[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
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. ***
[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
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=gccview=revrev=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
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
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=gccview=revrev=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
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
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=gccview=revrev=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 0x00cc64dc in get_named_section (decl=0x719a5850,
name=0x717fdbf4 .rodata.q.4121, reloc=0) at ../../gcc/varasm.c:411
#2 0x00cc7d6c in get_variable_section (decl=0x719a5850,
prefer_noswitch_p=true) at ../../gcc/varasm.c:1030
#3 0x00cc7f88 in get_block_for_decl (decl=0x719a5850) at
../../gcc/varasm.c:1076
#4 0x00cc8a88 in make_decl_rtl (decl=0x719a5850) at
../../gcc/varasm.c:1295
#5 0x00cc8e4f in make_decl_rtl_for_debug (decl=0x719a5850) at
../../gcc/varasm.c:1350
#6 0x00654bea in expand_debug_expr (exp=0x719a5850) at
../../gcc/cfgexpand.c:2777
#7 0x00657357 in expand_debug_expr (exp=0x717ed460) at
../../gcc/cfgexpand.c:3358
#8 0x00658b37 in expand_debug_locations () at
../../gcc/cfgexpand.c:3739
#9 0x0065b3c5 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=0x719a6410) at ../../gcc/varpool.c:61
#1 0x00cdb98a in varpool_remove_unreferenced_decls () at
../../gcc/varpool.c:406
#2 0x00cdbb07 in varpool_output_variables () at
../../gcc/varpool.c:440
#3 0x00686a00 in compile () at ../../gcc/cgraphunit.c:2044
#4 0x00686b7a in finalize_compilation_unit () at
../../gcc/cgraphunit.c:2120
and finally get_named_section again:
#1 0x00cc64dc in get_named_section (decl=0x719a5850,
name=0x717fdbf4 .rodata.q.4121, reloc=0) at ../../gcc/varasm.c:411
#2 0x00cc7d6c in get_variable_section (decl=0x719a5850,
prefer_noswitch_p=true) at ../../gcc/varasm.c:1030
#3 0x00cc7f88 in get_block_for_decl (decl=0x719a5850) at
../../gcc/varasm.c:1076
#4 0x00cc8a88 in make_decl_rtl (decl=0x719a5850) at
../../gcc/varasm.c:1295
#5 0x00cc8e4f in make_decl_rtl_for_debug (decl=0x719a5850) at
../../gcc/varasm.c:1350
#6 0x006f4d33 in rtl_for_decl_location (decl=0x719a5850) at
../../gcc/dwarf2out.c:15150
#7 0x006f503f in add_location_or_const_value_attribute
(die=0x71805be0, decl=0x719a5850, cache_p=false, attr=DW_AT_location)
at ../../gcc/dwarf2out.c:15244
#8 0x00709d9b in dwarf2out_finish (filename=0x7fffe58b
pr55395.i) at ../../gcc/dwarf2out.c:23218
#9 0x00a3e2ce 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
[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
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
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
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
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
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
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
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
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
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
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); }
