[Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu

[Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

             Bug #: 55395
           Summary: [4.8 Regression] libgfortran bootstrap failure on
                    powerpc-linux-gnu
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: doko@gcc.gnu.org


seen with Mon Nov 19 12:07:37 UTC 2012 (revision 193619), powerpc only:

/bin/bash ./libtool  --tag=CC   --mode=compile
/build/buildd/gcc-4.8-4.8-20121119/build/./gcc/xgcc
-B/build/buildd/gcc-4.8-4.8-20121119/build/./gcc/ -B/usr/powerpc-linux-gnu/bin/
-B/usr/powerpc-linux-gnu/lib/ -isystem /usr/powerpc-linux-gnu/include -isystem
/usr/powerpc-linux-gnu/sys-include    -DHAVE_CONFIG_H -I.
-I../../../src/libgfortran  -iquote../../../src/libgfortran/io
-I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config 
-I../.././gcc -I../../../src/libgfortran/../libgcc -I../libgcc  -std=gnu99
-Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra
-Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections  -g -O2
-MT list_read.lo -MD -MP -MF .deps/list_read.Tpo -c -o list_read.lo `test -f
'io/list_read.c' || echo '../../../src/libgfortran/'`io/list_read.c
libtool: compile:  /build/buildd/gcc-4.8-4.8-20121119/build/./gcc/xgcc
-B/build/buildd/gcc-4.8-4.8-20121119/build/./gcc/ -B/usr/powerpc-linux-gnu/bin/
-B/usr/powerpc-linux-gnu/lib/ -isystem /usr/powerpc-linux-gnu/include -isystem
/usr/powerpc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../src/libgfortran -iquote../../../src/libgfortran/io
-I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config
-I../.././gcc -I../../../src/libgfortran/../libgcc -I../libgcc -std=gnu99 -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra
-Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2
-MT list_read.lo -MD -MP -MF .deps/list_read.Tpo -c
../../../src/libgfortran/io/list_read.c  -fPIC -DPIC -o .libs/list_read.o
../../../src/libgfortran/io/list_read.c:2382:21: error: endl causes a section
type conflict with endl
   static const char endl[] = "\n";
                     ^
make[5]: *** [list_read.lo] Error 1
make[5]: Leaving directory
`/build/buildd/gcc-4.8-4.8-20121119/build/powerpc-linux-gnu/libgfortran'
make[4]: *** [all] Error 2
make[4]: Leaving directory
`/build/buildd/gcc-4.8-4.8-20121119/build/powerpc-linux-gnu/libgfortran'
make[3]: *** [all-target-libgfortran] Error 2

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|powerpc-linux-gnu           |powerpc-linux-gnu,
                   |                            |arm-linux-gnueabi

--- Comment #1 from Matthias Klose <doko at gcc dot gnu.org> 2012-11-19 23:01:36 UTC ---
seen on arm-linux-gnueabi (hard float) too.

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-11-19 23:09:57 UTC ---
Untested:

--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -2377,3 +2377,3 @@ nml_query (st_parameter_dt *dtp, char c)
   static const index_type endlen = 3;
-  static const char endl[] = "\r\n";
+  static const char endline[] = "\r\n";
   static const char nmlend[] = "&end\r\n";
@@ -2381,3 +2381,3 @@ nml_query (st_parameter_dt *dtp, char c)
   static const index_type endlen = 2;
-  static const char endl[] = "\n";
+  static const char endline[] = "\n";
   static const char nmlend[] = "&end\n";
@@ -2415,3 +2415,3 @@ nml_query (st_parameter_dt *dtp, char c)
          memcpy ((char*)(p + 1), dtp->namelist_name, len);
-         memcpy ((char*)(p + len + 1), &endl, endlen - 1);
+         memcpy ((char*)(p + len + 1), &endline, endlen - 1);
          for (nl = dtp->u.p.ionml; nl; nl = nl->next)
@@ -2426,3 +2426,3 @@ nml_query (st_parameter_dt *dtp, char c)
              memcpy ((char*)(p + 1), nl->var_name, len);
-             memcpy ((char*)(p + len + 1), &endl, endlen - 1);
+             memcpy ((char*)(p + len + 1), &endline, endlen - 1);
            }

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose <doko at gcc dot gnu.org> 2012-11-21 04:07:53 UTC ---
this seems to be a configuration issue. the plain cvs build does succeed,
however if you turn on -fstack-protector by default, the build fails.

this is the patch I'm using to turn on -fstack-protector by default:
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/gcc-default-ssp.diff?view=markup

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-11-21 04:10:18 UTC ---
Can you provide the preprocessed source?

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |53475

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-11-21 04:14:09 UTC ---
I think this might be a dup of bug 53475.

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[doko at gcc dot gnu.org]

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

--- Comment #6 from Matthias Klose <doko at gcc dot gnu.org> 2012-11-21 04:18:46 UTC ---
Created attachment 28749
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28749
preprocessed source

attached, for arm-linux-gnueabihf

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-12-04
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-04 10:13:06 UTC ---
Reduced testcase:
/* { dg-do compile } */
/* { dg-options "-fdata-sections -g -O2" } */
/* { dg-additional-options "-fstack-protector" { target fstack_protector } } */

extern inline __attribute__ ((__always_inline__))
void *
memcpy (void *__restrict d, const void *__restrict s, __SIZE_TYPE__ l)
{
  return __builtin___memcpy_chk (d, s, l, __builtin_object_size (d, 0));
}

void
foo (char *p)
{
  static const char q[] = "\n";
  memcpy (p, &q, 1);
}

The reason why this fails is IMHO bogus change from
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187631

void
varpool_remove_node (struct varpool_node *node)
{
  symtab_unregister_node ((symtab_node)node);
  if (DECL_INITIAL (node->symbol.decl)
      && !DECL_IN_CONSTANT_POOL (node->symbol.decl)
      /* Keep vtables for BINFO folding.  */
      && !DECL_VIRTUAL_P (node->symbol.decl)
      /* dbxout output constant initializers for readonly vars.  */
      && (!host_integerp (DECL_INITIAL (node->symbol.decl), 0)
          || !TREE_READONLY (node->symbol.decl)))
    DECL_INITIAL (node->symbol.decl) = error_mark_node;
  ggc_free (node);
}

(the DECL_INITIAL setting to error_mark_node).  I can understand the aim at
saving compile time memory, but this is a wrong thing to do.  dwarf2out.c uses
DECL_INITIAL heavily to emit debug info even for optimized away variables.

The exact reason for the error is that we have get_named_section called twice,
once before the varpool_remove_node call, once after it.
The first one is:
#1  0x0000000000cc64dc in get_named_section (decl=0x7ffff19a5850,
name=0x7ffff17fdbf4 ".rodata.q.4121", reloc=0) at ../../gcc/varasm.c:411
#2  0x0000000000cc7d6c in get_variable_section (decl=0x7ffff19a5850,
prefer_noswitch_p=true) at ../../gcc/varasm.c:1030
#3  0x0000000000cc7f88 in get_block_for_decl (decl=0x7ffff19a5850) at
../../gcc/varasm.c:1076
#4  0x0000000000cc8a88 in make_decl_rtl (decl=0x7ffff19a5850) at
../../gcc/varasm.c:1295
#5  0x0000000000cc8e4f in make_decl_rtl_for_debug (decl=0x7ffff19a5850) at
../../gcc/varasm.c:1350
#6  0x0000000000654bea in expand_debug_expr (exp=0x7ffff19a5850) at
../../gcc/cfgexpand.c:2777
#7  0x0000000000657357 in expand_debug_expr (exp=0x7ffff17ed460) at
../../gcc/cfgexpand.c:3358
#8  0x0000000000658b37 in expand_debug_locations () at
../../gcc/cfgexpand.c:3739
#9  0x000000000065b3c5 in gimple_expand_cfg () at ../../gcc/cfgexpand.c:4606
when creating DEBUG_IMPLICIT_PTR for the parameter s.  Then varpool_remove_node
is called:
#0  varpool_remove_node (node=0x7ffff19a6410) at ../../gcc/varpool.c:61
#1  0x0000000000cdb98a in varpool_remove_unreferenced_decls () at
../../gcc/varpool.c:406
#2  0x0000000000cdbb07 in varpool_output_variables () at
../../gcc/varpool.c:440
#3  0x0000000000686a00 in compile () at ../../gcc/cgraphunit.c:2044
#4  0x0000000000686b7a in finalize_compilation_unit () at
../../gcc/cgraphunit.c:2120
and finally get_named_section again:
#1  0x0000000000cc64dc in get_named_section (decl=0x7ffff19a5850,
name=0x7ffff17fdbf4 ".rodata.q.4121", reloc=0) at ../../gcc/varasm.c:411
#2  0x0000000000cc7d6c in get_variable_section (decl=0x7ffff19a5850,
prefer_noswitch_p=true) at ../../gcc/varasm.c:1030
#3  0x0000000000cc7f88 in get_block_for_decl (decl=0x7ffff19a5850) at
../../gcc/varasm.c:1076
#4  0x0000000000cc8a88 in make_decl_rtl (decl=0x7ffff19a5850) at
../../gcc/varasm.c:1295
#5  0x0000000000cc8e4f in make_decl_rtl_for_debug (decl=0x7ffff19a5850) at
../../gcc/varasm.c:1350
#6  0x00000000006f4d33 in rtl_for_decl_location (decl=0x7ffff19a5850) at
../../gcc/dwarf2out.c:15150
#7  0x00000000006f503f in add_location_or_const_value_attribute
(die=0x7ffff1805be0, decl=0x7ffff19a5850, cache_p=false, attr=DW_AT_location)
    at ../../gcc/dwarf2out.c:15244
