This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix two testsuite failures on k6-pc-linux-gnu


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]