Bug 20267 - gcc-c++-2.96-60 fails to compile this sample
Summary: gcc-c++-2.96-60 fails to compile this sample
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: David Lawrence
URL: ftp://icarus.com/pub/eda/tmp/foo.i
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-11-03 04:20 UTC by steve
Modified: 2007-04-18 16:29 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-16 22:46:34 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This is the offending file, neatly preprocessed. (307.54 KB, text/plain)
2000-11-03 04:22 UTC, steve
no flags Details
This very simple test case has the same symptoms as the bigger foo.i. (222 bytes, patch)
2000-11-03 23:12 UTC, steve
no flags Details | Diff

Description steve 2000-11-03 04:20:22 UTC
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.

Comment 1 steve 2000-11-03 04:22:15 UTC
Created attachment 4974 [details]
This is the offending file, neatly preprocessed.

Comment 2 Jakub Jelinek 2000-11-03 15:09:27 UTC
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.

Comment 3 steve 2000-11-03 18:50:13 UTC
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.

Comment 4 steve 2000-11-03 23:12:32 UTC
Created attachment 5034 [details]
This very simple test case has the same symptoms as the bigger foo.i.

Comment 5 steve 2000-11-03 23:17:43 UTC
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.


Comment 6 Jakub Jelinek 2000-11-04 07:02:33 UTC
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.

Comment 7 Jakub Jelinek 2000-11-04 20:25:06 UTC
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).

Comment 8 Jakub Jelinek 2001-02-16 22:46:30 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.