Re: target/5505: Doubts about a patch for OSF

Re: target/5505: Doubts about a patch for OSF

[Rainer Orth]

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

Re: target/5505: Doubts about a patch for OSF

[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

Re: target/5505: Doubts about a patch for OSF

[Richard B. Kreckel]

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/>
 
 

Re: target/5505: Doubts about a patch for OSF

[Rainer Orth]

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

Re: target/5505: Doubts about a patch for OSF

[Rainer Orth]

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
 

Re: target/5505: Doubts about a patch for OSF

[Richard B. Kreckel]

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--

Re: target/5505: Doubts about a patch for OSF

[Rainer Orth]

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

Re: target/5505: Doubts about a patch for OSF

[Rainer Orth]

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

Re: target/5505: Doubts about a patch for OSF

[Richard B. Kreckel]

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--

Re: target/5505: Doubts about a patch for OSF

[Richard B. Kreckel]

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/>
 
 

Re: target/5505: Doubts about a patch for OSF

[Rainer Orth]

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
 

Re: target/5505: Doubts about a patch for OSF

[Richard B. Kreckel]

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/>
 
 

Re: target/5505: Doubts about a patch for OSF

[Richard B. Kreckel]

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/>
 
 

Re: target/5505: Doubts about a patch for OSF

[Rainer Orth]

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
 

Re: target/5505: Doubts about a patch for OSF

[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

target/5505: Doubts about a patch for OSF

[kreckel]

>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: