C++: Parser regression over 1.1.2

C++: Parser regression over 1.1.2

[Martin v. Loewis]

In egcs 1.1, we would accept the code

typedef unsigned int QRgb;
struct QColor{
  QColor( QRgb rgb);
};

struct QColorGroup{
  QColorGroup( const QColor &foreground, const QColor &background);
};

int main()
{
  QColorGroup normal( QColor( QRgb(16711680) ), QColor( QRgb(16777215) ));
}

On i486-pc-linux-gnu,  gcc-2.95 19990606 says

a.cc: In function `int main()':
a.cc:12: redeclaration of `struct QColor QRgb'
a.cc:12: `struct QColor QRgb' previously declared here

It somehow thinks this is a declaration. I don't think so :-)

Regards,
Martin
>From andris@stargate.astr.lu.lv Tue Jun 08 00:42:00 1999
From: Andris Pavenis <andris@stargate.astr.lu.lv>
To: djgpp-workers@delorie.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: problem with data alignment with egcs-19990602
Date: Tue, 08 Jun 1999 00:42:00 -0000
Message-id: <99060810411500.00968@hal>
References: <99060717171200.00403@hal>
X-SW-Source: 1999-06/msg00190.html
Content-length: 2590

Problem seems to be related with use of #pragma pack():
	I had to put definition of some structures between
		#pragma pack(1)
	and
		#pragma pack()

It looks that with gcc 2.95 tree the second line (#pragma pack())
is ignored and as result I'm getting wrong code.
	- using __attribute__(packed) instead fixes the problem
	- no changes needed for egcs-1.1.2 (#pragma pack() works
	   as I expect)

Below is simple test example that ilustrates the problem

----------------------------------------------------
#include <stdio.h>
#include <assert.h>


#pragma pack(1)
#pragma pack()


class  Test1
  {
  public:
      char a;
      long b;
      Test1 (void)
        {
	    printf ("%p\n",(((char *) & b)-((char *) & a)));
	}
  };
  
  
int main (void)
  {
      Test1 x;
      return 0;
  }
  
----------------------------------------------------		
With gcc-1.1.2 I'm getting output 4
With gcc-2.95 prerelease I'm getting 1

So we should either have a warning from compiler that #pragma pack()
should not be used or this problem must be fixed

Andris


On Mon, 07 Jun 1999, Andris Pavenis wrote:
> On Mon, 07 Jun 1999, pavenis@lanet.lv wrote:
> > 	compiler generates code which access class member
> > 	via wrong address (result is SIGSEGV for me). Below is 		
> > 	some test data I got (I simply copied this from rhide watch 
> > 	window and added some comments)
> > 
> >  this: (TEphApp *) 0x240f20
> >  App: (TEphApp *) 0x240f20
> >  &slrcfg: (LoadedConfigFile *) 0x240f84
> >  &App->slrcfg: (LoadedConfigFile *) 0x240f84
> >  &satinfo: (LoadedConfigFile *) 0x240fa5             - false address 
> > 	 (but this address is used both when I call satinfo.foo() and
> > 	App->satinfo.foo() (name changed) from member function)
> >  &(App->satinfo): (LoadedConfigFile *) 0x240fa8   - right value (I can 
> >       get contents here)
> > 
> > I have this problem in rather big application (TVision + different 
> > other stuff, TEphApp is derived from TApplication such stuff as
> > virtual base classes etc is present) only.
> > 
> > I tried to reproduce this problem in a simple test example but didn't 
> > succeed. Perhaps I'll check the same sometime under Linux as this
> > app can be built (and it should normally work) also under Linux.
> > 
> 
> I reproduced the same thing with egcs-19990601 (I updated gcc 2.95
> branch with CVS then) under Linux (kernel 2.2.9, glibc-2.1.1). 
> As I don't have good test example to send then perhaps I'll retry the same
> with later snapshots. Perhaps it would be worth to try also with
> gcc-2.96 tree to see whether something changes.
> 
> Andris
>From mr@forstware.de Tue Jun 08 05:10:00 1999
From: Marcel Ruff <mr@forstware.de>
To: egcs-bugs@egcs.cygnus.com
Subject: gcc-2.95 19990602:  undefined symbol: __check_eh_spec
Date: Tue, 08 Jun 1999 05:10:00 -0000
Message-id: <375CF93B.8F6586FE@forstware.de>
X-SW-Source: 1999-06/msg00191.html
Content-length: 1024

Hi,

im using the 19990602 snapshot, but when starting my application i get
following error:
(running Linux  2.2.5, glibc 2.0.x)

bin> kpl.exe
kpl.exe: error in loading shared libraries
: undefined symbol: __check_eh_spec


bin> ldd kpl.exe
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40008000)
        libpng.so.2 => /usr/X11R6/lib/libpng.so.2 (0x400ad000)
        libz.so.1 => /usr/lib/libz.so.1 (0x400ca000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0x400da000)
        libdl.so.2 => /lib/libdl.so.2 (0x4010d000)
        libm.so.6 => /lib/libm.so.6 (0x40111000)
        libstdc++-libc6.0-1.so.2 => /usr/lib/libstdc++-libc6.0-1.so.2
(0x4012d000)
        libc.so.6 => /lib/libc.so.6 (0x4016e000)
        libjpeg.so.6 => /usr/lib/libjpeg.so.6 (0x4021b000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)

/usr/lib# nm -A *.so* | grep __check_eh_spec
        libstdc++.so.2.9:00031b00 T __check_eh_spec
        libstdc++.so.2.9.0:00031b00 T __check_eh_spec

any idea what to do??

thanks, Marcel

Re: C++: Parser regression over 1.1.2

[Franz Sirl]

At 09:03 08.06.99 , Martin v. Loewis wrote:
>In egcs 1.1, we would accept the code
>
>typedef unsigned int QRgb;
>struct QColor{
>   QColor( QRgb rgb);
>};
>
>struct QColorGroup{
>   QColorGroup( const QColor &foreground, const QColor &background);
>};
>
>int main()
>{
>   QColorGroup normal( QColor( QRgb(16711680) ), QColor( QRgb(16777215) ));
>}
>
>On i486-pc-linux-gnu,  gcc-2.95 19990606 says
>
>a.cc: In function `int main()':
>a.cc:12: redeclaration of `struct QColor QRgb'
>a.cc:12: `struct QColor QRgb' previously declared here
>
>It somehow thinks this is a declaration. I don't think so :-)

