[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict

[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict

[equinox-gccbugs at diac24 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091

David L. <equinox-gccbugs at diac24 dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |equinox-gccbugs at diac24 dot net

--- Comment #8 from David L. <equinox-gccbugs at diac24 dot net> ---
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

[boreynol at microsoft dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091

Bobby Reynolds <boreynol at microsoft dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |boreynol at microsoft dot com

--- Comment #9 from Bobby Reynolds <boreynol at microsoft dot com> ---
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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[paul_robinson at playstation dot sony.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091

Paul Robinson <paul_robinson at playstation dot sony.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paul_robinson at playstation dot s
                   |                            |ony.com, ppalka at gcc dot gnu.org

--- Comment #11 from Paul Robinson <paul_robinson at playstation dot sony.com> ---
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] New: Using section attribute in c and c++ function causes section type conflict

[mark at gcc dot gnu dot org]

The following code that puts two static variables into their own section won't
compile because of a section type conflict.

class C
{
public:
  void m()
  {
    static const int TWO __attribute__((section(".consts"))) = 2;
  }
}; 

static void c()
{
  static const int ONE __attribute__((section(".consts"))) = 1;
}

int
main (int argc, char **argv)
{
  C inst = C();
  inst.m();
  c();
  return 0;
}

$ g++ section.cxx 
section.cxx:12: error: ONE causes a section type conflict

The section should have the same type in both definitions, but apparently
doesn't.


-- 
           Summary: Using section attribute in c and c++ function causes
                    section type conflict
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mark at gcc dot gnu dot org


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

[pinskia at gcc dot gnu dot org]

------- 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

[mark at gcc dot gnu dot org]

------- 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

[mark at gcc dot gnu dot org]

------- 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

[roland at redhat dot com]

------- 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