* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
@ 2009-02-09 15:54 ` jakub at gcc dot gnu dot org
2009-02-09 16:40 ` jakub at gcc dot gnu dot org
` (28 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-02-09 15:54 UTC (permalink / raw)
To: gcc-bugs
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail| |4.4.0
Known to work| |4.3.2
Priority|P3 |P1
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
2009-02-09 15:54 ` [Bug target/39139] " jakub at gcc dot gnu dot org
@ 2009-02-09 16:40 ` jakub at gcc dot gnu dot org
2009-02-09 16:45 ` rguenth at gcc dot gnu dot org
` (27 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-02-09 16:40 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from jakub at gcc dot gnu dot org 2009-02-09 16:39 -------
Regression since http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134321
tree-ssa-sink.c moves e = {} store across a1 = 11 initialization, where a1
is a register asm ("%rdi") variable, so into a spot where %rdi is live and thus
can't be used for rep; stos*. Not sure what we should do. i386 expander
avoids using stos* etc. when %rdi is a global reg variable or fixed register,
but doesn't have df info to find out that %rdi is just locally live across this
spot. Probably it would be better not to sink that store across register var
initialization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
2009-02-09 15:54 ` [Bug target/39139] " jakub at gcc dot gnu dot org
2009-02-09 16:40 ` jakub at gcc dot gnu dot org
@ 2009-02-09 16:45 ` rguenth at gcc dot gnu dot org
2009-02-09 16:53 ` rguenth at gcc dot gnu dot org
` (26 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-02-09 16:45 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-09 16:45 -------
This would be a fragile solution. I think the backend has to cope with that
in some way, for example not using string expanders when there is any local
register variable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (2 preceding siblings ...)
2009-02-09 16:45 ` rguenth at gcc dot gnu dot org
@ 2009-02-09 16:53 ` rguenth at gcc dot gnu dot org
2009-02-09 18:12 ` jakub at gcc dot gnu dot org
` (25 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-02-09 16:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-09 16:53 -------
Another option is RESOLVED INVALID. Whoever uses local fixed regs ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (3 preceding siblings ...)
2009-02-09 16:53 ` rguenth at gcc dot gnu dot org
@ 2009-02-09 18:12 ` jakub at gcc dot gnu dot org
2009-02-09 19:13 ` hjl dot tools at gmail dot com
` (24 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-02-09 18:12 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from jakub at gcc dot gnu dot org 2009-02-09 18:12 -------
... must do what exactly? Using DECL_HARD_REGISTER vars in macros or inline
functions is very common, starting from kernel, glibc, many programs that
invoke syscalls directly, etc., and it worked well until now.
I think sinking = {} across DECL_HARD_REGISTER initialization is wrong even if
we teach i386 backend about DECL_HARD_REGISTER vars and don't use the stringop
insns in that case. something = {} might expand into memset call, and for all
call-clobbered vals having a call when those are live is definitely a bug.
All macros/inlines that use DECL_HARD_REGISTER vars I remember first prepare
all arguments in normal vars and then only copy everything to the hard
registers, so it can be only the compiler reordering stuff that introduces
breakage. Optimizations that increase the live range of such variables need to
be avoided.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (4 preceding siblings ...)
2009-02-09 18:12 ` jakub at gcc dot gnu dot org
@ 2009-02-09 19:13 ` hjl dot tools at gmail dot com
2009-02-09 19:39 ` hjl dot tools at gmail dot com
` (23 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-09 19:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from hjl dot tools at gmail dot com 2009-02-09 19:12 -------
I think it is related to PR 38941.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (5 preceding siblings ...)
2009-02-09 19:13 ` hjl dot tools at gmail dot com
@ 2009-02-09 19:39 ` hjl dot tools at gmail dot com
2009-02-09 20:17 ` jakub at gcc dot gnu dot org
` (22 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-09 19:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from hjl dot tools at gmail dot com 2009-02-09 19:39 -------
I think gcc treats REG in:
register unsigned long reg asm ("rax");
as an alias of the RAX register. If you use REG in any
way which interferes with register allocator, you will
get either ICE or unexpected results.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (6 preceding siblings ...)
2009-02-09 19:39 ` hjl dot tools at gmail dot com
@ 2009-02-09 20:17 ` jakub at gcc dot gnu dot org
2009-02-09 20:29 ` hjl dot tools at gmail dot com
` (21 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-02-09 20:17 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from jakub at gcc dot gnu dot org 2009-02-09 20:17 -------
This is different from that PR. In this case the code does nothing dangerous
in the block with the register vars. For %rdi and a couple of other regs on
x86-64
one could actually use "D" etc. constraints, but r8-r15 already don't have a
single register class for each register, and on most of the other targets this
isn't available either. So just to show that this isn't x86-64 only issue,
here is a testcase for sparc64-linux:
static inline int
foo (unsigned int x, void *y)
{
register unsigned long r asm ("o0");
register unsigned long a1 asm ("g1") = a1;
register unsigned long a2 asm ("g5") = a2;
a1 = (unsigned long) x;
a2 = (unsigned long) y;
asm volatile ("# %0 %1 %2" : "=r" (r), "+r" (a1), "+r" (a2) : : "memory");
return (int) r;
}
struct T { unsigned long t1, t2; unsigned int t3, t4, t5; };
int
bar (unsigned long x, unsigned int y, unsigned long u, unsigned int v)
{
long r;
struct T e = { .t1 = x, .t2 = u };
if (x << y != u << v)
return 5;
r = foo (11, &e);
return e.t3 == x;
}
compile with -Os -m64 and -Os -m64 -fno-tree-sink. See in the latter:
add %fp, 2015, %l0
mov 0, %o1
mov %l0, %o0
call memset, 0
mov 32, %o2
...
mov %l0, %g5
mov 11, %g1
#APP
! 9 "pr39139.c" 1
# %o0 %g1 %g5
#NO_APP
I.e. it would work just fine, both are initialized to the expected value. With
sinking we have:
save %sp, -208, %sp
sllx %i0, %i1, %i1
sllx %i2, %i3, %i3
cmp %i1, %i3
bne,pt %xcc, .LL3
mov 5, %g1
add %fp, 2015, %o0
mov 0, %o1
call memset, 0
mov 32, %o2
stx %i2, [%fp+2023]
stx %i0, [%fp+2015]
#APP
! 9 "mm.c" 1
# %o0 %g1 %g5
#NO_APP
where neither g1 nor g5 are initialized at all (they were initialized during
expand, but before the memset call, and as both g1 and g5 are call clobbered
their value would (or could) be corrupted during the call anyway).
I'd say easiest fix would be for tree-ssa-sink.c to punt sinking = {} if there
are any DECL_HARD_REGISTER vars in the function.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (7 preceding siblings ...)
2009-02-09 20:17 ` jakub at gcc dot gnu dot org
@ 2009-02-09 20:29 ` hjl dot tools at gmail dot com
2009-02-09 20:32 ` hjl dot tools at gmail dot com
` (20 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-09 20:29 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]
------- Comment #8 from hjl dot tools at gmail dot com 2009-02-09 20:29 -------
[hjl@gnu-6 reg-1]$ cat b.c
extern void abort (void);
int g = 3;
int main()
{
register int x __asm__("ecx");
x = 5;
if ((1 << g) != 8 || x != 5)
abort ();
return 0;
}
[hjl@gnu-6 reg-1]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-work/build-x86_64-linux/gcc/ -m32 -O0 b.c -S -o b.s
b.c: In function main:
b.c:11: error: unable to find a register to spill in class CREG
b.c:11: error: this is the insn:
(insn 8 7 9 2 b.c:8 (parallel [
(set (reg:SI 0 ax [orig:60 D.1254 ] [60])
(ashift:SI (reg:SI 1 dx [63])
(subreg:QI (reg:SI 0 ax [orig:61 g.0 ] [61]) 0)))
(clobber (reg:CC 17 flags))
]) 495 {*ashlsi3_1} (expr_list:REG_DEAD (reg:SI 1 dx [63])
(expr_list:REG_DEAD (reg:SI 0 ax [orig:61 g.0 ] [61])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))))
b.c:11: internal compiler error: in spill_failure, at reload1.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[hjl@gnu-6 reg-1]$
My point is if you use "register unsigned long reg asm" on local
variables, you may run into ICE or unexpected results if the
register you specified happens to be used by compiler for
some basic operations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (8 preceding siblings ...)
2009-02-09 20:29 ` hjl dot tools at gmail dot com
@ 2009-02-09 20:32 ` hjl dot tools at gmail dot com
2009-02-09 20:36 ` jeremy at goop dot org
` (19 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-09 20:32 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from hjl dot tools at gmail dot com 2009-02-09 20:32 -------
We should take a look at the problem "register unsigned long reg asm"
trying to resolve. We may need to provide some other reliable ways
to address the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (9 preceding siblings ...)
2009-02-09 20:32 ` hjl dot tools at gmail dot com
@ 2009-02-09 20:36 ` jeremy at goop dot org
2009-02-09 20:37 ` jakub at gcc dot gnu dot org
` (18 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: jeremy at goop dot org @ 2009-02-09 20:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from jeremy at goop dot org 2009-02-09 20:35 -------
The code in question is setting up parameters for a Xen hypercall. The
hypercall ABI defines what arguments go in which registers. It uses the
"register unsigned long arg asm" syntax because that's the only way to specify
high registers on x86-64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (10 preceding siblings ...)
2009-02-09 20:36 ` jeremy at goop dot org
@ 2009-02-09 20:37 ` jakub at gcc dot gnu dot org
2009-02-09 20:38 ` jeremy at goop dot org
` (17 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-02-09 20:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from jakub at gcc dot gnu dot org 2009-02-09 20:36 -------
Sure, but in your testcase you do the operation that requires the register
while the register var is still in scope and live. The compiler doesn't have a
possibility to compile it right. But, if we say it is ok for the compiler to
move an unrelated 1 << somevar or call, stringop etc. into a block where the
register var is live and ICE because the compiler did it, we'd basically forbid
all uses of register vars. Automatic register vars are there mainly to support
inline asm hardcoded inputs/outputs for which you don't have special register
classes, programmers using them know very well the limitations and that they
only copy prepared stuff from other variables into the register variables, do
inline asm and copy back the results from local register vars to other vars.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (11 preceding siblings ...)
2009-02-09 20:37 ` jakub at gcc dot gnu dot org
@ 2009-02-09 20:38 ` jeremy at goop dot org
2009-02-09 20:41 ` hjl dot tools at gmail dot com
` (16 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: jeremy at goop dot org @ 2009-02-09 20:38 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from jeremy at goop dot org 2009-02-09 20:37 -------
Created an attachment (id=17274)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17274&action=view)
Original code to set up hypercalls.
This is the original code Jakub distilled the reproducer from. It includes a
comment containing the rationale for the way the code is structured.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (12 preceding siblings ...)
2009-02-09 20:38 ` jeremy at goop dot org
@ 2009-02-09 20:41 ` hjl dot tools at gmail dot com
2009-02-09 20:43 ` hjl dot tools at gmail dot com
` (15 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-09 20:41 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from hjl dot tools at gmail dot com 2009-02-09 20:41 -------
(In reply to comment #10)
> The code in question is setting up parameters for a Xen hypercall. The
> hypercall ABI defines what arguments go in which registers. It uses the
> "register unsigned long arg asm" syntax because that's the only way to specify
> high registers on x86-64.
>
I suspected that is what happened. PR 38925 is another case.
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |38925
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (13 preceding siblings ...)
2009-02-09 20:41 ` hjl dot tools at gmail dot com
@ 2009-02-09 20:43 ` hjl dot tools at gmail dot com
2009-02-09 20:44 ` hjl dot tools at gmail dot com
` (14 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-09 20:43 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from hjl dot tools at gmail dot com 2009-02-09 20:43 -------
PR 16331 is another.
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
BugsThisDependsOn| |16331
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (14 preceding siblings ...)
2009-02-09 20:43 ` hjl dot tools at gmail dot com
@ 2009-02-09 20:44 ` hjl dot tools at gmail dot com
2009-02-09 20:47 ` hjl dot tools at gmail dot com
` (13 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-09 20:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from hjl dot tools at gmail dot com 2009-02-09 20:44 -------
I tempted to reopen PR 16331 and mark PR 38925/39139 as dup
for PR 16331.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (15 preceding siblings ...)
2009-02-09 20:44 ` hjl dot tools at gmail dot com
@ 2009-02-09 20:47 ` hjl dot tools at gmail dot com
2009-02-09 20:49 ` jakub at gcc dot gnu dot org
` (12 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-09 20:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from hjl dot tools at gmail dot com 2009-02-09 20:46 -------
*** This bug has been marked as a duplicate of 16331 ***
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (16 preceding siblings ...)
2009-02-09 20:47 ` hjl dot tools at gmail dot com
@ 2009-02-09 20:49 ` jakub at gcc dot gnu dot org
2009-02-09 20:52 ` hjl dot tools at gmail dot com
` (11 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-02-09 20:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from jakub at gcc dot gnu dot org 2009-02-09 20:49 -------
This is wrong, this is not a dup of PR16331. PR16331 is invalid, it makes a
call with r8 in scope. This one doesn't. That's pretty substantial
difference.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rth at gcc dot gnu dot org,
| |drepper at redhat dot com
Status|RESOLVED |UNCONFIRMED
Resolution|DUPLICATE |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (17 preceding siblings ...)
2009-02-09 20:49 ` jakub at gcc dot gnu dot org
@ 2009-02-09 20:52 ` hjl dot tools at gmail dot com
2009-02-09 21:01 ` jakub at gcc dot gnu dot org
` (10 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-09 20:52 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from hjl dot tools at gmail dot com 2009-02-09 20:52 -------
(In reply to comment #17)
> This is wrong, this is not a dup of PR16331. PR16331 is invalid, it makes a
> call with r8 in scope. This one doesn't. That's pretty substantial
> difference.
>
PR 16331 is "x86-64 inline asm register constraints insufficient WRT ABI".
Isn't this the same problem here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (18 preceding siblings ...)
2009-02-09 20:52 ` hjl dot tools at gmail dot com
@ 2009-02-09 21:01 ` jakub at gcc dot gnu dot org
2009-02-09 21:10 ` hjl dot tools at gmail dot com
` (9 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-02-09 21:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from jakub at gcc dot gnu dot org 2009-02-09 21:01 -------
No. This bug is about all targets, not just x86-64, and is about code which
follows extend.texi documentation (Extended Asm and Explicit Reg Vars) for
years (glibc e.g. uses it this way for more than 10 years). Do you suddenly
want to rule all that code invalid?
See glibc INLINE_SYSCALL and INTERNAL_SYSCALL macros on all arches, Linux
asm*/unistd.h _syscall* macros until very recently, etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (19 preceding siblings ...)
2009-02-09 21:01 ` jakub at gcc dot gnu dot org
@ 2009-02-09 21:10 ` hjl dot tools at gmail dot com
2009-02-09 22:37 ` ian at airs dot com
` (8 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-09 21:10 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from hjl dot tools at gmail dot com 2009-02-09 21:09 -------
(In reply to comment #19)
> No. This bug is about all targets, not just x86-64, and is about code which
> follows extend.texi documentation (Extended Asm and Explicit Reg Vars) for
> years (glibc e.g. uses it this way for more than 10 years). Do you suddenly
> want to rule all that code invalid?
> See glibc INLINE_SYSCALL and INTERNAL_SYSCALL macros on all arches, Linux
> asm*/unistd.h _syscall* macros until very recently, etc.
>
If you don't get ICE, you don't have to change anything. If
you do get ICE, you may have to update.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (20 preceding siblings ...)
2009-02-09 21:10 ` hjl dot tools at gmail dot com
@ 2009-02-09 22:37 ` ian at airs dot com
2009-02-10 1:36 ` hjl dot tools at gmail dot com
` (7 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: ian at airs dot com @ 2009-02-09 22:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from ian at airs dot com 2009-02-09 22:37 -------
I agree with Jakub that the original test case, and the one in comment #7,
appear to conform to the documented gcc extension. I think that gcc has to
treat this sort of code as valid, and not break it. We can't casually or
accidentally break our documented extensions.
Unfortunately this means that in a function which contains both local register
variables and an asm, we must severely restrict any code motion which may
involve a function call or the use of hidden registers. We should explicitly
express a dependency between any asm and any local register variable in scope
for the asm. That won't solve the problem by itself, though.
--
ian at airs dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (21 preceding siblings ...)
2009-02-09 22:37 ` ian at airs dot com
@ 2009-02-10 1:36 ` hjl dot tools at gmail dot com
2009-02-10 9:51 ` bonzini at gnu dot org
` (6 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-02-10 1:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from hjl dot tools at gmail dot com 2009-02-10 01:36 -------
I guess it is too expensive to add a new reg class for each
register to support constraints for all registers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (22 preceding siblings ...)
2009-02-10 1:36 ` hjl dot tools at gmail dot com
@ 2009-02-10 9:51 ` bonzini at gnu dot org
2009-02-10 10:21 ` jakub at gcc dot gnu dot org
` (5 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: bonzini at gnu dot org @ 2009-02-10 9:51 UTC (permalink / raw)
To: gcc-bugs
------- Comment #23 from bonzini at gnu dot org 2009-02-10 09:50 -------
> I guess it is too expensive to add a new reg class for each
> register to support constraints for all registers.
This has no reference to the actual problem of this PR.
The sparc testcase that Jakub posted is particularly significative, since you
don't get ICEs but wrong code there.
> Unfortunately this means that in a function which contains both local register
> variables and an asm, we must severely restrict any code motion which may
> involve a function call or the use of hidden registers.
I think that in the GIMPLE grammar local register variables should be treated
as memory, with loads and stores separated from the computations; and just like
memory, each asm or function call should have a VUSE and (depending on the
asm's inputs, outputs and clobbers; and in the case of function calls for
call-clobbered local register variables) VDEF for the local register variables.
--
bonzini at gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bonzini at gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-02-10 09:50:44
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (23 preceding siblings ...)
2009-02-10 9:51 ` bonzini at gnu dot org
@ 2009-02-10 10:21 ` jakub at gcc dot gnu dot org
2009-02-10 10:29 ` jakub at gcc dot gnu dot org
` (4 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-02-10 10:21 UTC (permalink / raw)
To: gcc-bugs
------- Comment #24 from jakub at gcc dot gnu dot org 2009-02-10 10:20 -------
Their loads and stores are already separated from other computations, as
they aren't is_gimple_reg. And they do have VDEFs/VUSES:
# a1D.1284_24 = VDEF <a1D.1284_23(D)> { a1D.1284 }
a1D.1284 = 11;
y.0D.1287_15 = (long unsigned intD.4) &eD.1268;
# a2D.1285_26 = VDEF <a2D.1285_25(D)> { a2D.1285 }
a2D.1285 = y.0D.1287_15;
# eD.1268_28 = VDEF <eD.1268_22>
# rD.1283_29 = VDEF <rD.1283_27(D)>
# a1D.1284_30 = VDEF <a1D.1284_24>
# a2D.1285_31 = VDEF <a2D.1285_26> { eD.1268 rD.1283 a1D.1284 a2D.1285 }
__asm__ __volatile__("" : "=r" rD.1283, "=r" a1D.1284, "=r" a2D.1285 : "1"
a1D.1284 : "2" a2D.1285 : "memory");
But that is not enough to prevent sinking in between these, sinking of e = {}
looks solely at eD.1268_* VUSEs and the immediate user is therefore the asm.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (24 preceding siblings ...)
2009-02-10 10:21 ` jakub at gcc dot gnu dot org
@ 2009-02-10 10:29 ` jakub at gcc dot gnu dot org
2009-02-10 10:35 ` rguenth at gcc dot gnu dot org
` (3 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-02-10 10:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #25 from jakub at gcc dot gnu dot org 2009-02-10 10:29 -------
Created an attachment (id=17275)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17275&action=view)
gcc44-pr39139.patch
Quick patch to avoid sinking of block copies or clearings if current function
has local explicit register vars. If there are other passes that move around
calls or potential calls to places where they haven't been originally, they
could do similar thing. If needed, we could track which basic blocks have such
vars live etc., but I don't think it is worth it.
The alternative would be to make DECL_HARD_REGISTER initializations (and uses?)
act like loads/stores of pointers that can point to any memory, but that seems
to me even bigger overkill, there is nothing wrong with moving a normal memory
load or store, it is just the potential libcalls and inline stringops that are
a problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (25 preceding siblings ...)
2009-02-10 10:29 ` jakub at gcc dot gnu dot org
@ 2009-02-10 10:35 ` rguenth at gcc dot gnu dot org
2009-02-10 10:49 ` bonzini at gnu dot org
` (2 subsequent siblings)
29 siblings, 0 replies; 32+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-02-10 10:35 UTC (permalink / raw)
To: gcc-bugs
------- Comment #26 from rguenth at gcc dot gnu dot org 2009-02-10 10:35 -------
I could imagine that other architectures have other special registers, so
I think treating them like pointer dereferences to anything would be more
robust than changing all code-motion passes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (26 preceding siblings ...)
2009-02-10 10:35 ` rguenth at gcc dot gnu dot org
@ 2009-02-10 10:49 ` bonzini at gnu dot org
2009-02-10 16:22 ` jakub at gcc dot gnu dot org
2009-02-10 16:35 ` jakub at gcc dot gnu dot org
29 siblings, 0 replies; 32+ messages in thread
From: bonzini at gnu dot org @ 2009-02-10 10:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #27 from bonzini at gnu dot org 2009-02-10 10:49 -------
The patch does not seem too bad. You could add a target hook to get a
HARD_REG_SET or constituting an optimization barriers (defaulting to all
call-clobbered registers, which would be okay for all targets that do not have
stringops).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (27 preceding siblings ...)
2009-02-10 10:49 ` bonzini at gnu dot org
@ 2009-02-10 16:22 ` jakub at gcc dot gnu dot org
2009-02-10 16:35 ` jakub at gcc dot gnu dot org
29 siblings, 0 replies; 32+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-02-10 16:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #28 from jakub at gcc dot gnu dot org 2009-02-10 16:22 -------
Subject: Bug 39139
Author: jakub
Date: Tue Feb 10 16:22:29 2009
New Revision: 144065
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144065
Log:
PR target/39139
* function.h (struct function): Add has_local_explicit_reg_vars
bit.
* gimplify.c (gimplify_bind_expr): Set it if local DECL_HARD_REGISTER
VAR_DECLs were seen.
* tree-ssa-live.c (remove_unused_locals): Recompute
cfun->has_local_explicit_reg_vars.
* tree-ssa-sink.c (statement_sink_location): Don't sink BLKmode
copies or clearings if cfun->has_local_explicit_reg_vars.
* gcc.target/i386/pr39139.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr39139.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.h
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-live.c
trunk/gcc/tree-ssa-sink.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bug target/39139] [4.4 Regression] ICE with stringop and register var
2009-02-09 15:53 [Bug target/39139] New: [4.4 Regression] ICE with stringop and register var jakub at gcc dot gnu dot org
` (28 preceding siblings ...)
2009-02-10 16:22 ` jakub at gcc dot gnu dot org
@ 2009-02-10 16:35 ` jakub at gcc dot gnu dot org
29 siblings, 0 replies; 32+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-02-10 16:35 UTC (permalink / raw)
To: gcc-bugs
------- Comment #29 from jakub at gcc dot gnu dot org 2009-02-10 16:35 -------
Fixed.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139
^ permalink raw reply [flat|nested] 32+ messages in thread