When will this bug get fixed in gcc-2.95pre? Repeated C++ build tests are 
really annoying with this bug in place.

Franz.

Re: C++: Parser regression over 1.1.2

[Jeffrey A Law]

  In message < 4.2.0.58.19990702120740.03f6d260@mail.lauterbach.com >you write:
  > When will this bug get fixed in gcc-2.95pre? Repeated C++ build tests are 
  > really annoying with this bug in place.
It is entirely possible it may not get fixed.

Every release is going to have some bugs.  That's life.  The question is
how important is this bug.

jeff

Re: C++: Parser regression over 1.1.2

[Franz Sirl]

At 12:22 02.07.99 , Jeffrey A Law wrote:
>   In message < 4.2.0.58.19990702120740.03f6d260@mail.lauterbach.com >you write:
>   > When will this bug get fixed in gcc-2.95pre? Repeated C++ build tests 
> are
>   > really annoying with this bug in place.
>It is entirely possible it may not get fixed.
>
>Every release is going to have some bugs.  That's life.  The question is
>how important is this bug.

If it's not gonna be fixed for 2.95, that's ok too. But til now I've seen 
no will-be-fixed/won't-be-fixed statements on any of the reports (and there 
have been a couple of reports here and on other lists) and I wanted to make 
sure it didn't get lost. Probably worth an FAQ entry then.

Franz.

Re: C++: Parser regression over 1.1.2

[Jeffrey A Law]

  In message < 4.2.0.58.19990702122750.0367e6f0@mail.lauterbach.com >you write:
  > If it's not gonna be fixed for 2.95, that's ok too. But til now I've seen 
  > no will-be-fixed/won't-be-fixed statements on any of the reports (and there
  > have been a couple of reports here and on other lists) and I wanted to make
  > sure it didn't get lost. Probably worth an FAQ entry then.
If it's not already fixed, odds are it is not going to be fixed for this
release.  The number of outstanding bugs we're likely to fix is very small at
this point.

Ask yourself this question -- is this bug serious enough that it is worth
delaying the release.    If not, then it probably will not be fixed in time
for this release.  The only changes I want going into the tree are for bugs
which are serious enough to hold up the release.  They have to be bad enough
that we would be literally embarrassed if we let the code go out the door.

Is it worth an FAQ entry?  I don't know.  We do not try to document every bug
with an FAQ entry.  One might claim that if it is important enough for an FAQ
entry that we may need to fix it.  I know zip about the code you're talking
about, so I have no idea how popular it is and how bad things will be if we
do not fix it.

We should plan on the last non-documentation patch going into the tree within
the next 24 hours so that we can get a snapshot of the gcc-2.95 compiler made
for final testing while we work through the doc and other changes which do
not effect the compiler's behavior.  The last day to get any changes into the
source will probably be the 6th as it takes ~48-72hrs to get enough mirror
coverage to make the release.

Depending on the severity of the bug it may be something we fix for gcc-2.95.1
(it is safe to assume that we will have the usual 2-4 bugfix releases over
the next few months).

jeff

Re: C++: Parser regression over 1.1.2

[Jeffrey A Law]

  In message < 4.2.0.58.19990702133700.03a16410@mail.lauterbach.com >you write:
  > Well, I wonder how you passed the RH-6.0 building tests then?
A few things never passed.  KDE in particular.

  > I thought it was a goal that RH-6.0 should build with gcc-2.95, except
  > for bugs in the sources? And KDE in RH6.0 triggers this a few times. All
  >  other bugs  triggered by RH-6.0 (not counting the PPC specific gen_reload
  >  one) have  been fixed, AFAIK. Has this goal been relaxed?
