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 a
in 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.