[Bug lto/51255] New: Using -flto breaks code which puts values in .ctors or .init_array

[Bug lto/51255] New: Using -flto breaks code which puts values in .ctors or .init_array

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255

             Bug #: 51255
           Summary: Using -flto breaks code which puts values in .ctors or
                    .init_array
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ian@airs.com


A test case similar to this is used by the gcc configure script
(HAVE_INITFINI_ARRAY in gcc/acinclude.m4):


extern void abort ();
static int count;

static void
init1005 ()
{
  if (count != 0)
    abort ();
  count = 1005;
}
void (*const init_array1005[]) ()
  __attribute__ ((section (".init_array.01005"), aligned (sizeof (void *))))
  = { init1005 };
static void
fini1005 ()
{
  if (count != 1005)
    abort ();
}
void (*const fini_array1005[]) ()
  __attribute__ ((section (".fini_array.01005"), aligned (sizeof (void *))))
  = { fini1005 };

static void
ctor1007 ()
{
  if (count != 1005)
    abort ();
  count = 1007;
}
void (*const ctors1007[]) ()
  __attribute__ ((section (".ctors.64528"), aligned (sizeof (void *))))
  = { ctor1007 };
static void
dtor1007 ()
{
  if (count != 1007)
    abort ();
  count = 1005;
}
void (*const dtors1007[]) ()
  __attribute__ ((section (".dtors.64528"), aligned (sizeof (void *))))
  = { dtor1007 };

static void
init65530 ()
{
  if (count != 1007)
    abort ();
  count = 65530;
}
void (*const init_array65530[]) ()
  __attribute__ ((section (".init_array.65530"), aligned (sizeof (void *))))
  = { init65530 };
static void
fini65530 ()
{
  if (count != 65530)
    abort ();
  count = 1007;
}
void (*const fini_array65530[]) ()
  __attribute__ ((section (".fini_array.65530"), aligned (sizeof (void *))))
  = { fini65530 };

static void
ctor65535 ()
{
  if (count != 65530)
    abort ();
  count = 65535;
}
void (*const ctors65535[]) ()
  __attribute__ ((section (".ctors"), aligned (sizeof (void *))))
  = { ctor65535 };
static void
dtor65535 ()
{
  if (count != 65535)
    abort ();
  count = 65530;
}
void (*const dtors65535[]) ()
  __attribute__ ((section (".dtors"), aligned (sizeof (void *))))
  = { dtor65535 };

int
main ()
{
  if (count != 65535)
    abort ();
  return 0;
}

When using a recent version of GNU ld or gold, this program is intended to
compile and run correctly.  However, if compiled with "-flto -O", it fails,
even using a recent linker.  It fails because the LTO pass does not realize
that the functions in the .ctors and .init_array sections are going to be run
before main.

[Bug lto/51255] Using -flto breaks code which puts values in .ctors or .init_array

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |krisztian.kocsis at
                   |                            |optimaster dot eu

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-03-05 18:39:30 UTC ---
*** Bug 52489 has been marked as a duplicate of this bug. ***

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |wrong-code
   Last reconfirmed|                            |2012-03-06
          Component|lto                         |middle-end
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
     Ever Confirmed|0                           |1
            Summary|Using -flto breaks code     |Using -fwhole-program
                   |which puts values in .ctors |breaks code which puts
                   |or .init_array              |values in .ctors or
                   |                            |.init_array

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-06 10:25:53 UTC ---
Reproducible with -O -fwhole-program as well.  This is IPA references work
which does not recognize count as being written to which is because we
removed the .init/fini_array section contents.

If you mark the section contents with the 'used' attribute it works correctly.

Honza, can we apply some magic here?  Thus, recognize special section names
or so?  Or is this a user bug (with -fwhole-program)?  Note that the linker
plugin gets this wrong as well (somehow).

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-03-19 15:35:28 UTC ---
I would incline to declare this an user error. GCC does not control the meaning
of all of the user specified sections and thus I would say that user is either
required to use constructor/destructor attributes or "used" attribute.

For sure we can add magic and make cgraph_finalize_function or so to drop an
attribute implicitly.

Note that constructor/destructor attributes are different from used
attribute+named section. We know how to optimize away ctors/dtors without side
effects etc. So it would be better to convert such code to an dedicated
attribute.

Honza

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[krisztian.kocsis at optimaster dot eu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255

--- Comment #4 from Krisztian Kocsis <krisztian.kocsis at optimaster dot eu> 2012-04-16 12:07:19 UTC ---
If it is treated as a user error than a warning should be printed because this
changes the behavior of what is dropped and what is not. People expect that
"used thinds" won't be dropped from the final binary and they treate these
sections as "used things" even if it is technically not true.

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255

--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> 2012-04-16 13:50:35 UTC ---
How common is this construction in practice?  Adding a warning or making GCC to
imply used attribute is same amount of work - it means teaching GCC about those
and possibly others special purpose sections.  Or alternatively declare all
named sections special purpose and implicitely used.

The code is not conforming any standards.  In past we started taking away
unused
variables/functions that also broke asm constructs and required annotations
without
making an attempt for GCC to parse asm statements.

Section names are easier to parse, indeed, but still the situation is very
symmetric
here.

Honza

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[krisztian.kocsis at optimaster dot eu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255

--- Comment #6 from Krisztian Kocsis <krisztian.kocsis at optimaster dot eu> 2012-04-16 14:35:37 UTC ---
I currently know that glibc uses it but don't know who else use it.
In my projects I always use constructor/destructor attributes because with them
I can control the exection order.

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[carlos at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #7 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Krisztian Kocsis from comment #6)
> I currently know that glibc uses it but don't know who else use it.
> In my projects I always use constructor/destructor attributes because with
> them I can control the exection order.

Internally glibc uses attribute used to mark any special .init_array sections
as used. It is only in our configure check and some tests that we don't use the
used attribute (bug in glibc). Building the library with -fwhole-program has
never been tested and likely won't succeed without a lot of additional work.

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[krisztian.kocsis at optimaster dot eu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51255

--- Comment #8 from Krisztian Kocsis <krisztian.kocsis at optimaster dot eu> ---
Hi!

In the meanwhile I'v successfully compiled uClibc 0.9.33.2 with LTO.
It required to patch only a few (2-3) lines to mark these sections as used.

We are running this in an embedded ARM926EJ-S based product since february
2013.

The system boot time is decreased by aprox. 10% only by recompiling libc with
LTO so it seems that it worth the job.

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
With the used attribute added to each of the variables, the code starts working
with both -flto and -fwhole-program (even on clang/LLVM this is needed to work
correctly).

So closing as invalid.