#8  0x0000000000709d9b in dwarf2out_finish (filename=0x7fffffffe58b
"pr55395.i") at ../../gcc/dwarf2out.c:23218
#9  0x0000000000a3e2ce in compile_file () at ../../gcc/toplev.c:600

In the first case, DECL_INITIAL is not NULL, nor error_mark_node, nor zero
initializer, so rodata.q.4121 is assumed to be a read-only section, in the
second case DECL_INITIAL of q is already error_mark_node and thus rodata.q.4121
is assumed to be a bss section, therefore a section flags conflict.  In the
case of array initialized with a constant string right now the initializer
won't be useful, but I guess we could emit DW_OP_GNU_implicit_pointer in that
case, pointing to a DW_OP_implicit_value initialized artificial object.  But
there are tons of cases where DECL_INITIAL is even successfully used at
dwarf2out_finish time, e.g. during the deferred location processing.  So, if
you want to save memory, please do that solely if not emitting debug info.
So, I'd suggest replacing the
      /* dbxout output constant initializers for readonly vars.  */
      && (!host_integerp (DECL_INITIAL (node->symbol.decl), 0)
          || !TREE_READONLY (node->symbol.decl)))
part with
      && write_symbols == NO_DEBUG)
or ammending it with
      /* dwarf2out.c uses DECL_INITIAL even on optimized away decls,
         very late during compilation.  */
      && (write_symbols != DWARF2_DEBUG && write_symbols !=
VMS_AND_DWARF2_DEBUG)

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> 2012-12-04 14:46:06 UTC ---
> (the DECL_INITIAL setting to error_mark_node).  I can understand the aim at
> saving compile time memory, but this is a wrong thing to do.  dwarf2out.c uses
> DECL_INITIAL heavily to emit debug info even for optimized away variables.

