This information is actually reported to me by a user, but I managed to get out of him enough information to make a thorough report. I believe that my code is correct, and earlier versions of gcc agree with me, but instead I get this rather cryptic error message: c++ -DHAVE_GETOPT_H=1 -g -O2 -I. -MD -c t-dll.cc -o t-dll.o t-dll.cc: In function `void __static_initialization_and_destruction_0 (int, int)': t-dll.cc:492: non-lvalue in unary `&' make: *** [t-dll.o] Error 1 The preprocessed source that produced this message is available at: <ftp://icarus.com/pub/eda/tmp/foo.i> The entire source bundle that includes this is available at: <ftp://icarus.com/pub/eda/verilog/snapshots/verilog-20001028.tar.gz> If the bug is not conveniently fixed, a workaround would be great.
Created attachment 4974 [details] This is the offending file, neatly preprocessed.
That looks like a bug in verilog. The issue is that you have extern const struct target tgt_dll = { "dll", &dll_target_obj }; but the first field of struct target is not char *, but string, so C++ has to call string constructor, but cannot, because the variable is const. Either initialize that tgt_dll variable just in one object (in which you remove both extern const), or make its fields char * or something which does not need to be constructed at runtime. I'm not a C++ guru, but the error makes sense to me. If you have any further testcases, please post them.
The string in the "const struct target ..." should have its initializer invoked, whether it is constant or not. This is how const objects with constructurs get initialized in the first place. This works with gcc 2.96: const string hello = "Hello, world."; The best I can figure, gcc-2.96 is deciding that the tgt_dll object is a PODS and not passing parameters to the initializers of the members, even though the string member has the appropriate constructor. Anyhow, it looks like I have a workaround for this specific problem. I still think that gcc is wrong, though.
Created attachment 5034 [details] This very simple test case has the same symptoms as the bigger foo.i.
OK, I've attached a very simple hello.cc example. It is my understanding that this program should compile just fine, but it doesn't. The constructor to the string object must be called, whether the object is constant or not, and some constructors take parameters. The syntax I'm using should pass a parameter to the string constructor. Anyhow, I've got my workaround working, and at this point the matter is entirely academic. Just thought you'd like to know what I found out.
Ihave sent even smaller testcase to our C++ experts yesterday, hope somebody responds with either explanation why it is illegal or ack that it is a bug.
Ok, the first response so far was that one guy cannot find anything what would make that illegal, so I'm reopening this, as it is unclear where the bug is. I'll try to find out more (even read C++ standard on monday).
Should be fixed by http://gcc.gnu.org/ml/gcc-patches/2001-02/msg00967.html which I've just commited to CVS head and gcc 3.0 branch and will appear in gcc-c++-2.96-76.