I am experimenting with clang-tidy (while using a gcc) with all of it's checks. I was curious if the below case is a bug of clang-tidy as it contradicts my compiler's warnings. Here is a minimum example:
struct a{
virtual void func()=0;
virtual void func2()=0;
};
struct b:a{
void func() override {};
void func2() override {};
private:
int x{};
}
int main(){
b b_item;
}
The suggestion :
/home/main.cpp:7:8: note: use "__attribute__((aligned(0)))" to align struct 'a' to 0 bytes
struct a{
^
/home/main.cpp:13:8: warning: accessing fields in struct 'b' is inefficient due to padding; only needs 4 bytes but is using 16 bytes [altera-struct-pack-align]
struct b:a{
^
I will not demonstrate the code after the suggestion as clang-tidy made a lot of changes the important bit is:
struct a{
virtual void func()=0;
virtual void func2()=0;
} __attribute__((aligned(0)));
warning after calling fix:
warning: requested alignment ‘0’ is not a positive power of 2 [-Wattributes]
12 | } __attribute__((aligned(0)));
Reasoning
After all the reasoning for that is quite simple. The
altera*options of clang-tidy relate with fpga programming in C with some very specific compilers in mind (I think altera uses c2h and there is also a big list of alternatives here). These compilers probably doesn't have these quite advanced warning but I haven't verified that yet. A reason I believe that is that c lang doesn't have virtual functions so I can not think of a case where zero byte alignment would be appropriate(C doesn't allow trivial structs).Aftermath
The question that occurred to me is why gcc throws these warning? Is it appropriate to have a zero byte struct in c++ ? The answer is no pure virtual and abstract classes never compile they are only used as base classes for others. Structs like the
struct ain my question never appear in assembly. So as a conclusion I believe that both gcc and clang-tidy are correct on their warnings but I would strongly recommend to someone to not use clang-tidy fpga specific flags on non-fpga projects.Here and here is some reasoning on gcc side about introducing these warning.