This is the mail archive of the 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: Unexpected output constraints

On 04/01/2010 10:54 PM, Daniel Jacobowitz wrote:
> I'm debugging a Thumb-2 glibc build failure on trunk for
> arm-none-linux-gnueabi.  I believe it's from Richard Earnshaw's
> 2010-02-01 patch for TLS patterns, which includes this:
> (define_insn "tls_load_dot_plus_four"
>   [(set (match_operand:SI 0 "register_operand" "=l,r")
>         (mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "+l,r")
>                             (const_int 4)
>                             (match_operand 2 "" "")]
>                            UNSPEC_PIC_BASE)))]
> It's that "+" on the second operand.  It should just be "&", and I
> think that will fix the failure (I'll test it shortly).

That can't be right, "&" only makes sense for outputs.

> It seems to me that the problem is marking a register in the RHS of a
> set as an output constraint.

Yes.  There was a similar bug for tls_load_dot_plus_eight recently.  In
this case it seems that operand 1 is in fact both read and written by
the pattern, so the pattern should be something like

  [(set (match_operand:SI 0 "register_operand" "=l,r")
        (mem:SI (unspec:SI [(match_dup 1)
                            (const_int 4)
                            (match_operand 2 "" "")]
   (clobber (match_operand:SI 1 "register_operand" "+&l,&r"))]

That's untested however.


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