OK, the aim was mostly to get rid of large constructors. Is it possible to tell
when
the DECL_INITIAL will be needed?  This problem also exists with LTO where we do
not
stream initializers of variables not assigned to a given partition.

Honza

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-04 15:10:00 UTC ---
(In reply to comment #8)
> OK, the aim was mostly to get rid of large constructors. Is it possible to tell
> when the DECL_INITIAL will be needed?  This problem also exists with LTO where > we do not stream initializers of variables not assigned to a given partition.

It is always used if available and there is no other way to generate the
location info for it (which for vars that were removed from the varpool is
probably always, I bet those aren't assigned memory locations).  The question
is of course if it can successfully generate something out of it or not, but
you can't guess that before it tried.
For the invalid error part of this PR, it would be just important that it
doesn't set DECL_INITIAL to error_mark_node, but some other magic value which
says, this decl had non-zero initializer, but ignore the other details about
it.  Of course to make the debug info more complete you really should keep the
initializer.
Aren't you building mozilla with LTO without -g anyway, given that LTO screws
up debug info so terribly that it isn't useful at all?
Can you come up with some short testcase that would show what kind of large
constructors you care about?

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[hubicka at ucw dot cz]

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

--- Comment #10 from Jan Hubicka <hubicka at ucw dot cz> 2012-12-04 16:25:36 UTC ---
> It is always used if available and there is no other way to generate the
> location info for it (which for vars that were removed from the varpool is
> probably always, I bet those aren't assigned memory locations).  The question
> is of course if it can successfully generate something out of it or not, but
> you can't guess that before it tried.
> For the invalid error part of this PR, it would be just important that it
> doesn't set DECL_INITIAL to error_mark_node, but some other magic value which
> says, this decl had non-zero initializer, but ignore the other details about
> it.  Of course to make the debug info more complete you really should keep the

OK, what value it should be?  We always used error_mark_node with this meaning
both in LTO and cgraph.
> initializer.
> Aren't you building mozilla with LTO without -g anyway, given that LTO screws
> up debug info so terribly that it isn't useful at all?

I build -g to at least catch the ICEs. Of course we should work towards making
-g
useful not useless.

> Can you come up with some short testcase that would show what kind of large
> constructors you care about?

static int a[]={huge sequence of numbers};
In C++ we have a lot of class constructors and vtables that comes from headers
and can go away...

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-04 16:41:35 UTC ---
(In reply to comment #10)
> OK, what value it should be?  We always used error_mark_node with this meaning
> both in LTO and cgraph.

Dunno, I'm leaning towards just not dropping anything for -g.

> static int a[]={huge sequence of numbers};
> In C++ we have a lot of class constructors and vtables that comes from headers
> and can go away...

But that should be perfectly expressable in DWARF4, if we don't express it
right now, we just should.

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jakub at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-06 13:52:10 UTC ---
Created attachment 28887
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28887
gcc48-pr55395.patch

Patch I've bootstrapped/regtested on x86_64-linux and i686-linux (which I also
need for PR55608.

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-06 20:35:01 UTC ---
Author: jakub
Date: Thu Dec  6 20:34:55 2012
New Revision: 194272

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194272
Log:
    PR fortran/55395
    * varpool.c (varpool_remove_node): Don't drop DECL_INITIAL
    if -g and emitting DWARF2+.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/varpool.c

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-07 00:01:41 UTC ---
Fixed.

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-07 16:04:33 UTC ---
Author: jakub
Date: Fri Dec  7 16:04:26 2012
New Revision: 194304

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194304
Log:
    PR fortran/55395
    * varpool.c (varpool_remove_node): Don't drop DECL_INITIAL
    for -g for any kind of debug info.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/varpool.c

[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Greta.Yorsh at arm dot com

Bug 55395 depends on bug 53475, which changed state.

Bug 53475 Summary: [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-10 20:31:51 UTC ---
*** Bug 53475 has been marked as a duplicate of this bug. ***