Internal compiler error in GCC 4.2.1

[sharper]

Internal compiler error in GCC 4.2.1

[GoogleCodeExporter]

I tried compiling on gcc 4.2.1, and was unable to reproduce the problem.  Can 
you
clarify if the ICE happens with "-g -O2", or is it only with -g?  (Though I was
unable to reproduce the problem in either case.)

Can you maybe attach the full make output you get, where you get this error?  I 
will
try running with exactly the same commandline arguments as you.

I'd rather not work around this problem by DECLARING every string we define: 
that
makes all string vars global variables (by default they're local to the file 
they're
DEFINED), which isn't so great.  But hopefully there's another solution that 
will
work as well.

Original comment by [email protected] on 29 Aug 2008 at 11:49

[GoogleCodeExporter]

I use this as the source file (define.cpp):

#include <gflags/gflags.h>
DEFINE_string(name, "default", "help");

And the following command line to compile it:

g++ -g -c -Igflags-1.0rc1/src/ -o define.o define.cpp

I also made a reduced test case which triggers the problem without including 
any 
headers:

class C {};
namespace NS {
C obj;
C& ref = *reinterpret_cast<C*>(&obj);
}
using NS::ref;

Original comment by [email protected] on 30 Aug 2008 at 9:07

[GoogleCodeExporter]

Actually the test case can be reduced further:

class C {};
namespace NS {
C obj;
C& ref = obj;
}
using NS::ref;

Original comment by [email protected] on 30 Aug 2008 at 9:39

[GoogleCodeExporter]

Thanks for finding such a nice test case.  However, I still can't reproduce the
problem.  Perhaps it's due to a local (suse) modification to gcc, or the way 
it's
compiled?  Or perhaps we made a local change here; I don't know of any, but it's
possible.  Or perhaps there ae more than one gcc 4.2.1?

Here is my program:
% cat bad.cc
class C {};
namespace NS {
C obj;
C& ref = obj;
}
using NS::ref;

And here is my compilation:
% g++ --version
g++ (GCC) 4.2.1
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% g++ -c bad.cc
%

Unfortunately I don't have access to a SUSE 10 machine, so I can't reproduce the
problem directly.

Can you maybe explore workarounds locally?  You already found one, it sounds 
like,
which involves adding an extern declaration?  I had objected to that earlier, 
not
wanting to make the flags global, but it occurs to me my objection was silly. 
DEFINEs are done in .cc files, not .h files, so the "extern" doesn't really do
anything except work around the bug.

Can you try modifying the DEFINE_* macro in gflags.h, to put an "extern" 
declaration
in various places, and see if you can find an incantation that quiets the 
compiler?
(This is cleaner than just putting in the DECLARE_* macro as part of the 
DEFINE_*
macro.)  If so, I'll make it part of the next gcc release.

Original comment by [email protected] on 2 Sep 2008 at 6:58

• Changed state: Accepted

[GoogleCodeExporter]

The "-g" flag is essential to trigger the error.

Original comment by [email protected] on 2 Sep 2008 at 7:10

[GoogleCodeExporter]

Right -- you had said and I totally forgot.

I did it again with -g and got the same result:

% g++ -g -c bad.cc
%

Original comment by [email protected] on 2 Sep 2008 at 7:17

[GoogleCodeExporter]

I can report the same using GCC 4.2.1 (SUSE Linux 10.3, x86), when compiling 
with the
-g option.  Otherwise it is fine.

Adding these 2 lines always fixes the test case provided by mthuurne (for me).
class C {};
namespace NS {
  C obj;
  extern C& ref;  // added
  using NS::ref;  // added, now compiles
  C& ref = obj;
}
using NS::ref;

Doing the same in config.h.in quiets the compiler.  Or, equivalently, adding
DECLARE_string as mthuurne pointed out.  Unfortunately, I could never get a
successful compile, without using both the 'extern ...' and 'using ...' extra 
lines.

>svn diff
Index: src/gflags/gflags.h.in
===================================================================
--- src/gflags/gflags.h.in      (revision 28)
+++ src/gflags/gflags.h.in      (working copy)
@@ -508,6 +508,8 @@
     static @ac_google_namespace@::FlagRegisterer o_##name(                \
       #name, "string", MAYBE_STRIPPED_HELP(txt), __FILE__,                \
       s_##name[0].s, new (s_##name[1].s) std::string(*FLAGS_no##name));   \
+    extern std::string& FLAGS_##name;                                  \
+    using fLS::FLAGS_##name;                                           \
     std::string& FLAGS_##name = *(reinterpret_cast<std::string*>(s_##name[0].s));   \
   }                                                                       \
   using fLS::FLAGS_##name

Original comment by [email protected] on 6 Nov 2008 at 3:24

[GoogleCodeExporter]

Wow, a using declaration within its own namespace!  What a weird compiler issue 
this
must be.

This magic incantation seems to have no downside, so I'll add it for the next 
release.

Original comment by [email protected] on 6 Nov 2008 at 6:30

• Changed state: Started

[GoogleCodeExporter]

This should be fixed in gflags 1.2

Original comment by [email protected] on 11 Sep 2009 at 12:18

• Changed state: Fixed