[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
--- Comment #4 from roland at redhat dot com 2010-08-11 23:52 ---
The compiler is being internally inconsistent here. It somtimes decides that
__attribute__((section ("name"))) means a "name" section in a COMDAT group, and
sometimes decides that it means just a plain "name" section. If it's going to
have that behavior implicitly, then it should not call this a conflict.
Instead, it should implicitly recognize that the particular COMDAT version of
"name" is a different animal than the non-COMDAT "name".
In fact, it has an arguably more severe version of this bug too:
class C
{
public:
void m()
{
static int TWO __attribute__((section(".consts"))) = 2;
}
};
class D
{
public:
void m()
{
static int THREE __attribute__((section(".consts"))) = 2;
}
};
int
main (int argc, char **argv)
{
C inst = C();
inst.m();
D inst2 = D();
inst2.m();
return 0;
}
For that, it happily puts TWO and THREE initializers both in the COMDAT group
for C::m()::TWO, which is quite clearly wrong. The left hand uses multiple
different sections of the same name, but the right hand thinks that any section
matching the simple name it's looking for is the same thing regardless of
whether or not its a distinct COMDAT variant.
--
roland at redhat dot com changed:
What|Removed |Added
CC||roland at redhat dot com,
||jakub at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091
Benedek changed:
What|Removed |Added
CC||erenon2 at gmail dot com
--- Comment #6 from Benedek ---
The following code reproduces this, or a very similar issue:
#define STORE(SECTION, STRING) \
__attribute__((section(SECTION), used)) \
static constexpr const char* s[] = { STRING }
void f()
{
STORE(".custom", "normal_foobar");
}
inline void g()
{
STORE(".custom", "inline_foobar");
}
template
void h()
{
STORE(".custom", "template_foobar");
}
int main()
{
f(); g(); h();
return 0;
}
$ g++ -std=c++11 section.cpp
section.cpp: error: 's' causes a section type conflict with 's'
GCC 4.8, 5.2, 7.2, and trunk are affected (x86-64, checked on godbolt).
Depending on the compiler version, either the normal and the inline, or the
normal and the function template clashes.
I suppose because of how comdat is handled, they might have slightly different
needs, but it would be really nice to make it easier for the user.
(Clang compiles it fine)
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091 Martin Sebor changed: What|Removed |Added Keywords||rejects-valid Status|RESOLVED|NEW Last reconfirmed||2017-10-25 Resolution|FIXED |--- Ever confirmed|0 |1 Known to fail||4.4.0, 4.9.4, 5.4.0, 6.4.0, ||7.2.0, 8.0 --- Comment #7 from Martin Sebor --- Thanks for the test case. I can confirm the error on trunk (GCC 8.0). Reopening.
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Martin Sebor --- I see no error for the test case in comment #0 with the top of trunk (GCC 7.0) so I'm resolving this report as fixed. Please reopen it if the problem persists with different symptoms.
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091 Paul Robinson changed: What|Removed |Added CC||paul_robinson at playstation dot s ||ony.com, ppalka at gcc dot gnu.org --- Comment #11 from Paul Robinson --- Given that the fix for bug 94342 by @ppalka should have addressed this for templates, is it the case that the only remaining issue is for inline functions? (See comment 6 for the test case.) Naively the comdat-related section naming issues would be the same.
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-14 04:50 --- Actually, they have to have two different section types. c::m()::TWO has to be in the comdat section for C::m(). While c()::ONE does not and can be in a normal section. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
--- Comment #2 from mark at gcc dot gnu dot org 2009-10-14 07:48 --- (In reply to comment #1) > Actually, they have to have two different section types. > > c::m()::TWO has to be in the comdat section for C::m(). > While c()::ONE does not and can be in a normal section. INVALID? How is the user supposed to know (or care) about comdat? All they want is make sure the constants get put in the same section. So how can one specify that behavior for both ONE and TWO? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
--- Comment #3 from mark at gcc dot gnu dot org 2009-10-17 11:28 --- See comment #2. -- mark at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091 David L. changed: What|Removed |Added CC||equinox-gccbugs at diac24 dot net --- Comment #8 from David L. --- Issue persists in gcc 10.2, test program from comment #6 still errors out. We're hitting this bug in production/real-world code [ https://github.com/FRRouting/frr/pull/6766 ]. What we're doing is very similar to SystemTap's trace points, I believe those might be affected as well. clang++ works fine meanwhile.
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091 Bobby Reynolds changed: What|Removed |Added CC||boreynol at microsoft dot com --- Comment #9 from Bobby Reynolds --- My team is also impacted by this issue (also with tracing code, as it turns out). FWIW there's a great writeup explaining the issue on Stack Overflow: https://stackoverflow.com/questions/35091862/inline-static-data-causes-a-section-type-conflict In this writeup, the author suggests that perhaps -fno-gnu-unique should additionally cause GCC to _not_ use section grouping for the associated symbol; in this case GCC would simply emit a weak symbol without grouping, which I believe would match the (admittedly less robust) behavior of Clang.
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091 --- Comment #10 from Andrew Pinski --- I really doubt there is a good solution for this because of what c++ calls vague linkage. Clang's solution is broken too.
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #12 from Andrew Pinski --- See PR 87178. *** This bug has been marked as a duplicate of bug 87178 ***
