[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586

[ebotcazou at gcc dot gnu dot org]

-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-23 06:10:37
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325

[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-09-23 09:16 ---
Yes, my patch should be a no-op on this failure, it just avoids calling
convert_move if it would ICE anyway.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325

[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586

[manu at gcc dot gnu dot org]

--- Comment #9 from manu at gcc dot gnu dot org  2010-09-23 15:53 ---
(In reply to comment #1)
 Well - obviously global typedefs keep their BLKmode.  The target attribute
 can't work this way - it's broken by design.

If it is broken by design, why not remove it before people start depending on
it and GCC has to add layer after layer of workarounds?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325

[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2010-09-23 00:20 ---
*** Bug 45753 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325

[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586

[davek at gcc dot gnu dot org]

--- Comment #6 from davek at gcc dot gnu dot org  2010-09-12 23:45 ---
This is also present on i686-pc-cygwin:

 FAIL: gcc.target/i386/pr38240.c (internal compiler error)

ICE happens here:

(gdb) bt
#0  0x006065e0 in convert_move (to=0x7fcc26c0, from=0x7fcc26d0, unsignedp=0)
at /gnu/gcc/gcc-unpatched/gcc/expr.c:2944
#1  0x00609d2f in store_expr (exp=0x7fde2c10, target=0x7fcc26c0,
call_param_p=0, nontemporal=0 '\0')
at /gnu/gcc/gcc-unpatched/gcc/expr.c:2944
#2  0x0060f638 in expand_assignment (to=0x7fe20050, from=0x7fde2c10,
nontemporal=0 '\0') at /gnu/gcc/gcc-unpatched/gcc/expr.c:2944

(...yes, the line number info is wrong, don't know why but it's unrelated.)

  The patch in r162918 tightens up the condition on calling emit_block_move:

--- trunk/gcc/expr.c2010/08/05 15:39:54 162917
+++ trunk/gcc/expr.c2010/08/05 16:37:38 162918
@@ -4752,11 +4752,14 @@
{
  int unsignedp = TYPE_UNSIGNED (TREE_TYPE (exp));
  if (GET_MODE (target) == BLKmode
-  || GET_MODE (temp) == BLKmode)
+  GET_MODE (temp) == BLKmode)
emit_block_move (target, temp, expr_size (exp),
 (call_param_p
  ? BLOCK_OP_CALL_PARM
  : BLOCK_OP_NORMAL));
+ else if (GET_MODE (target) == BLKmode)
+   store_bit_field (target, INTVAL (expr_size (exp)) * BITS_PER_UNIT,
+0, GET_MODE (temp), temp);
  else
convert_move (target, temp, unsignedp);
}
so that when temp is BLKmode and target is not, as in this case:

(gdb) call debug_rtx (to) # aka target
(mem/c/i:V4SF (reg/f:SI 58 [ D.1753 ]) [0 retval+0 S16 A128])
(gdb) call debug_rtx (from) # aka temp
(mem/c/i:BLK (plus:SI (reg/f:SI 54 virtual-stack-vars)
(const_int -16 [0xfff0])) [0 D.1747+0 S16 A128])

... it falls through into the final else clause, and calls convert_move. 
However convert_move is unable to handle any BLKmode data at all: it has these
asserts near the beginning,

  gcc_assert (to_mode != BLKmode);
  gcc_assert (from_mode != BLKmode);

.. and the second one fires.


-- 

davek at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||davek at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325

[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325

[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-08-19 19:38 ---
It is caused by revision 162918:

http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00129.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325

[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586

[rth at gcc dot gnu dot org]

--- Comment #5 from rth at gcc dot gnu dot org  2010-08-19 19:48 ---
(In reply to comment #3)
 Well, I think we should back out support for that option.  The set of
 nonsensical options doesn't include sse - but all options are included
 in the set of broken options.  At least I expect that you can create a
 testcase with such ICEs for every one.

Not every one, just those that expand the set of valid backend modes.
Thus sse3 will not cause additional ice's, assuming sse2 is in
effect globally.

That's not to say this feature isn't fraught with peril.  I think it
should be improved though, not removed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325