[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586
--- 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
--- 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
-- 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
--- 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
--- 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 +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 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
--- 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
[Bug middle-end/45325] [4.6 Regression] target attribute doesn't work with -march=i586
--- 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