seen on arm-linux-gnueabi (hard float) too.

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);
            }

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

Can you provide the preprocessed source?

I think this might be a dup of bug 53475.

Created attachment 28749 [details]
preprocessed source

attached, for arm-linux-gnueabihf

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)

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

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

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

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

Created attachment 28887 [details]
gcc48-pr55395.patch

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

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

Fixed.

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 53475 has been marked as a duplicate of this bug. ***