This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix two testsuite failures on k6-pc-linux-gnu
- From: "Eric Botcazou" <ebotcazou at libertysurf dot fr>
- To: <law at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 2 Jul 2002 02:03:48 +0200
- Subject: Re: Fix two testsuite failures on k6-pc-linux-gnu
- References: <200207012225.g61MP7M23735@porcupine.slc.redhat.com>
> Nope. It has nothing to do with order of evaluation issues. The
> underlying issue is that the compiler isn't aware that the length of
> this instruction varies and that the varying length effects how we will
> output the instruction.
So, if the mechanism worked before Jan's patch and works for other ports,
it's purely by chance ?
> So if we look at how final works we see that it will try to compute
> the difference between the address of the loop instruction and its
> target. In the case where we've seen the target, we have a known
> address and we can get a reasonable length computation.
>
> However, if we are working with a target we have not seen (ie, the
> target appears *after* the loop instruction), then we use the value
> zero for the target address.
>
> The first loop instruction appears at offset 0xae in the output file. So
> we compute the difference as -0xae which appears to be within the range of
> a loop instruction.
I don't understand: -0xae is certainly not within the range of the 'loop'
instruction. Do you mean that it appears to GCC as being within the range ?
So the test
(if_then_else (and (eq_attr "alternative" "0")
(and (ge (minus (match_dup 0) (pc))
(const_int -128))
(lt (minus (match_dup 0) (pc))
(const_int 124))))
is somehow or other bypassed ?
> Later compute the address of the target as being something like 0x147, but
> since we do not know that the loop instruction has a varying length we do
> not re-compute its length.
>
> This leads to incorrect output when we output assembly code for the
> instruction.
Can't your analysis be applied to the old code too ?
> For the problem with the loop instruction, I'm not entirely sure how it
> should best be fixed. One way would be your approach.
Note that it's not really mine. The i386 port used and other ports still use
these variable-length instructions.
--
Eric Botcazou
ebotcazou@multimania.com