[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |8.4 --- Comment #11 from Jakub Jelinek --- Fixed on the trunk and all release branches.
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782
--- Comment #10 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:baef3efdc4992e4dcb7f4de62ff5bcb13bf05f60
commit r8-10016-gbaef3efdc4992e4dcb7f4de62ff5bcb13bf05f60
Author: Jakub Jelinek
Date: Fri Feb 14 15:47:55 2020 +0100
i386: Make xmm16-xmm31 call used even in ms ABI [PR65782]
On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> I guess that Comment #9 patch form the PR should be trivially correct,
> but althouhg it looks obvious, I don't want to propose the patch since
> I have no means of testing it.
I don't have means of testing it either.
https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
is quite explicit that [xyz]mm16-31 are call clobbered and only xmm6-15
(low
128-bits only) are call preserved.
We are talking e.g. about
/* { dg-options "-O2 -mabi=ms -mavx512vl" } */
typedef double V __attribute__((vector_size (16)));
void foo (void);
V bar (void);
void baz (V);
void
qux (void)
{
V c;
{
register V a __asm ("xmm18");
V b = bar ();
asm ("" : "=x" (a) : "0" (b));
c = a;
}
foo ();
{
register V d __asm ("xmm18");
V e;
d = c;
asm ("" : "=x" (e) : "0" (d));
baz (e);
}
}
where according to the MSDN doc gcc incorrectly holds the c value
in xmm18 register across the foo call; if foo is compiled by some Microsoft
compiler (or LLVM), then it could clobber %xmm18.
If all xmm18 occurrences are changed to say xmm15, then it is valid to hold
the 128-bit value across the foo call (though, surprisingly, LLVM saves it
into stack anyway).
The other parts are I guess mainly about SEH. Consider e.g.
void
foo (void)
{
register double x __asm ("xmm14");
register double y __asm ("xmm18");
asm ("" : "=x" (x));
asm ("" : "=v" (y));
x += y;
y += x;
asm ("" : : "x" (x));
asm ("" : : "v" (y));
}
looking at cross-compiler output, with -O2 -mavx512f this emits
.file "abcdeq.c"
.text
.align 16
.globl foo
.deffoo;.scl2; .type 32; .endef
.seh_proc foo
foo:
subq$40, %rsp
.seh_stackalloc 40
vmovaps %xmm14, (%rsp)
.seh_savexmm%xmm14, 0
vmovaps %xmm18, 16(%rsp)
.seh_savexmm%xmm18, 16
.seh_endprologue
vaddsd %xmm18, %xmm14, %xmm14
vaddsd %xmm18, %xmm14, %xmm18
vmovaps (%rsp), %xmm14
vmovaps 16(%rsp), %xmm18
addq$40, %rsp
ret
.seh_endproc
.ident "GCC: (GNU) 10.0.1 20200207 (experimental)"
Does whatever assembler mingw64 uses even assemble this (I mean the
.seh_savexmm %xmm16, 16 could be problematic)?
I can find e.g.
https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin/43210527
which then links to
https://gcc.gnu.org/PR65782
2020-02-08 Uroš Bizjak
Jakub Jelinek
PR target/65782
* config/i386/i386.h (CALL_USED_REGISTERS): Make
xmm16-xmm31 call-used even in 64-bit ms-abi.
* gcc.target/i386/pr65782.c: New test.
Co-authored-by: Uroš Bizjak
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782
--- Comment #9 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:a91e5d88970c8d865a49f2a4ed4e17ee2c58b73f
commit r9-8222-ga91e5d88970c8d865a49f2a4ed4e17ee2c58b73f
Author: Jakub Jelinek
Date: Sat Feb 8 10:59:40 2020 +0100
i386: Make xmm16-xmm31 call used even in ms ABI [PR65782]
On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> I guess that Comment #9 patch form the PR should be trivially correct,
> but althouhg it looks obvious, I don't want to propose the patch since
> I have no means of testing it.
I don't have means of testing it either.
https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
is quite explicit that [xyz]mm16-31 are call clobbered and only xmm6-15
(low
128-bits only) are call preserved.
We are talking e.g. about
/* { dg-options "-O2 -mabi=ms -mavx512vl" } */
typedef double V __attribute__((vector_size (16)));
void foo (void);
V bar (void);
void baz (V);
void
qux (void)
{
V c;
{
register V a __asm ("xmm18");
V b = bar ();
asm ("" : "=x" (a) : "0" (b));
c = a;
}
foo ();
{
register V d __asm ("xmm18");
V e;
d = c;
asm ("" : "=x" (e) : "0" (d));
baz (e);
}
}
where according to the MSDN doc gcc incorrectly holds the c value
in xmm18 register across the foo call; if foo is compiled by some Microsoft
compiler (or LLVM), then it could clobber %xmm18.
If all xmm18 occurrences are changed to say xmm15, then it is valid to hold
the 128-bit value across the foo call (though, surprisingly, LLVM saves it
into stack anyway).
The other parts are I guess mainly about SEH. Consider e.g.
void
foo (void)
{
register double x __asm ("xmm14");
register double y __asm ("xmm18");
asm ("" : "=x" (x));
asm ("" : "=v" (y));
x += y;
y += x;
asm ("" : : "x" (x));
asm ("" : : "v" (y));
}
looking at cross-compiler output, with -O2 -mavx512f this emits
.file "abcdeq.c"
.text
.align 16
.globl foo
.deffoo;.scl2; .type 32; .endef
.seh_proc foo
foo:
subq$40, %rsp
.seh_stackalloc 40
vmovaps %xmm14, (%rsp)
.seh_savexmm%xmm14, 0
vmovaps %xmm18, 16(%rsp)
.seh_savexmm%xmm18, 16
.seh_endprologue
vaddsd %xmm18, %xmm14, %xmm14
vaddsd %xmm18, %xmm14, %xmm18
vmovaps (%rsp), %xmm14
vmovaps 16(%rsp), %xmm18
addq$40, %rsp
ret
.seh_endproc
.ident "GCC: (GNU) 10.0.1 20200207 (experimental)"
Does whatever assembler mingw64 uses even assemble this (I mean the
.seh_savexmm %xmm16, 16 could be problematic)?
I can find e.g.
https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin/43210527
which then links to
https://gcc.gnu.org/PR65782
2020-02-08 Uroš Bizjak
Jakub Jelinek
PR target/65782
* config/i386/i386.h (CALL_USED_REGISTERS): Make
xmm16-xmm31 call-used even in 64-bit ms-abi.
* gcc.target/i386/pr65782.c: New test.
Co-authored-by: Uroš Bizjak
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 --- Comment #8 from Kai Tietz --- Hmm, that behavior of gcc seems to be indeed pretty bad. The SEH commands for registers above index 15 (0..15) for xmm? are indeed undefined, and even worse, can't be coded proper into the seh table correctly. Anything above 16-byte size of ?mm registers, and anything above register index 15 has to be treated as call clobbered. But in anycase, the unwind information has not to contain that information
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:79ab8c4321b2dc940bb706a7432a530e26f0df1a
commit r10-6522-g79ab8c4321b2dc940bb706a7432a530e26f0df1a
Author: Jakub Jelinek
Date: Sat Feb 8 10:59:40 2020 +0100
i386: Make xmm16-xmm31 call used even in ms ABI [PR65782]
On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> I guess that Comment #9 patch form the PR should be trivially correct,
> but althouhg it looks obvious, I don't want to propose the patch since
> I have no means of testing it.
I don't have means of testing it either.
https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
is quite explicit that [xyz]mm16-31 are call clobbered and only xmm6-15
(low
128-bits only) are call preserved.
We are talking e.g. about
/* { dg-options "-O2 -mabi=ms -mavx512vl" } */
typedef double V __attribute__((vector_size (16)));
void foo (void);
V bar (void);
void baz (V);
void
qux (void)
{
V c;
{
register V a __asm ("xmm18");
V b = bar ();
asm ("" : "=x" (a) : "0" (b));
c = a;
}
foo ();
{
register V d __asm ("xmm18");
V e;
d = c;
asm ("" : "=x" (e) : "0" (d));
baz (e);
}
}
where according to the MSDN doc gcc incorrectly holds the c value
in xmm18 register across the foo call; if foo is compiled by some Microsoft
compiler (or LLVM), then it could clobber %xmm18.
If all xmm18 occurrences are changed to say xmm15, then it is valid to hold
the 128-bit value across the foo call (though, surprisingly, LLVM saves it
into stack anyway).
The other parts are I guess mainly about SEH. Consider e.g.
void
foo (void)
{
register double x __asm ("xmm14");
register double y __asm ("xmm18");
asm ("" : "=x" (x));
asm ("" : "=v" (y));
x += y;
y += x;
asm ("" : : "x" (x));
asm ("" : : "v" (y));
}
looking at cross-compiler output, with -O2 -mavx512f this emits
.file "abcdeq.c"
.text
.align 16
.globl foo
.deffoo;.scl2; .type 32; .endef
.seh_proc foo
foo:
subq$40, %rsp
.seh_stackalloc 40
vmovaps %xmm14, (%rsp)
.seh_savexmm%xmm14, 0
vmovaps %xmm18, 16(%rsp)
.seh_savexmm%xmm18, 16
.seh_endprologue
vaddsd %xmm18, %xmm14, %xmm14
vaddsd %xmm18, %xmm14, %xmm18
vmovaps (%rsp), %xmm14
vmovaps 16(%rsp), %xmm18
addq$40, %rsp
ret
.seh_endproc
.ident "GCC: (GNU) 10.0.1 20200207 (experimental)"
Does whatever assembler mingw64 uses even assemble this (I mean the
.seh_savexmm %xmm16, 16 could be problematic)?
I can find e.g.
https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin/43210527
which then links to
https://gcc.gnu.org/PR65782
2020-02-08 Uroš Bizjak
Jakub Jelinek
PR target/65782
* config/i386/i386.h (CALL_USED_REGISTERS): Make
xmm16-xmm31 call-used even in 64-bit ms-abi.
* gcc.target/i386/pr65782.c: New test.
Co-authored-by: Uroš Bizjak
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 Agner Fog changed: What|Removed |Added CC||agner at agner dot org --- Comment #6 from Agner Fog --- I get the same error with G++ 7.4.0 Cygwin when compiling with option -mavx512vl -m64. A workaround is to use -fno-asynchronous-unwind-tables Register xmm16-31 should be considered clobbered in Win64. See https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 --- Comment #5 from Daniel Fruzynski --- I got following link: https://stackoverflow.com/questions/53733624/is-xmm8-register-value-preserved-across-calls/53733767#53733767 Quote from it: "Any additional registers for newer instruction sets are volatile by default. This includes the upper parts of YMM0-15 and ZMM0-15 as well as ?MM16-31 if present.". So it looks that gcc should not generate .seh_savexmm for xmm16..31 at all.
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 --- Comment #4 from Daniel Fruzynski --- I have found that I can use -ffixed-reg option for this. It allows to eliminate one register, so I have to use it 16 times to eliminate all xmm16..31 registers. It would be handy to have another option which would allow to disable all registers from this group together.
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 Daniel Fruzynski changed: What|Removed |Added CC||bugzilla@poradnik-webmaster ||a.com --- Comment #3 from Daniel Fruzynski --- Cygwin (x86_64-pc-cygwin) is also affected. I have encountered this bug on gcc 7.4.0. Could you add new option which would remove XMM16+ registers from available registers pool? It could be used as an easy to use workaround until you fix it properly.
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- For the xmm16 to xmm31 registers a possible workaround could be to turn those registers fixed on mingw (thus unavailable for register allocation and not call saved). See PR79127.
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-22 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kai Tietz --- This issue is related to output in gcc for SEH-prologue pseudos. It tries to output registers not being supported 8-byte SSE ones. Generally, AVX512 can't be supported in an 32-byte aligned way on x64 target anyway.
