This is the mail archive of the gcc@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: 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 "" "")]
                           UNSPEC_PIC_BASE)))
   (clobber (match_operand:SI 1 "register_operand" "+&l,&r"))]

That's untested however.


Bernd


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