From dmurdoch at pair.com  Tue Nov 25 22:45:20 2003
From: dmurdoch at pair.com (Duncan Murdoch)
Date: Tue Nov 25 22:43:38 2003
Subject: [Rd] O2 optimization produces wrong code (PR#5315)
In-Reply-To: <Pine.LNX.4.44.0311252120320.9796-100000@gannet.stats>
References: <x2oev0rww4.fsf@biostat.ku.dk>
	<Pine.LNX.4.44.0311252120320.9796-100000@gannet.stats>
Message-ID: <p6j7svg1drf0s6sg13tanlm939jevtfpfb@4ax.com>

On Tue, 25 Nov 2003 21:22:08 +0000 (GMT), Prof Brian Ripley
<ripley@stats.ox.ac.uk> wrote :

>On 25 Nov 2003, Peter Dalgaard wrote:
>
>> Duncan Murdoch <dmurdoch@pair.com> writes:
>> 
>> > On Tue, 25 Nov 2003 15:47:01 +0000 (GMT), Prof Brian Ripley
>> > <ripley@stats.ox.ac.uk> wrote :
>> > 
>> > >This is a long-known problem: one example is the MASS example in the
>> > >script ch15.R, and that has gone wrong on platforms other than Windows.  
>> > >It has been reported to the maintainer in the past.
>> > 
>> > Should we back off to something less aggressive than -O2?
>> 
>> Traditionally, we've prioritized performance and used cases like this
>> to file bugs for the compiler writers. But is this really a compiler
>> problem or a problem with badly written code in akima??
>
>I suspect the latter, in particular I suspect uninitialized data areas.
>As far as I recall, this has gone wrong even without optimization.

I think I misread Brian as saying that this is a long-known problem
with gcc, rather than a long-known problem with akima.  Back to my
original suggestion:  give the akima maintainer a reproducible
example.

Duncan


[Rd] O2 optimization produces wrong code (PR#5315)
Duncan Murdoch