This is the mail archive of the
mailing list for the GCC project.
Re: Segmentation fault building libg++ without named returns
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Subject: Re: Segmentation fault building libg++ without named returns
- From: Manfred Hollstein <manfredh at redhat dot com>
- Date: Sun, 10 Sep 2000 11:55:06 +0200 (MEST)
- Cc: gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- References: <firstname.lastname@example.org><200009092206.SAA12592@hiauly1.hia.nrc.ca>
- Reply-To: Manfred Hollstein <manfred dot h at gmx dot net>
On Saturday, 9 September 2000, 18:06:51 -0400, email@example.com wrote:
> > Thanks for the patch you sent with your previous email; I observed the
> > same failures when Mark installed his patch to warn about using named
> > return values. I took a differend approach than you, i.e. instead of
> > removing the code completely, I used the opposite logic with a flag
> > _G_USE_NRV as opposed to the former _G_NO_NRV; I've attached that
> > patch to this email.
> I tend to think the code should be removed. There were essentially two
> sets with the "same" code.
I agree; however, I'll keep the code for some time, at least until it's
working again with the current gcc versions.... and until I've checked
the _NO_NRV code works with older compilers, too.
> However, the unused branch which didn't use
> named returns had rotted a bit. Apparently, `and', `or' and `xor' are
> c++ diagraphs and can't be used.
Yup, my fix included patches for this also.
> > Regarding the missing weak symbols, I'm pretty much at a loss;
> > building Fix.cc and Rational.cc doesn't generate all required weak
> > symbols as it did before; even worse, using a reduced test case
> > doesn't fail to generate those symbols... I'll dig further and keep
> > you informed.
> I don't have any time this weekend to work on it but I think a first
> step would be to dump the assembly code for Fix.cc and see what is
> happening with respect to the week definitions.
I did already, they aren't even emitted...
> Then, looking at the
> rtl may help to pinpoint where things are going wrong. It's a fairly
> recent change to the compiler that has caused the problem.
> J. David Anglin firstname.lastname@example.org
> National Research Council of Canada (613) 990-0752 (FAX: 952-6605)