https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70370

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-checking, wrong-code

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Interestingly enough for

struct X { int i; };

struct X boo (struct X x)
{
  __asm__ ("" : "=r" (x.i));
  return x;
}

struct X boof (struct X x)
{
  __asm__ ("" : "+r" (x.i));
  return x;
}

we "ignore" the !allows_mem and end up generating virtual operands anyway,
leaving RTL expansion to fix up things (or ICE).  When omitting the .i
the proposed patch would reject this (we can't fix up on GIMPLE if not
for using a different type based on the mode).  If making X not have
a mode suitable for a register we get

t.c: In function ‘boo’:
t.c:5:3: error: impossible constraint in ‘asm’
   __asm__ ("" : "=r" (x));
   ^

this hints the ICE being an operand scanner issue after all (in some weird
way...).  Still having !allows_mem but not a register might be odd.

Ok, so I think the real issue with __real/__imag is that it doesn't get
a VOP because the param is_gimple_reg() as it has DECL_GIMPLE_REG_P set.
That happens because we do in gimplify_function_tree:

11521     for (parm = DECL_ARGUMENTS (fndecl); parm ; parm = DECL_CHAIN (parm))
11522       {
11523         /* Preliminarily mark non-addressed complex variables as eligible
11524            for promotion to gimple registers.  We'll transform their uses
11525            as we find them.  */
(gdb) 
11526         if ((TREE_CODE (TREE_TYPE (parm)) == COMPLEX_TYPE
11527              || TREE_CODE (TREE_TYPE (parm)) == VECTOR_TYPE)
11528             && !TREE_THIS_VOLATILE (parm)
11529             && !needs_to_live_in_memory (parm))
11530           DECL_GIMPLE_REG_P (parm) = 1;
11531       }

but this means we have to transform _all_ uses during gimplification.
I don't think we can roll-back setting of DECL_GIMPLE_REG_P.  Or the FEs
would need to mark even !allows_mem asm operands as addressable.

So fixing this up in gimplification is required but I'm trying to leave
the other cases (!is_gimple_reg base) alone for the expander to complain about.

Reply via email to