This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA:] Fix gcc.c-torture/execute/20020720-1.x and further analysis
- From: Jeff Law <law at porcupine dot slc dot redhat dot com>
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: roger at eyesopen dot com (Roger Sayle), gcc-patches at gcc dot gnu dot org
- Date: Tue, 03 Sep 2002 11:11:30 -0600
- Subject: Re: [RFA:] Fix gcc.c-torture/execute/20020720-1.x and further analysis
- Reply-to: law at redhat dot com
In message <200209010235.g812Z1Kr003141@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
>> > >From the discussion, it appears that combine should know how to optimize
>> > this rtl (3 insns?) but apparently there is a problem. However, the
>> > problem in this case isn't the abs optimization.
>>
>>
>> This is very interesting! Notice the REG_EQUAL note on instruction
>> 27, the compiler has determined that the condition flags are always
>> false (i.e. that 1.0 is not less than 0.0)! I'd be surprised that
>> with this information the conditional branch survives the rest of
>> compilation.
>
>Hmmm, is the REG_EQUAL note for %r0 rather than the condition code?
>It is always 0. The conditional branch does survive the rest of the
>compilation.
Hard Reg 0 (from the compiler's viewpoint) is the FP condition codes.
>> One observation is that the .s files still contain references
>> to ".IMPORT link_error,ENTRY" even though link_error is never
>> referenced or called in the generated code. I didn't build a
>> full hppa64 toolchain, so I've no idea if this is the issue.
>
>These don't cause a link error or the test to fail at lower
>optimization levels. This is a problem that's not easily fixed,
>but as far as I am aware it doesn't cause any problems. This
>happens often in C++ code.
The extraneous imports shouldn't be a problem. Both the GNU and the
HP assemblers will strip out symbols which are imported, but never
used.
jeff