Re: gcc3 vs 176.gcc

[Dale Johannesen <dalej at apple dot com>]

On Tuesday, January 8, 2002, at 09:49 PM, Andreas Jaeger wrote:

> Dale Johannesen <dalej@apple.com> writes:
>
>> On Tuesday, January 8, 2002, at 04:23 PM, dewar@gnat.com wrote:
>>
>>>>> The answer is to get SPEC fixed somehow
>>>
>>> Interesting. What is the status of SPEC test that has undefined code
>>> in it?
>>
>> I'm not exactly sure what you're asking.  SPEC CPU2000 is a benchmark,
>> not a test.  SPEC regards standards compliance as a desirable goal, but
>> not a requirement.  They are more interested in portability.  There are
>> other cases where SPEC has nonstandard usage.  For example, "long long"
>> was used before it was in the standards.
>
> How should this code get fixed so that it works correctly?
>
> Dale, please send a bugreport to the SPEC folks and include the fix
> together with some background information.  SPEC allows such patches
> to the source under specific circumstance.  The changes in SPEC v1.2
> for building eon with GCC 3 and for building perl with glibc 2.2. are
> the direct result of myself (and probably others) sending such
> reports.  I worked together with the SPEC folks on a clean solution
> for them and then got a src.alt patch that I was allowed to use in
> official SPEC benchmarks.  Can you go this way with 176.gcc, please?

I'll do that, but I suspect they'll be reluctant on this one because
a change to this code is likely to affect the benchmark time (it's
in heavily-executed rtx_alloc).

Having thought about it more, I now think gcc3's behavior in this
case is clearly wrong, at least as a quality-of-implementation issue.
The aliasing rules are there to permit compilers to make aggressive
assumptions when they can't tell whether two memrefs alias or not.
They are not there to permit compilers to do stupid things when they
can easily tell that two memrefs do alias.  The examples in the
Rationale make this clear.