I'cant believe what I heard from IBM France
Benoit Dupont de Dinechin
I get the following message with xlC:
make
xlC -DXLC_BUGS -O -I.. -I../../MapLib -o Central Central.C AlphaEv4.o C3.a
xlC: 1501-224 fatal error in /usr/lpp/xlC/bin/C++inline: signal 11 received
The error code from the last failed command is -5.
In short, the inliner makes an address error. After I called IBM France software
support to report the problem (client number 681888, incident number 3020x), I got
the following answer (a week later):
IBM>> We've got the solution to your problem: don't use the -O flag
Now that I call helpful and competent support ! (in fact I can do -O with -Q!,
which disables inlining). Does anybody have a better advice ?
The command lslpp -h 'xlC*' yields:
Name
--------------------
Fix Id Release Status Action Date Time User Name
------- --------------- ---------- ---------- ---------- -------- ----------
Path: /usr/lib/objrepos
xlCbrs.obj
01.01.0002.0048 COMPLETE COMMIT 01/05/95 14:23:13 root
xlCcmp.obj
01.01.0002.0048 COMPLETE COMMIT 01/05/95 14:23:14 root
xlCcmpiEn_US.info
03.02.0003.0000 COMPLETE COMMIT 08/04/94 18:12:01 root
xlClib.iv.src
01.01.0002.0023 COMPLETE COMMIT 08/04/94 18:10:15 root
xlClib.nih.src
01.01.0002.0023 COMPLETE COMMIT 08/04/94 18:10:15 root
xlCmEn_US.msg
01.01.0002.0048 COMPLETE COMMIT 01/05/95 14:23:14 root
xlCrte.obj
01.01.0002.0048 COMPLETE COMMIT 01/05/95 14:23:14 root
Path: /etc/objrepos
xlCbrs.obj
01.01.0002.0048 COMPLETE COMMIT 01/05/95 14:23:15 root
xlCcmp.obj
01.01.0002.0048 COMPLETE COMMIT 01/05/95 14:23:15 root
Thanks,
Benoit
Randy Langehennig
> Hi happy xlC users,
>
> I get the following message with xlC:
> make
> xlC -DXLC_BUGS -O -I.. -I../../MapLib -o Central Central.C AlphaEv4.o C3.a
> xlC: 1501-224 fatal error in /usr/lpp/xlC/bin/C++inline: signal 11 received
> The error code from the last failed command is -5.
> In short, the inliner makes an address error. After I called IBM France software
> support to report the problem (client number 681888, incident number 3020x), I got
> the following answer (a week later):
>
> IBM>> We've got the solution to your problem: don't use the -O flag
>
> Now that I call helpful and competent support ! (in fact I can do -O with -Q!,
> which disables inlining). Does anybody have a better advice ?
I don't have better advise for you, however, I hope your call results in a
defect for the xlC folks in Toronto to investigate. You might want to ask
your IBM support representative if a defect has been opened.
--
---------------------------------------------------------------------------
Randy Langehennig ran...@austin.ibm.com
"The content of this posting is independent of official IBM position."
Eric Siebert
In article <D4s9G...@austin.ibm.com>, ran...@austin.ibm.com (Randy Langehennig) writes:
|>>[Responding to the original post for which quoting seems to have been passed over :-)]
|>> I get the following message with xlC:
|>> make
|>> xlC -DXLC_BUGS -O -I.. -I../../MapLib -o Central Central.C AlphaEv4.o C3.a
|>> xlC: 1501-224 fatal error in /usr/lpp/xlC/bin/C++inline: signal 11 received
|>> The error code from the last failed command is -5.
|>
|>> In short, the inliner makes an address error. After I called IBM France software
|>> support to report the problem (client number 681888, incident number 3020x), I got
|>> the following answer (a week later):
|>>
|>> IBM>> We've got the solution to your problem: don't use the -O flag
|>>
|>> Now that I call helpful and competent support ! (in fact I can do -O with -Q!,
|>> which disables inlining). Does anybody have a better advice ?
|>
|>I don't have better advise for you, however, I hope your call results in a
|>defect for the xlC folks in Toronto to investigate. You might want to ask
|>your IBM support representative if a defect has been opened.
well it is in the APAR database (see below), with the turning off
optimization mentioned as a temporary workaround. but i'm a bit
unclear as to what the status of the APAR is now (other than that its
closed, it doesn't appear to mention a PTF being generated.)
APAR NUMBER: IX46286 RESOLVED AS: PROGRAM ERROR
ABSTRACT:
SIGNAL 11 RECEIVED WHEN COMPILING WITH OPTIMIZATION.
ORIGINATING DETAILS:
COMPONENT: 576503501 RELEASE = 111
The program is declaring a large complex array. When compiling
without optimization the program is compiled cleanly but when
compiling with -O3 the following message is produced:
xlC: 1501-224 fatal error in /usr/lpp/xlC/bin/C++inline: signal
11 received
LOCAL FIX AS REPORTED BY ORIGINATOR:
The workaround is to not use optimization when compiling.
RESPONDER CONCLUSION:
The problem was in the inliner in a
malloc routine. The inliner was writing 4 bytes past the end
of a malloced area for the inline list. The signal 11 will
no longer occur
Reported to Correct a PTF in Error: NO
Reported as a Highly pervasive problem: NO
PE Apar?: NoPE
Hiper Apar?: NoHiper
Status: CLOSED PER
Component Name: XL C++ COMPILER
Version: 111
Component ID: 576503501
Submitted: 94/09/14
Closed: 94/10/11
ChangeTeam: CN7021
-------------------------------------------------------------------------------
Eric Siebert
email: e-si...@uchicago.edu Any opinions expressed are mine and are not
University of Chicago - NTCS necessarily shared by my employer.
Charlie McGuire
|> Rich Ervin (rervin@tnt) wrote:
|> : Benoit Dupont de Dinechin (b...@babar.limeil.cea.fr) wrote:
|> : >Hi happy xlC users,
|>
|> : >IBM>> We've got the solution to your problem: don't use the -O flag
|>
|> : I cab believe it. Typical, typical, typical. This is why I use gcc
|> : much as possible.
|>
|> This doesn't surprise me, either.
|>
|> An Adobe employee indicated that they don't trust xlc (C, not C++)
|> compiler's -O flag, because of unpredictable results. Likewise, I've
|> had bizarre results when I optimized a program that went away when I
|> recompiled it without -O.***
|>
|> So, another compiler with a broken optimizer sounds about par for the
|> course.
|>
Yes indeedy. Over the years I've seen lots of compilers do strange things
trying to optimize code. I rarely use optimizers anymore and never during
development. I once had the AIX C compiler optimize an X command for drawing
arcs where I was drawing a polygon and the darn thing removed the
closing arc of the polygon. I have no idea how the X code is expanded but
somewhere along the line it saw that the first and last elements of a
structure were identical (startpoint/endpoint) so it threw the last one out.
Charlie
--
*************************************************************************
( Charlie McGuire | Tel. : (406) 243-4618 )
( System Administration | Fax : (406) 243-4076 )
( The University of Montana | )
( Computer Science Dept | E-Mail: mcg...@cs.umt.edu )
*************************************************************************
Rich Ervin
>Hi happy xlC users,
>IBM>> We've got the solution to your problem: don't use the -O flag
I cab believe it. Typical, typical, typical. This is why I use gcc
much as possible.
Doug Sewell
This doesn't surprise me, either.
An Adobe employee indicated that they don't trust xlc (C, not C++)
compiler's -O flag, because of unpredictable results. Likewise, I've
had bizarre results when I optimized a program that went away when I
recompiled it without -O.***
So, another compiler with a broken optimizer sounds about par for the
course.
*** (In case you're wondering why I didn't report this, the program is
a square dance choreography program, so explaining how to test it
and reproduce the error is, well, "a stretch").
--
Doug Sewell (do...@cc.ysu.edu) (http://cc.ysu.edu/doug)
"Steve [Boursy] -- You Have Been Trolled. Have A Nice Day." -- Karl A Krueger
Mark Mendell
get fixed (as opposed to ignored). IBM France should only be giving you that
advice as a workaround while the bug is being fixed.
--
Mark Mendell
C Set ++ for AIX Development
IBM Toronto Lab
men...@vnet.ibm.com
Thomas Braunbeck
|>
|> In article <D4s9G...@austin.ibm.com>, ran...@austin.ibm.com (Randy Langehennig) writes:
|>
|> APAR NUMBER: IX46286 RESOLVED AS: PROGRAM ERROR
VERSION 01.01.0002.0049 has the fix.
IBM France software support should be able to send you this
or a later version of the compiler.