public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: target/5505: Doubts about a patch for OSF
@ 2002-01-30 6:14 ro
0 siblings, 0 replies; 16+ messages in thread
From: ro @ 2002-01-30 6:14 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, kreckel, nobody, ro, ro
Synopsis: Doubts about a patch for OSF
Responsible-Changed-From-To: unassigned->ro
Responsible-Changed-By: ro
Responsible-Changed-When: Wed Jan 30 06:14:19 2002
Responsible-Changed-Why:
Mine.
State-Changed-From-To: open->feedback
State-Changed-By: ro
State-Changed-When: Wed Jan 30 06:14:19 2002
State-Changed-Why:
Please follow the bug reporting instructions at
http://gcc.gnu.org/bugs.html
and include all the required information (especially how GCC
was configured and a self-contained test case). Without a
testcase demonstrating the problem, I cannot reproduce or
fix this. as, ar, or nm messages out of context (i.e.
without the corresponding source files) don't help here.
Besides, I've been able to build and test CLN 1.1.4 on
alpha-dec-osf5.1 with a copy a gcc 3.0.2 prerelease without
any problems, i.e. make and make check both complete
sucessfully.
The problem may therefore be due not to a gcc problem but
to a as or ld bug. The machine used here is running
Tru64 UNIX V5.1 with Patch Kit 3 installed.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5505
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-05-10 5:36 Rainer Orth
0 siblings, 0 replies; 16+ messages in thread
From: Rainer Orth @ 2002-05-10 5:36 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Richard.Kreckel@Uni-Mainz.DE
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Fri, 10 May 2002 14:26:17 +0200 (MEST)
Richard B. Kreckel writes:
> I just tired the prerelease g++ 3.1 20020422 and it seems to work indeed.
> So, yes, the PR may be closed. BTW, do you have any idea what kind of
fine, thanks for the confirmation.
> interference with -fno-exceptions was triggered by your patch?
Not really: some generic improvements on weak symbol handling went in on
after 3.0.x, but I cannot pinpoint the exact problem.
Rainer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-05-10 5:27 ro
0 siblings, 0 replies; 16+ messages in thread
From: ro @ 2002-05-10 5:27 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, kreckel, ro, ro
Synopsis: Doubts about a patch for OSF
State-Changed-From-To: feedback->closed
State-Changed-By: ro
State-Changed-When: Fri May 10 05:27:15 2002
State-Changed-Why:
confirmed fixed in 3.1 20020422
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5505
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-05-09 10:56 Richard B. Kreckel
0 siblings, 0 replies; 16+ messages in thread
From: Richard B. Kreckel @ 2002-05-09 10:56 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: "Richard B. Kreckel" <kreckel@ginac.de>
To: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Thu, 9 May 2002 19:51:07 +0200 (CEST)
On Tue, 16 Apr 2002, Rainer Orth wrote:
> > > If you have some time, it would be nice if you could confirm the
> > > dependence on -fno-exceptions before I start stripping that down. Thanks!
> >
> > Indeed: the test program works (i.e. doesn't crash) at -O2 and -O1
> > -fno-exceptions, but SEGVs at -O2 -fno-exceptions.
>
> This seems to be fixed in g++ 3.1 20020327: I've sucessfully built the test
> with -O2 -fno-exceptions. As an additional test, I've configured CLN 1.1.4
> with CXXFLAGS='-O2 -fno-exceptions' --disable-shared --without-gmp and all
> tests passed. If you can confirm that this really works for you, the PR
> can be closed.
I just tired the prerelease g++ 3.1 20020422 and it seems to work indeed.
So, yes, the PR may be closed. BTW, do you have any idea what kind of
interference with -fno-exceptions was triggered by your patch?
Regards
-richy.
--
Richard B. Kreckel
<Richard.Kreckel@Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-04-16 10:56 Rainer Orth
0 siblings, 0 replies; 16+ messages in thread
From: Rainer Orth @ 2002-04-16 10:56 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Richard.Kreckel@Uni-Mainz.DE
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Tue, 16 Apr 2002 19:54:58 +0200 (MEST)
Rainer Orth writes:
> > If you have some time, it would be nice if you could confirm the
> > dependence on -fno-exceptions before I start stripping that down. Thanks!
>
> Indeed: the test program works (i.e. doesn't crash) at -O2 and -O1
> -fno-exceptions, but SEGVs at -O2 -fno-exceptions.
This seems to be fixed in g++ 3.1 20020327: I've sucessfully built the test
with -O2 -fno-exceptions. As an additional test, I've configured CLN 1.1.4
with CXXFLAGS='-O2 -fno-exceptions' --disable-shared --without-gmp and all
tests passed. If you can confirm that this really works for you, the PR
can be closed.
Rainer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-02-25 8:58 Rainer Orth
0 siblings, 0 replies; 16+ messages in thread
From: Rainer Orth @ 2002-02-25 8:58 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Richard.Kreckel@Uni-Mainz.DE
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Mon, 25 Feb 2002 17:25:52 +0100 (MET)
Richard B. Kreckel writes:
> Sorry, silly me. I've attached an old case and that index out of bound
> has been fixed in the real sources ages ago. However, the crash I see
> seems to have nothing to do with this line! Modifying the condition such
> that j==0 does not happen still results in a crashing program when
> compiled with -O2 -fno-exceptions and a working program when compiled with
> -O2 alone. There is an example modified accordingly attached to this
> email and this time I have made sure it also runs with -lefence and stuff.
ok, thanks.
> If you have some time, it would be nice if you could confirm the
> dependence on -fno-exceptions before I start stripping that down. Thanks!
Indeed: the test program works (i.e. doesn't crash) at -O2 and -O1
-fno-exceptions, but SEGVs at -O2 -fno-exceptions.
Rainer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-02-23 14:12 Richard B. Kreckel
0 siblings, 0 replies; 16+ messages in thread
From: Richard B. Kreckel @ 2002-02-23 14:12 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: "Richard B. Kreckel" <kreckel@ginac.de>
To: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Sat, 23 Feb 2002 22:03:28 +0100 (CET)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--1569097344-122519837-1014498208=:18949
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
On Fri, 22 Feb 2002, Rainer Orth wrote:
> Richard B. Kreckel writes:
>
> > Rainer, you probably know by now that this whole issue has nothing to do
> > at all with CLN? It seems like your patch breaks anything when using
>
> most likely, yes.
>
> > -fno-exceptions. Attached is a trial program that only uses doubles and
>
> Only in combination with -O2, it seems.
>
> > some STL containers. (Sorry for not boiling it down from 100 to 10 lines,
> > I have unfortunately very little time right now.)
>
> Please try to do so: my knowledge of C++ is close to zero, so a minimal
> testcase would help enormously.
Sure, I will, next week. Sorry, again I am only for a couple of minutes
in my office...
> > Can you confirm this? Otherwise we are back with the theory that my boxen
> > are broken / patched wrongly...
>
> Not yet: I get a SEGV even if compiling without any special options:
>
> > g++ -o minor minor.cc
> > ./minor
> permanent of 6x6-matrix
> c==4Segmentation fault
>
> The crash happens in minor.c, l. 80:
>
> 80 Pkey[j] = Pkey[j-1]+1;
>
> j = 0 at this point, so Pkey[j-1] is out of bounds. The crash happens when
> compiling with Compaq cxx as well.
Sorry, silly me. I've attached an old case and that index out of bound
has been fixed in the real sources ages ago. However, the crash I see
seems to have nothing to do with this line! Modifying the condition such
that j==0 does not happen still results in a crashing program when
compiled with -O2 -fno-exceptions and a working program when compiled with
-O2 alone. There is an example modified accordingly attached to this
email and this time I have made sure it also runs with -lefence and stuff.
If you have some time, it would be nice if you could confirm the
dependence on -fno-exceptions before I start stripping that down. Thanks!
Regards
-richy.
--
Richard B. Kreckel
<Richard.Kreckel@Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
--1569097344-122519837-1014498208=:18949
Content-Type: TEXT/x-c++src; name="minor.cc"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0202232203280.18949@higgs.physik.uni-mainz.de>
Content-Description: minor.cc
Content-Disposition: attachment; filename="minor.cc"
I2luY2x1ZGUgPGNtYXRoPg0KI2luY2x1ZGUgPGlvc3RyZWFtPg0KI2luY2x1
ZGUgPHZlY3Rvcj4NCiNpbmNsdWRlIDxtYXA+DQojaW5jbHVkZSA8YWxnb3Jp
dGhtPg0KdXNpbmcgbmFtZXNwYWNlIHN0ZDsNCg0KaW50IHNpemUgPSA3Ow0K
DQp2b2lkIGluaXQodmVjdG9yPGRvdWJsZT4gJiB2KQ0Kew0KICAgIHYuY2xl
YXIoKTsNCiAgICBmb3IgKGludCBpPTA7IGk8c2l6ZSpzaXplOyArK2kpDQog
ICAgICAgIHYucHVzaF9iYWNrKCgxMC4wKnJhbmQoKSkvKFJBTkRfTUFYKzEu
MCktNS4wKTsNCn0NCg0KZG91YmxlIGRldF9taW5vcihjb25zdCB2ZWN0b3I8
ZG91YmxlPiAmdikNCnsNCiAgICAvLyBmb3Igc21hbGwgbWF0cmljZXMgdGhl
IGFsZ29yaXRobSBkb2VzIG5vdCBtYWtlIHNlbnNlOg0KICAgIGlmIChzaXpl
PT0xKQ0KICAgICAgICByZXR1cm4gdlswXTsNCiAgICBpZiAoc2l6ZT09MikN
CiAgICAgICAgcmV0dXJuIHZbMF0qdlszXS12WzJdKnZbMV07DQogICAgaWYg
KHNpemU9PTMpDQogICAgICAgIHJldHVybiAoKHZbNF0qdls4XS12WzVdKnZb
N10pKnZbMF0tDQogICAgICAgICAgICAgICAgKHZbMV0qdls4XS12WzJdKnZb
N10pKnZbM10rDQogICAgICAgICAgICAgICAgKHZbMV0qdls1XS12WzRdKnZb
Ml0pKnZbNl0pOw0KDQogICAgLy8gd2Ugc3RvcmUgb3VyIHN1Ym1pbm9ycyBp
biB0aGVzZSBjb250YWluZXJzDQogICAgdHlwZWRlZiBtYXA8dmVjdG9yPHVu
c2lnbmVkPixkb3VibGU+IFJtYXA7DQogICAgdHlwZWRlZiBtYXA8dmVjdG9y
PHVuc2lnbmVkPixkb3VibGU+Ojp2YWx1ZV90eXBlIFJtYXBfdmFsdWU7DQog
ICAgUm1hcCBBLCBCOw0KICAgIGRvdWJsZSBkZXQgPSAwLjA7DQogICAgdmVj
dG9yPHVuc2lnbmVkPiBQa2V5OyAgICAvLyBVbmlxdWUgZmxpcHBlciBjb3Vu
dGVyIGZvciB0aGUgcGFydGl0aW9uDQogICAgUGtleS5yZXNlcnZlKHNpemUp
Ow0KICAgIHZlY3Rvcjx1bnNpZ25lZD4gTWtleTsgICAgLy8ga2V5IGZvciBt
aW5vciBkZXRlcm1pbmFudCAoYSBwYXJ0aXRpb24gb2YgUGtleSkNCiAgICBN
a2V5LnJlc2VydmUoc2l6ZS0xKTsNCiAgICAvLyBpbml0aWFsaXplIEEgd2l0
aCBsYXN0IGNvbHVtbjoNCiAgICBmb3IgKHVuc2lnbmVkIHI9MDsgcjxzaXpl
OyArK3IpIHsNCiAgICAgICAgUGtleS5lcmFzZShQa2V5LmJlZ2luKCksUGtl
eS5lbmQoKSk7DQogICAgICAgIFBrZXkucHVzaF9iYWNrKHIpOw0KICAgICAg
ICBBLmluc2VydChSbWFwX3ZhbHVlKFBrZXksdltzaXplKnIrc2l6ZS0xXSkp
Ow0KICAgIH0NCiAgICAvLyBjbG9nIDw8ICJsb29wOiAiIDw8IGVuZGw7DQog
ICAgZm9yIChpbnQgYz1zaXplLTI7IGM+PTA7IC0tYykgew0KICAgICAgY2xv
ZyA8PCAiYz09IiA8PCBjICA8PCBmbHVzaDsNCiAgICAgICAgUGtleS5lcmFz
ZShQa2V5LmJlZ2luKCksUGtleS5lbmQoKSk7ICAvLyBkb24ndCBjaGFuZ2Ug
Y2FwYWNpdHkNCiAgICAgICAgTWtleS5lcmFzZShNa2V5LmJlZ2luKCksTWtl
eS5lbmQoKSk7DQogICAgICAgIGZvciAodW5zaWduZWQgaT0wOyBpPHNpemUt
YzsgKytpKQ0KICAgICAgICAgICAgUGtleS5wdXNoX2JhY2soaSk7DQogICAg
ICAgIHVuc2lnbmVkIGZjID0gMDsgIC8vIGNvbnRyb2xzIGxvZ2ljIGZvciBv
dXIgc3RyYW5nZSBmbGlwcGVyIGNvdW50ZXINCiAgICAgICAgZG8gew0KICAg
ICAgICAgICAgZGV0ID0gMC4wOw0KICAgICAgICAgICAgZm9yICh1bnNpZ25l
ZCByPTA7IHI8c2l6ZS1jOyArK3IpIHsNCiAgICAgICAgICAgICAgICAvLyBt
YXliZSB0aGVyZSBpcyBub3RoaW5nIHRvIGRvPw0KICAgICAgICAgICAgICAg
IGlmICh2W1BrZXlbcl0qc2l6ZStjXT09MC4wKQ0KICAgICAgICAgICAgICAg
ICAgICBjb250aW51ZTsNCiAgICAgICAgICAgICAgICAvLyBjcmVhdGUgdGhl
IHNvcnRlZCBrZXkgZm9yIGFsbCBwb3NzaWJsZSBtaW5vcnMNCiAgICAgICAg
ICAgICAgICBNa2V5LmVyYXNlKE1rZXkuYmVnaW4oKSxNa2V5LmVuZCgpKTsN
CiAgICAgICAgICAgICAgICBmb3IgKHVuc2lnbmVkIGk9MDsgaTxzaXplLWM7
ICsraSkNCiAgICAgICAgICAgICAgICAgICAgaWYgKGkhPXIpDQogICAgICAg
ICAgICAgICAgICAgICAgICBNa2V5LnB1c2hfYmFjayhQa2V5W2ldKTsNCiAg
ICAgICAgICAgICAgICAvLyBmZXRjaCB0aGUgbWlub3JzIGFuZCBjb21wdXRl
IHRoZSBuZXcgZGV0ZXJtaW5hbnQNCiAgICAgICAgICAgICAgICBpZiAociUy
KQ0KICAgICAgICAgICAgICAgICAgICBkZXQgLT0gdltQa2V5W3JdKnNpemUr
Y10qQVtNa2V5XTsNCiAgICAgICAgICAgICAgICBlbHNlDQogICAgICAgICAg
ICAgICAgICAgIGRldCArPSB2W1BrZXlbcl0qc2l6ZStjXSpBW01rZXldOw0K
ICAgICAgICAgICAgfQ0KICAgICAgICAgICAgLy8gU3RvcmUgdGhlIG5ldyBk
ZXRlcm1pbmFudCBhdCBpdHMgcGxhY2UgaW4gQjoNCiAgICAgICAgICAgIGlm
IChkZXQhPTAuMCkNCiAgICAgICAgICAgICAgICBCLmluc2VydChSbWFwX3Zh
bHVlKFBrZXksZGV0KSk7DQogICAgICAgICAgICAvLyBpbmNyZW1lbnQgb3Vy
IHN0cmFuZ2UgZmxpcHBlciBjb3VudGVyDQogICAgICAgICAgICBmb3IgKGZj
PXNpemUtYzsgZmM+MDsgLS1mYykgew0KICAgICAgICAgICAgICAgICsrUGtl
eVtmYy0xXTsNCiAgICAgICAgICAgICAgICBpZiAoUGtleVtmYy0xXTxmYytj
KQ0KICAgICAgICAgICAgICAgICAgICBicmVhazsNCiAgICAgICAgICAgIH0N
CiAgICAgICAgICAgIGlmIChmYzxzaXplLWMgJiYgZmM+MCkNCiAgICAgICAg
ICAgICAgICBmb3IgKHVuc2lnbmVkIGo9ZmM7IGo8c2l6ZS1jOyArK2opDQog
ICAgICAgICAgICAgICAgICAgIFBrZXlbal0gPSBQa2V5W2otMV0rMTsNCiAg
ICAgICAgfSB3aGlsZShmYyk7DQogICAgICAgIC8vIGNoYW5nZSB0aGUgcm9s
ZSBvZiBBIGFuZCBCOg0KICAgICAgICBBID0gQjsNCiAgICAgICAgQi5jbGVh
cigpOw0KCWNsb2cgPDwgZW5kbDsNCiAgICB9DQoNCiAgICByZXR1cm4gZGV0
Ow0KfQ0KDQppbnQgbWFpbih2b2lkKQ0Kew0KICAgIHNyYW5kKCh1bnNpZ25l
ZCl0aW1lKE5VTEwpKTsNCiAgICBkb3VibGUgZDA7DQogICAgdmVjdG9yPGRv
dWJsZT4gbTsNCiAgICBmb3IgKHNpemU9Njsgc2l6ZTwxMTsgKytzaXplKSB7
DQogICAgICAgIGNvdXQgPDwgImRldGVybWluYW50IG9mICIgPDwgc2l6ZSA8
PCAieCIgPDwgc2l6ZSA8PCAiLW1hdHJpeCIgPDwgZW5kbDsNCiAgICAgICAg
Zm9yIChpbnQgaT0wOyBpPDIwOyArK2kpIHsNCiAgICAgICAgICAgIGluaXQo
bSk7DQogICAgICAgICAgICBkMCA9IGRldF9taW5vcihtKTsNCiAgICAgICAg
ICAgIGNvdXQgPDwgZDAgPDwgZW5kbDsNCiAgICAgICAgfQ0KICAgIH0NCn0N
Cg==
--1569097344-122519837-1014498208=:18949--
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-02-22 15:46 Rainer Orth
0 siblings, 0 replies; 16+ messages in thread
From: Rainer Orth @ 2002-02-22 15:46 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Richard.Kreckel@Uni-Mainz.DE
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Fri, 22 Feb 2002 23:13:42 +0100 (MET)
Richard B. Kreckel writes:
> Rainer, you probably know by now that this whole issue has nothing to do
> at all with CLN? It seems like your patch breaks anything when using
most likely, yes.
> -fno-exceptions. Attached is a trial program that only uses doubles and
Only in combination with -O2, it seems.
> some STL containers. (Sorry for not boiling it down from 100 to 10 lines,
> I have unfortunately very little time right now.)
Please try to do so: my knowledge of C++ is close to zero, so a minimal
testcase would help enormously.
> Can you confirm this? Otherwise we are back with the theory that my boxen
> are broken / patched wrongly...
Not yet: I get a SEGV even if compiling without any special options:
> g++ -o minor minor.cc
> ./minor
permanent of 6x6-matrix
c==4Segmentation fault
The crash happens in minor.c, l. 80:
80 Pkey[j] = Pkey[j-1]+1;
j = 0 at this point, so Pkey[j-1] is out of bounds. The crash happens when
compiling with Compaq cxx as well.
Rainer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-02-22 14:16 Rainer Orth
0 siblings, 0 replies; 16+ messages in thread
From: Rainer Orth @ 2002-02-22 14:16 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Richard.Kreckel@Uni-Mainz.DE
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Fri, 22 Feb 2002 23:04:01 +0100 (MET)
Richard B. Kreckel writes:
> Err, while trying to debug into the problem I discovered something
> that had escaped my attantion until now: compiling CLN and an example
> (examples/e, or tests/tests or whatever, never mind) with either -O1, -O2
> or -O1 -g resulted in a working test (the linker warnings are of course
> still present) while -O2 -fno-exceptions produced a crashing program.
> Also, these funny warnings:
> as1: Warning: /tmp/ccb8ZbYD.s, line 6: macro instruction used $at
> appear only when I disable exceptions. I hadn't noticed it so far because
> I *always* export CXXFLAGS="-O2 -fno-exceptions" prior to building
> CLN. May I ask you how you configured and tested CLN? You did not
> specify -fno-exceptions, did you? Does it work when you do so?
I get those warnings and crashing test programs only when configuring with
CXXFLAGS='-fno-exceptions' CPPFLAGS="-DNO_ASM -DNO_PROVIDE_REQUIRE" \
./configure --disable-shared --without-gmp
CXXFLAGS=-fno-exceptions alone still works.
> Anyways, here is a g++ -v output as you requested:
Thanks, nothing unusual here.
Rainer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-02-21 16:21 Richard B. Kreckel
0 siblings, 0 replies; 16+ messages in thread
From: Richard B. Kreckel @ 2002-02-21 16:21 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: "Richard B. Kreckel" <kreckel@ginac.de>
To: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Thu, 21 Feb 2002 22:43:24 +0100 (CET)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--1569097344-1672908506-1014327804=:6702
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
On Wed, 20 Feb 2002, I wrote:
[...]
> Err, while trying to debug into the problem I discovered something
> that had escaped my attantion until now: compiling CLN and an example
> (examples/e, or tests/tests or whatever, never mind) with either -O1, -O2
> or -O1 -g resulted in a working test (the linker warnings are of course
> still present) while -O2 -fno-exceptions produced a crashing program.
> Also, these funny warnings:
> as1: Warning: /tmp/ccb8ZbYD.s, line 6: macro instruction used $at
> appear only when I disable exceptions. I hadn't noticed it so far because
> I *always* export CXXFLAGS="-O2 -fno-exceptions" prior to building
> CLN. May I ask you how you configured and tested CLN? You did not
> specify -fno-exceptions, did you? Does it work when you do so?
Rainer, you probably know by now that this whole issue has nothing to do
at all with CLN? It seems like your patch breaks anything when using
-fno-exceptions. Attached is a trial program that only uses doubles and
some STL containers. (Sorry for not boiling it down from 100 to 10 lines,
I have unfortunately very little time right now.)
Can you confirm this? Otherwise we are back with the theory that my boxen
are broken / patched wrongly...
Regards
-richy.
--
Richard B. Kreckel
<Richard.Kreckel@Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
--1569097344-1672908506-1014327804=:6702
Content-Type: TEXT/x-c++src; name="minor.cc"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0202212243240.6702@higgs.physik.uni-mainz.de>
Content-Description: minor.cc
Content-Disposition: attachment; filename="minor.cc"
I2luY2x1ZGUgPGNtYXRoPg0KI2luY2x1ZGUgPGlvc3RyZWFtPg0KI2luY2x1
ZGUgPHZlY3Rvcj4NCiNpbmNsdWRlIDxtYXA+DQojaW5jbHVkZSA8YWxnb3Jp
dGhtPg0KdXNpbmcgbmFtZXNwYWNlIHN0ZDsNCg0KaW50IHNpemUgPSA3Ow0K
DQp2b2lkIGluaXQodmVjdG9yPGRvdWJsZT4gJiB2KQ0Kew0KICAgIHYuY2xl
YXIoKTsNCiAgICBmb3IgKGludCBpPTA7IGk8c2l6ZSpzaXplOyArK2kpDQog
ICAgICAgIHYucHVzaF9iYWNrKCgxMC4wKnJhbmQoKSkvKFJBTkRfTUFYKzEu
MCktNS4wKTsNCn0NCg0KZG91YmxlIGRldF9taW5vcihjb25zdCB2ZWN0b3I8
ZG91YmxlPiAmdikNCnsNCiAgICAvLyBmb3Igc21hbGwgbWF0cmljZXMgdGhl
IGFsZ29yaXRobSBkb2VzIG5vdCBtYWtlIHNlbnNlOg0KICAgIGlmIChzaXpl
PT0xKQ0KICAgICAgICByZXR1cm4gdlswXTsNCiAgICBpZiAoc2l6ZT09MikN
CiAgICAgICAgcmV0dXJuIHZbMF0qdlszXS12WzJdKnZbMV07DQogICAgaWYg
KHNpemU9PTMpDQogICAgICAgIHJldHVybiAoKHZbNF0qdls4XS12WzVdKnZb
N10pKnZbMF0tDQogICAgICAgICAgICAgICAgKHZbMV0qdls4XS12WzJdKnZb
N10pKnZbM10rDQogICAgICAgICAgICAgICAgKHZbMV0qdls1XS12WzRdKnZb
Ml0pKnZbNl0pOw0KDQogICAgLy8gd2Ugc3RvcmUgb3VyIHN1Ym1pbm9ycyBp
biB0aGVzZSBjb250YWluZXJzDQogICAgdHlwZWRlZiBtYXA8dmVjdG9yPHVu
c2lnbmVkPixkb3VibGU+IFJtYXA7DQogICAgdHlwZWRlZiBtYXA8dmVjdG9y
PHVuc2lnbmVkPixkb3VibGU+Ojp2YWx1ZV90eXBlIFJtYXBfdmFsdWU7DQog
ICAgUm1hcCBBLCBCOw0KICAgIGRvdWJsZSBkZXQgPSAwLjA7DQogICAgdmVj
dG9yPHVuc2lnbmVkPiBQa2V5OyAgICAvLyBVbmlxdWUgZmxpcHBlciBjb3Vu
dGVyIGZvciB0aGUgcGFydGl0aW9uDQogICAgUGtleS5yZXNlcnZlKHNpemUp
Ow0KICAgIHZlY3Rvcjx1bnNpZ25lZD4gTWtleTsgICAgLy8ga2V5IGZvciBt
aW5vciBkZXRlcm1pbmFudCAoYSBwYXJ0aXRpb24gb2YgUGtleSkNCiAgICBN
a2V5LnJlc2VydmUoc2l6ZS0xKTsNCiAgICAvLyBpbml0aWFsaXplIEEgd2l0
aCBsYXN0IGNvbHVtbjoNCiAgICBmb3IgKHVuc2lnbmVkIHI9MDsgcjxzaXpl
OyArK3IpIHsNCiAgICAgICAgUGtleS5lcmFzZShQa2V5LmJlZ2luKCksUGtl
eS5lbmQoKSk7DQogICAgICAgIFBrZXkucHVzaF9iYWNrKHIpOw0KICAgICAg
ICBBLmluc2VydChSbWFwX3ZhbHVlKFBrZXksdltzaXplKnIrc2l6ZS0xXSkp
Ow0KICAgIH0NCiAgICAvLyBjbG9nIDw8ICJsb29wOiAiIDw8IGVuZGw7DQog
ICAgZm9yIChpbnQgYz1zaXplLTI7IGM+PTA7IC0tYykgew0KICAgICAgICBj
bG9nIDw8ICJjPT0iIDw8IGMgIDw8IGZsdXNoOw0KICAgICAgICBQa2V5LmVy
YXNlKFBrZXkuYmVnaW4oKSxQa2V5LmVuZCgpKTsgIC8vIGRvbid0IGNoYW5n
ZSBjYXBhY2l0eQ0KICAgICAgICBNa2V5LmVyYXNlKE1rZXkuYmVnaW4oKSxN
a2V5LmVuZCgpKTsNCiAgICAgICAgZm9yICh1bnNpZ25lZCBpPTA7IGk8c2l6
ZS1jOyArK2kpDQogICAgICAgICAgICBQa2V5LnB1c2hfYmFjayhpKTsNCiAg
ICAgICAgdW5zaWduZWQgZmMgPSAwOyAgLy8gY29udHJvbHMgbG9naWMgZm9y
IG91ciBzdHJhbmdlIGZsaXBwZXIgY291bnRlcg0KICAgICAgICBkbyB7DQog
ICAgICAgICAgICBkZXQgPSAwLjA7DQogICAgICAgICAgICBmb3IgKHVuc2ln
bmVkIHI9MDsgcjxzaXplLWM7ICsrcikgew0KICAgICAgICAgICAgICAgIC8v
IG1heWJlIHRoZXJlIGlzIG5vdGhpbmcgdG8gZG8/DQogICAgICAgICAgICAg
ICAgaWYgKHZbUGtleVtyXSpzaXplK2NdPT0wLjApDQogICAgICAgICAgICAg
ICAgICAgIGNvbnRpbnVlOw0KICAgICAgICAgICAgICAgIC8vIGNyZWF0ZSB0
aGUgc29ydGVkIGtleSBmb3IgYWxsIHBvc3NpYmxlIG1pbm9ycw0KICAgICAg
ICAgICAgICAgIE1rZXkuZXJhc2UoTWtleS5iZWdpbigpLE1rZXkuZW5kKCkp
Ow0KICAgICAgICAgICAgICAgIGZvciAodW5zaWduZWQgaT0wOyBpPHNpemUt
YzsgKytpKQ0KICAgICAgICAgICAgICAgICAgICBpZiAoaSE9cikNCiAgICAg
ICAgICAgICAgICAgICAgICAgIE1rZXkucHVzaF9iYWNrKFBrZXlbaV0pOw0K
ICAgICAgICAgICAgICAgIC8vIGZldGNoIHRoZSBtaW5vcnMgYW5kIGNvbXB1
dGUgdGhlIG5ldyBkZXRlcm1pbmFudA0KICAgICAgICAgICAgICAgIGlmIChy
JTIpDQogICAgICAgICAgICAgICAgICAgIGRldCAtPSB2W1BrZXlbcl0qc2l6
ZStjXSpBW01rZXldOw0KICAgICAgICAgICAgICAgIGVsc2UNCiAgICAgICAg
ICAgICAgICAgICAgZGV0ICs9IHZbUGtleVtyXSpzaXplK2NdKkFbTWtleV07
DQogICAgICAgICAgICB9DQogICAgICAgICAgICAvLyBTdG9yZSB0aGUgbmV3
IGRldGVybWluYW50IGF0IGl0cyBwbGFjZSBpbiBCOg0KICAgICAgICAgICAg
aWYgKGRldCE9MC4wKQ0KICAgICAgICAgICAgICAgIEIuaW5zZXJ0KFJtYXBf
dmFsdWUoUGtleSxkZXQpKTsNCiAgICAgICAgICAgIC8vIGluY3JlbWVudCBv
dXIgc3RyYW5nZSBmbGlwcGVyIGNvdW50ZXINCiAgICAgICAgICAgIGZvciAo
ZmM9c2l6ZS1jOyBmYz4wOyAtLWZjKSB7DQogICAgICAgICAgICAgICAgKytQ
a2V5W2ZjLTFdOw0KICAgICAgICAgICAgICAgIGlmIChQa2V5W2ZjLTFdPGZj
K2MpDQogICAgICAgICAgICAgICAgICAgIGJyZWFrOw0KICAgICAgICAgICAg
fQ0KICAgICAgICAgICAgaWYgKGZjPHNpemUtYykNCiAgICAgICAgICAgICAg
ICBmb3IgKHVuc2lnbmVkIGo9ZmM7IGo8c2l6ZS1jOyArK2opDQogICAgICAg
ICAgICAgICAgICAgIFBrZXlbal0gPSBQa2V5W2otMV0rMTsNCiAgICAgICAg
fSB3aGlsZShmYyk7DQogICAgICAgIC8vIGNoYW5nZSB0aGUgcm9sZSBvZiBB
IGFuZCBCOg0KICAgICAgICBBID0gQjsNCiAgICAgICAgQi5jbGVhcigpOw0K
CWNsb2cgPDwgZW5kbDsNCiAgICB9DQoNCiAgICByZXR1cm4gZGV0Ow0KfQ0K
DQppbnQgbWFpbih2b2lkKQ0Kew0KICAgIHNyYW5kKCh1bnNpZ25lZCl0aW1l
KE5VTEwpKTsNCiAgICBkb3VibGUgZDA7DQogICAgdmVjdG9yPGRvdWJsZT4g
bTsNCiAgICBmb3IgKHNpemU9Njsgc2l6ZTwxMTsgKytzaXplKSB7DQogICAg
ICAgIGNvdXQgPDwgInBlcm1hbmVudCBvZiAiIDw8IHNpemUgPDwgIngiIDw8
IHNpemUgPDwgIi1tYXRyaXgiIDw8IGVuZGw7DQogICAgICAgIGZvciAoaW50
IGk9MDsgaTwyMDsgKytpKSB7DQogICAgICAgICAgICBpbml0KG0pOw0KICAg
ICAgICAgICAgZDAgPSBkZXRfbWlub3IobSk7DQogICAgICAgICAgICBjb3V0
IDw8IGQwIDw8IGVuZGw7DQogICAgICAgIH0NCiAgICB9DQp9DQo=
--1569097344-1672908506-1014327804=:6702--
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-02-20 9:36 Richard B. Kreckel
0 siblings, 0 replies; 16+ messages in thread
From: Richard B. Kreckel @ 2002-02-20 9:36 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: "Richard B. Kreckel" <kreckel@ginac.de>
To: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Wed, 20 Feb 2002 18:16:41 +0100 (CET)
Hi,
On Tue, 19 Feb 2002, Rainer Orth wrote:
[...]
> two things: please provide g++ -v output for some individual compilation of
> CLN, so I can see exactly how gcc was configured.
>
> Besides, could you run one of the crashing programs (tests/tests or
> tests/exam, I suppose) under ladebug to get at least an idea where it
> crashes? While older versions of ladebug simply bail out on gcc compiled
> code with stabs-in-ECOFF debugging information, recent versions recognize
> and ignore it, but should get you a stack trace. If this leads nowhere,
> we might be able to get some further debugging done with a copy of gdb 5.0
> hacked up to somewhat work on 5.1.
Err, while trying to debug into the problem I discovered something
that had escaped my attantion until now: compiling CLN and an example
(examples/e, or tests/tests or whatever, never mind) with either -O1, -O2
or -O1 -g resulted in a working test (the linker warnings are of course
still present) while -O2 -fno-exceptions produced a crashing program.
Also, these funny warnings:
as1: Warning: /tmp/ccb8ZbYD.s, line 6: macro instruction used $at
appear only when I disable exceptions. I hadn't noticed it so far because
I *always* export CXXFLAGS="-O2 -fno-exceptions" prior to building
CLN. May I ask you how you configured and tested CLN? You did not
specify -fno-exceptions, did you? Does it work when you do so?
Anyways, here is a g++ -v output as you requested:
micky:~/src/patch358/cln-1.1.4/src$ g++ -v -O -I/homes/iphuthep/kreckel/DUX4/include -I../include -I./integer -I./base/digitseq -I./base/digit -Ibase -I./base -c ./integer/ring/cl_0_ring.cc -o cl_0_ring.o
Reading specs from /homes/iphuthep/kreckel/DUX4/lib/gcc-lib/alphaev67-dec-osf5.1/3.0.3/specs
Configured with: ../gcc-3.0.3/configure --prefix=/homes/iphuthep/kreckel/DUX4
Thread model: single
gcc version 3.0.3
/homes/iphuthep/kreckel/DUX4/lib/gcc-lib/alphaev67-dec-osf5.1/3.0.3/cc1plus -v -I/homes/iphuthep/kreckel/DUX4/include -I../include -I./integer -I./base/digitseq -I./base/digit -Ibase -I./base -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=3 -Dunix -D__osf__ -D_LONGLONG -DSYSTYPE_BSD -D_SYSTYPE_BSD -D__unix__ -D__osf__ -D_LONGLONG -D__SYSTYPE_BSD__ -D_SYSTYPE_BSD -D__unix -D__SYSTYPE_BSD -Asystem=unix -Asystem=xpg4 -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -D__LANGUAGE_C_PLUS_PLUS__ -D__LANGUAGE_C_PLUS_PLU S -D__cplusplus -Acpu=alpha -Amachine=alpha -D__alpha -D__alpha__ -D__alpha_ev6__ -Acpu=ev6 -D__alpha_bwx__ -Acpu=bwx -D__alpha_max__ -Acpu=max -D__alpha_fix__ -Acpu=fix -D__alpha_cix__ -Acpu=cix -D__X_FLOAT ./integer/ring/cl_0_ring.cc -D__GNUG__=3 -D__GXX_DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -quiet -dumpbase cl_0_ring.cc -O -version -o /tmp/ccHKnWKP.s
GNU CPP version 3.0.3 (cpplib)
GNU C++ version 3.0.3 (alphaev67-dec-osf5.1)
compiled by GNU C version 3.0.3.
ignoring nonexistent directory "/homes/iphuthep/kreckel/DUX4/alphaev67-dec-osf5.1/include"
ignoring duplicate directory "base"
#include "..." search starts here:
#include <...> search starts here:
/homes/iphuthep/kreckel/DUX4/include
../include
integer
base/digitseq
base/digit
base
/homes/iphuthep/kreckel/DUX4/include/g++-v3
/homes/iphuthep/kreckel/DUX4/include/g++-v3/alphaev67-dec-osf5.1
/homes/iphuthep/kreckel/DUX4/include/g++-v3/backward
/usr/local/include
/homes/iphuthep/kreckel/DUX4/lib/gcc-lib/alphaev67-dec-osf5.1/3.0.3/include
/usr/include
End of search list.
as -g -oldas -c -nocpp -O0 -o cl_0_ring.o /tmp/ccHKnWKP.s
/homes/iphuthep/kreckel/DUX4/lib/gcc-lib/alphaev67-dec-osf5.1/3.0.3/mips-tfile -v -o cl_0_ring.o /tmp/ccHKnWKP.s
mips-tfile version 3.0.3
Regards
-richy.
--
Richard B. Kreckel
<Richard.Kreckel@Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-02-19 5:26 Rainer Orth
0 siblings, 0 replies; 16+ messages in thread
From: Rainer Orth @ 2002-02-19 5:26 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Richard.Kreckel@Uni-Mainz.DE
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Tue, 19 Feb 2002 14:16:13 +0100 (MET)
Richard B. Kreckel writes:
> Sigh. Finally they have patched the machine up to ld from patch 358 --
> sorry it took so long. Unfortunately, the problem does not go away. I
> have bootstrapped gcc-3.0.3 and compiled CLN from scratch and it still
> complains about multiple symbols and crashes upon execution.
>
> So I have still no idea what is needed for gcc to function properly and,
> hence, cannot provide a proper documentation patch. I'm afraid, this is
> as good as it gets, unless somebody can come up with an educated guess
> what to try next.
two things: please provide g++ -v output for some individual compilation of
CLN, so I can see exactly how gcc was configured.
Besides, could you run one of the crashing programs (tests/tests or
tests/exam, I suppose) under ladebug to get at least an idea where it
crashes? While older versions of ladebug simply bail out on gcc compiled
code with stabs-in-ECOFF debugging information, recent versions recognize
and ignore it, but should get you a stack trace. If this leads nowhere,
we might be able to get some further debugging done with a copy of gdb 5.0
hacked up to somewhat work on 5.1.
Rainer
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-02-18 12:56 Richard B. Kreckel
0 siblings, 0 replies; 16+ messages in thread
From: Richard B. Kreckel @ 2002-02-18 12:56 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: "Richard B. Kreckel" <kreckel@ginac.de>
To: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Mon, 18 Feb 2002 21:49:22 +0100 (CET)
On Mon, 4 Feb 2002, Richard B. Kreckel wrote:
> On Mon, 4 Feb 2002, Rainer Orth wrote:
> > Fine. Instead of patching the whole machine, it should be sufficient to
> > just drop a copy of the patched ld in
> > $prefix/lib/gcc-lib/alpha-dec-osf5.1/3.0.4/ld.
>
> The machine isn't operated by myself, unfortunately. I have to wait for a
> planned downtime tomorrow. Then, the machine will be patched.
>
> [...]
> > I've re-bootstrapped GCC 3.0.4 20020129 with no regressions compared to
> > 3.0.2 20010921, and this version still creates a working CLN 1.1.4 which
> > passes make check. I've even tried to drop the Tru64 UNIX V5.1 ld (before
> > any patches) into the gcc tree as mentioned above and rebuilt CLN, which
> > keeps working. This may mean that ld isn't the culprit or the error only
> > happens when linking libstdc++.
>
> Thanks for this piece of information. After our last email I had grown
> suspicious, too, about ld being the only reason for this failure...
Sigh. Finally they have patched the machine up to ld from patch 358 --
sorry it took so long. Unfortunately, the problem does not go away. I
have bootstrapped gcc-3.0.3 and compiled CLN from scratch and it still
complains about multiple symbols and crashes upon execution.
So I have still no idea what is needed for gcc to function properly and,
hence, cannot provide a proper documentation patch. I'm afraid, this is
as good as it gets, unless somebody can come up with an educated guess
what to try next.
Regards
-richy.
--
Richard B. Kreckel
<Richard.Kreckel@Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-02-04 11:06 Richard B. Kreckel
0 siblings, 0 replies; 16+ messages in thread
From: Richard B. Kreckel @ 2002-02-04 11:06 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: "Richard B. Kreckel" <kreckel@ginac.de>
To: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Mon, 4 Feb 2002 17:08:17 +0100 (CET)
On Mon, 4 Feb 2002, Rainer Orth wrote:
> Fine. Instead of patching the whole machine, it should be sufficient to
> just drop a copy of the patched ld in
> $prefix/lib/gcc-lib/alpha-dec-osf5.1/3.0.4/ld.
The machine isn't operated by myself, unfortunately. I have to wait for a
planned downtime tomorrow. Then, the machine will be patched.
[...]
> I've re-bootstrapped GCC 3.0.4 20020129 with no regressions compared to
> 3.0.2 20010921, and this version still creates a working CLN 1.1.4 which
> passes make check. I've even tried to drop the Tru64 UNIX V5.1 ld (before
> any patches) into the gcc tree as mentioned above and rebuilt CLN, which
> keeps working. This may mean that ld isn't the culprit or the error only
> happens when linking libstdc++.
Thanks for this piece of information. After our last email I had grown
suspicious, too, about ld being the only reason for this failure...
Regards
-richy.
--
Richard B. Kreckel
<Richard.Kreckel@Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: target/5505: Doubts about a patch for OSF
@ 2002-02-04 11:06 Rainer Orth
0 siblings, 0 replies; 16+ messages in thread
From: Rainer Orth @ 2002-02-04 11:06 UTC (permalink / raw)
To: ro; +Cc: gcc-prs
The following reply was made to PR target/5505; it has been noted by GNATS.
From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Richard.Kreckel@Uni-Mainz.DE
Cc: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>, gcc-bugs@gcc.gnu.org,
gcc-gnats@gcc.gnu.org
Subject: Re: target/5505: Doubts about a patch for OSF
Date: Mon, 4 Feb 2002 16:56:37 +0100 (MET)
Richard B. Kreckel writes:
[Please keep gcc-gnats on the Cc: so the whole thread gets archived in
GNATS as well. Thanks.]
> Hmm, `as' is also from OSFCMPLRS510. But `ld' is more and more becoming a
> suspect: mine are from OSFBASE510 (i.e. no patch) and from
> OSFPAT00007200510 (i.e. an older patch), respectively. Maybe I can get
> hold of OSFPAT00035800510 patch and see if it solves the problems. Not
> sure, though, when this can happen... I'll keep you informed.
Fine. Instead of patching the whole machine, it should be sufficient to
just drop a copy of the patched ld in
$prefix/lib/gcc-lib/alpha-dec-osf5.1/3.0.4/ld.
> > As I said, make and make check both passed with the above snapshot. I can
> > try a fresh bootstrap from current 3.0 branch sources, just to make sure,
> > but this may take some time.
>
> Maybe that would be helpful, just to make sure. As I said: I can revert
> your patch from either GCC 3.0.{1,2,3} and it works. The point being
> other interferences are not very likely...
I've re-bootstrapped GCC 3.0.4 20020129 with no regressions compared to
3.0.2 20010921, and this version still creates a working CLN 1.1.4 which
passes make check. I've even tried to drop the Tru64 UNIX V5.1 ld (before
any patches) into the gcc tree as mentioned above and rebuilt CLN, which
keeps working. This may mean that ld isn't the culprit or the error only
happens when linking libstdc++.
Rainer
^ permalink raw reply [flat|nested] 16+ messages in thread
* target/5505: Doubts about a patch for OSF
@ 2002-01-27 6:26 kreckel
0 siblings, 0 replies; 16+ messages in thread
From: kreckel @ 2002-01-27 6:26 UTC (permalink / raw)
To: gcc-gnats; +Cc: ro
>Number: 5505
>Category: target
>Synopsis: Doubts about a patch for OSF
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Jan 27 06:26:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Richard B. Kreckel
>Release: gcc-3.0.1, gcc-3.0.2, gcc-3.0.3
>Organization:
>Environment:
alphaev5-dec-osf5.1
>Description:
This patch:
> Mon Jul 16 19:57:19 2001 Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
>
> * config/alpha/osf.h (ASM_OUTPUT_WEAK_ALIAS, ASM_WEAKEN_LABEL,
> HANDLE_SYSV_PRAGMA): Define.
> * mips-tfile.c (add_ext_symbol): Pass complete symbol ptr, inline
> previous args.
> (copy_object): Caller changed.
>
> testsuite:
> * g++.old-deja/g++.pt/static3.C: Removed alpha*-*-osf* XFAIL.
> g++.old-deja/g++.pt/static6.C: Likewise.
> * lib/target-supports.exp (check_weak_available): alpha*-*-osf*
> supports weak symbols.
[...]
seems to break the CLN library [0] on `alphaev5-dec-osf5.1'. The
patch went into GCC 3.0.1 and is still there in GCC 3.0.3. I have
reverted it from an otherwise vanilla GCC 3.0.1, 3.0.2 and 3.0.3,
bootstrapped that and everything works fine again.
The symptoms during compilation are:
With a vanilla g++ I frequently get obscure warnings like this one:
as1: Warning: /tmp/ccL7IbTO.s, line 6: macro instruction used $at
whereas with the patch reverted I don't see any of these. These are
still mere warnings, though...
When creating the static library with the vanilla compiler I find that it
is 8% larger than with the patch reverted and I also get tons of warnings
of this kind:
ar: Warning: ignoring second definition of _ZN3cln8NDS_to_IEPKmm defined in archive
Having a look at the .o files where that symbol occurs reveals this
difference:
vanilla: nm cl_I_from_UDS.o
Name Value Type Size
[...]
_ZN3cln15cl_class_bignumE | 0000000000000000 | U | 0000000000000000
_ZN3cln8NDS_to_IEPKmm | 0000000000000144 | T | 0000000000000008
[...]
reverted: nm cl_I_from_UDS.o
Name Value Type Size
[...]
_ZN3cln15cl_class_bignumE | 0000000000000000 | U | 0000000000000000
_ZN3cln8NDS_to_IEPKmm | 0000000000000144 | t | 0000000000000008
_ZN3cln8NDS_to_IEPKmm | 0000000000000000 | N | 0000000000000000
[...]
The offending text symbol `_ZN3cln8NDS_to_IEPKmm' demangles to
`cln::NDS_to_I(unsigned long const*, unsigned long)'. Should it not
be a weak symbol, as is in the reverted case, since it is inlined? Is
it okay to mark it .globl and .weakext? Enabling the weak #pragma
with this patch (which isn't used in the library) shouldn't change
this, should it?
When linking any executable against the library I get zillions of
warnings "weak symbol multiply defined", which may just be a problem
of the linker. But then again: why are there duplicates if above
we were told that the second definition is ignored?
Most worrying: all executables still build but simply segfault
immediately after calling into the library.
Could somebody with better knowledge of this stuff please review the
patch and comment on what may be going on there? Unfortunately, I am
unable to get gdb to run on this system, otherwise I would have
debugged further. I would even do so if somebody tells me where to
start but right now I'm completely stuck.
Regards
-richy.
[0] <http://www.gnu.org/directory/CLN.html>
>How-To-Repeat:
If someone wants to give it a sad try, I recommend to configure CLN
as simple as possible, i.e.:
$ export CPPFLAGS="-DNO_ASM -DNO_PROVIDE_REQUIRE"
$ ./configure --disable-shared --without-gmp
>Fix:
Remove the patch mentioned above.
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2002-05-10 12:36 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-01-30 6:14 target/5505: Doubts about a patch for OSF ro
-- strict thread matches above, loose matches on Subject: below --
2002-05-10 5:36 Rainer Orth
2002-05-10 5:27 ro
2002-05-09 10:56 Richard B. Kreckel
2002-04-16 10:56 Rainer Orth
2002-02-25 8:58 Rainer Orth
2002-02-23 14:12 Richard B. Kreckel
2002-02-22 15:46 Rainer Orth
2002-02-22 14:16 Rainer Orth
2002-02-21 16:21 Richard B. Kreckel
2002-02-20 9:36 Richard B. Kreckel
2002-02-19 5:26 Rainer Orth
2002-02-18 12:56 Richard B. Kreckel
2002-02-04 11:06 Richard B. Kreckel
2002-02-04 11:06 Rainer Orth
2002-01-27 6:26 kreckel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).