Error building V3 on i686-pc-linux-gnu

[Jan Hubicka]

>   /usr/include/bits/mathinline.h: In function `long int lrintf(float)':
>   /usr/include/bits/mathinline.h:583: output number 0 not directly addressable
>   /usr/include/bits/mathinline.h:583: inconsistent operand constraints in an 

No RTL fumps needed.
If you check the error message, it comes from frontend - expand_asm_operand.
> 
>   #define __lrint_code \
>     long int __lrintres;							      \
>     __asm__ __volatile__							      \
>       ("fistpl %0"							      \
>        : "=m" (__lrintres) : "t" (__x) : "st");				      \
>     return __lrintres
>   __MATH_INLINE long int
>   lrintf (float __x)
>   {
>     __lrint_code;
>   }
The offending piece of code (in mainline) is:

      if ((TREE_CODE (val) == INDIRECT_REF
	   && allows_mem)
	  || (DECL_P (val)
	      && (allows_mem || GET_CODE (DECL_RTL (val)) == REG)
	      && ! (GET_CODE (DECL_RTL (val)) == REG
		    && GET_MODE (DECL_RTL (val)) != TYPE_MODE (type)))
	  || ! allows_reg
	  || is_inout)
	{
	  if (! allows_reg)
	    mark_addressable (TREE_VALUE (tail));

	  output_rtx[i]
	    = expand_expr (TREE_VALUE (tail), NULL_RTX, VOIDmode,
			   EXPAND_MEMORY_USE_WO);

	  if (! allows_reg && GET_CODE (output_rtx[i]) != MEM)
	    error ("output number %d not directly addressable", i);

The code sees just "m" in the alternatives and IMO it is expected to
convert value to the MEM expression, but for some purpose it don't happend.
I guess it is mark_addressable/expand_expr problem - I am not frontend expert
and I can't reproduce the problem from your bugreport (differnt glibc version
and branch builds fine for me).
But I guess putting the breakpoinit at last error and examing output_rtx
will tell enought you to fix that.

How did you come to the conclusion that x86_64 patches are source of the
problem BTW?
They do receive quite a bit of testing - in the branch and then standard
installing protocol (done by script).
Most of followup patches was in the nature of tweaking previously correct
code to make it cleaner or produce better code.
Not real bugs on i386 compilation side.

If there was some simple way how to give bootstrap to generic changes on
multiple platforms, I would definitly do so.  I've already set up an mips
computer where I am doing occasinal tests of the x86_64 branch to ensure
that something is not really wrong.

No more generic changes are on the way anyway.

Honza