* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
@ 2012-11-19 23:02 ` doko at gcc dot gnu.org
2012-11-19 23:10 ` [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi burnus at gcc dot gnu.org
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: doko at gcc dot gnu.org @ 2012-11-19 23:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
2012-11-19 23:02 ` [Bug fortran/55395] " doko at gcc dot gnu.org
@ 2012-11-19 23:10 ` burnus at gcc dot gnu.org
2012-11-21 4:08 ` doko at gcc dot gnu.org
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-11-19 23:10 UTC (permalink / raw)
To: gcc-bugs
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);
}
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
2012-11-19 23:02 ` [Bug fortran/55395] " doko at gcc dot gnu.org
2012-11-19 23:10 ` [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi burnus at gcc dot gnu.org
@ 2012-11-21 4:08 ` doko at gcc dot gnu.org
2012-11-21 4:10 ` pinskia at gcc dot gnu.org
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: doko at gcc dot gnu.org @ 2012-11-21 4:08 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (2 preceding siblings ...)
2012-11-21 4:08 ` doko at gcc dot gnu.org
@ 2012-11-21 4:10 ` pinskia at gcc dot gnu.org
2012-11-21 4:14 ` pinskia at gcc dot gnu.org
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: pinskia at gcc dot gnu.org @ 2012-11-21 4:10 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (3 preceding siblings ...)
2012-11-21 4:10 ` pinskia at gcc dot gnu.org
@ 2012-11-21 4:14 ` pinskia at gcc dot gnu.org
2012-11-21 4:19 ` doko at gcc dot gnu.org
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: pinskia at gcc dot gnu.org @ 2012-11-21 4:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (4 preceding siblings ...)
2012-11-21 4:14 ` pinskia at gcc dot gnu.org
@ 2012-11-21 4:19 ` doko at gcc dot gnu.org
2012-11-25 15:52 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: doko at gcc dot gnu.org @ 2012-11-21 4:19 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (5 preceding siblings ...)
2012-11-21 4:19 ` doko at gcc dot gnu.org
@ 2012-11-25 15:52 ` rguenth at gcc dot gnu.org
2012-12-04 10:14 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-11-25 15:52 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (6 preceding siblings ...)
2012-11-25 15:52 ` rguenth at gcc dot gnu.org
@ 2012-12-04 10:14 ` jakub at gcc dot gnu.org
2012-12-04 14:47 ` hubicka at ucw dot cz
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-04 10:14 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (7 preceding siblings ...)
2012-12-04 10:14 ` jakub at gcc dot gnu.org
@ 2012-12-04 14:47 ` hubicka at ucw dot cz
2012-12-04 15:11 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: hubicka at ucw dot cz @ 2012-12-04 14:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (8 preceding siblings ...)
2012-12-04 14:47 ` hubicka at ucw dot cz
@ 2012-12-04 15:11 ` jakub at gcc dot gnu.org
2012-12-04 16:26 ` hubicka at ucw dot cz
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-04 15:11 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (9 preceding siblings ...)
2012-12-04 15:11 ` jakub at gcc dot gnu.org
@ 2012-12-04 16:26 ` hubicka at ucw dot cz
2012-12-04 16:42 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: hubicka at ucw dot cz @ 2012-12-04 16:26 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (10 preceding siblings ...)
2012-12-04 16:26 ` hubicka at ucw dot cz
@ 2012-12-04 16:42 ` jakub at gcc dot gnu.org
2012-12-06 13:52 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-04 16:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (11 preceding siblings ...)
2012-12-04 16:42 ` jakub at gcc dot gnu.org
@ 2012-12-06 13:52 ` jakub at gcc dot gnu.org
2012-12-06 20:35 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-06 13:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (12 preceding siblings ...)
2012-12-06 13:52 ` jakub at gcc dot gnu.org
@ 2012-12-06 20:35 ` jakub at gcc dot gnu.org
2012-12-07 0:02 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-06 20:35 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (13 preceding siblings ...)
2012-12-06 20:35 ` jakub at gcc dot gnu.org
@ 2012-12-07 0:02 ` jakub at gcc dot gnu.org
2012-12-07 16:05 ` jakub at gcc dot gnu.org
2012-12-10 20:32 ` jakub at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-07 0:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (14 preceding siblings ...)
2012-12-07 0:02 ` jakub at gcc dot gnu.org
@ 2012-12-07 16:05 ` jakub at gcc dot gnu.org
2012-12-10 20:32 ` jakub at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-07 16:05 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
` (15 preceding siblings ...)
2012-12-07 16:05 ` jakub at gcc dot gnu.org
@ 2012-12-10 20:32 ` jakub at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-10 20:32 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 18+ messages in thread