Goal != requirement.  I would have loved to had this fixed, but other more
pressing stuff had to take priority.  There are only so many hours in each
day, and I've been spending far too many in front of the computer lately.

  > Well, KDE and qt-1.4x are quite popular :-).
I had no problems at all building qt.

  > Ugh, the release is that close? Without any publicly announced beta phase?
We've been in beta for over a month.  What do you think we've been doing since
we branched?


jeff

Re: C++: Parser regression over 1.1.2

[Franz Sirl]

At 11:12 09.07.99 , Jeffrey A Law wrote:
>   In message < 4.2.0.58.19990702133700.03a16410@mail.lauterbach.com >you write:
>   > Well, I wonder how you passed the RH-6.0 building tests then?
>A few things never passed.  KDE in particular.

Yeah, but the other bugs are bugs in the source that have been reported to 
the KDE team (and will be fixed in KDE-1.1.2, I hope). If there is interest 
I can even do a patch set against KDE-1.1.1 to make it mostly gcc-2.95 
safe. Martin helped me a lot on finding out whether it's a source bug or a 
bug in gcc-2.95, and we could resolve every problem, except 1 bug in the 
source and 1 bug in gcc (the parser regression). And that work was finished 
shortly after the branch.

>   > I thought it was a goal that RH-6.0 should build with gcc-2.95, except
>   > for bugs in the sources? And KDE in RH6.0 triggers this a few times. All
>   >  other bugs  triggered by RH-6.0 (not counting the PPC specific 
> gen_reload
>   >  one) have  been fixed, AFAIK. Has this goal been relaxed?
>Goal != requirement.  I would have loved to had this fixed, but other more
>pressing stuff had to take priority.  There are only so many hours in each
>day, and I've been spending far too many in front of the computer lately.

ok, understood. That's why we all try to help you :-). I'll accept without 
complaints if it doesn't get fixed, I just think that it's quite reasonable 
to expect at least this "won't get fixed" feedback on a bug that has been 
reported as a regression compared to egcs-1.1.2.

>   > Well, KDE and qt-1.4x are quite popular :-).
>I had no problems at all building qt.

You are right, building qt is not the problem, but using qt will trigger 
this bug quite often.

>   > Ugh, the release is that close? Without any publicly announced beta 
> phase?
>We've been in beta for over a month.  What do you think we've been doing since
>we branched?

As a developer I agree, as a, hmm, "professional" or "advanced" user I 
don't agree. For these to get their attention to really _use_ a beta 
compiler and get a wider audience, you need to call the snapshots something 
like gcc-2.95pre1 and announce each of the snapshots on Freshmeat and 
similar sites. Otherwise the development after the branch is just like an 
"internal" stabilization phase with the "usual" snapshot/cvs users.

Franz.

Re: C++: Parser regression over 1.1.2

[Franz Sirl]

At 13:02 02.07.99 , Jeffrey A Law wrote:

>   In message < 4.2.0.58.19990702122750.0367e6f0@mail.lauterbach.com >you write:
>   > If it's not gonna be fixed for 2.95, that's ok too. But til now I've 
> seen
>   > no will-be-fixed/won't-be-fixed statements on any of the reports (and 
> there
>   > have been a couple of reports here and on other lists) and I wanted 
> to make
>   > sure it didn't get lost. Probably worth an FAQ entry then.
>If it's not already fixed, odds are it is not going to be fixed for this
>release.  The number of outstanding bugs we're likely to fix is very small at
>this point.

Ok, as I said no problem. Just wanted to know what's going on with this one.


>Ask yourself this question -- is this bug serious enough that it is worth
>delaying the release.    If not, then it probably will not be fixed in time
>for this release.  The only changes I want going into the tree are for bugs
>which are serious enough to hold up the release.  They have to be bad enough
>that we would be literally embarrassed if we let the code go out the door.

Well, I wonder how you passed the RH-6.0 building tests then? I thought it 
was a goal that RH-6.0 should build with gcc-2.95, except for bugs in the 
sources? And KDE in RH6.0 triggers this a few times. All other bugs 
triggered by RH-6.0 (not counting the PPC specific gen_reload one) have 
been fixed, AFAIK. Has this goal been relaxed?

>Is it worth an FAQ entry?  I don't know.  We do not try to document every bug
>with an FAQ entry.  One might claim that if it is important enough for an FAQ
>entry that we may need to fix it.  I know zip about the code you're talking
>about, so I have no idea how popular it is and how bad things will be if we
>do not fix it.

Well, KDE and qt-1.4x are quite popular :-).

>We should plan on the last non-documentation patch going into the tree within
>the next 24 hours so that we can get a snapshot of the gcc-2.95 compiler made
>for final testing while we work through the doc and other changes which do
>not effect the compiler's behavior.  The last day to get any changes into the
>source will probably be the 6th as it takes ~48-72hrs to get enough mirror
>coverage to make the release.

Ugh, the release is that close? Without any publicly announced beta phase?

>Depending on the severity of the bug it may be something we fix for gcc-2.95.1
>(it is safe to assume that we will have the usual 2-4 bugfix releases over
>the next few months).

That's fine with me, as I usually build the branch anyway :-)

Franz.