https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
Ilya Enkovich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #22 from Ilya Enkovich ---
Author: ienkovich
Date: Tue May 17 09:28:15 2016
New Revision: 236315
URL: https://gcc.gnu.org/viewcvs?rev=236315=gcc=rev
Log:
gcc/
PR target/71114
* config/i386/i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #21 from Dominique d'Humieres ---
> Probably just scan for movdqa then to get rid of addressing dependencies? Or
> use
>
> movdqa[ t]+.?LC0
>
> pattern if it works fine on Darwin.
The failure is indeed fixed with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #20 from Ilya Enkovich ---
(In reply to Dominique d'Humieres from comment #18)
> > smoke test passes, I'll leave it to Dominique's full-run to confirm.
>
> With the patch in comment 15 applied on top of revision r236286 the reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #19 from Dominique d'Humieres ---
Results at https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg01774.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #18 from Dominique d'Humieres ---
> smoke test passes, I'll leave it to Dominique's full-run to confirm.
With the patch in comment 15 applied on top of revision r236286 the reported
failures are gone.
From the fix, would it be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #17 from Iain Sandoe ---
smoke test passes, I'll leave it to Dominique's full-run to confirm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #16 from Ilya Enkovich ---
(In reply to Iain Sandoe from comment #15)
> that code won't build - did you mean :
>
Sure. Thanks for noticing!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #15 from Iain Sandoe ---
(In reply to Dominique d'Humieres from comment #14)
> > Looks I found the problem. validize_mem generates new instructions which
> > are placed wrongly. This patch should help. Unfortunately I can't test
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #14 from Dominique d'Humieres ---
> Looks I found the problem. validize_mem generates new instructions which
> are placed wrongly. This patch should help. Unfortunately I can't test
> it properly on Darwin.
Thanks for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #13 from Ilya Enkovich ---
Looks I found the problem. validize_mem generates new instructions which are
placed wrongly. This patch should help. Unfortunately I can't test it
properly on Darwin.
diff --git a/gcc/config/i386/i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #12 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #11)
> I wonder if it's a stack/data alignment problem
maybe not;
comparing 6.1 and trunk with the function annotated to
__attribute__((noinline)) it seems that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #11 from Iain Sandoe ---
I wonder if it's a stack/data alignment problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #10 from Iain Sandoe ---
(In reply to Ilya Enkovich from comment #9)
> (In reply to Iain Sandoe from comment #8)
> > Created attachment 38495 [details]
> > assembly for linux case
> >
> > Here's the asm for the case from my build,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #9 from Ilya Enkovich ---
(In reply to Iain Sandoe from comment #8)
> Created attachment 38495 [details]
> assembly for linux case
>
> Here's the asm for the case from my build, although I don't expect it'll
> help much if you can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #8 from Iain Sandoe ---
Created attachment 38495
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38495=edit
assembly for linux case
Here's the asm for the case from my build, although I don't expect it'll help
much if you can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #7 from Ilya Enkovich ---
(In reply to Dominique d'Humieres from comment #2)
> Created attachment 38486 [details]
> Assembly for gcc.c-torture/execute/ashldi-1.c compiled with r236090
>
> Assembly for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #6 from Ilya Enkovich ---
(In reply to Iain Sandoe from comment #5)
> Also fails on Linux for the m32 multilib with -msse2avx :
> make -k check-gcc-c
> RUNTESTFLAGS="--target_board=unix/-msse/-msse2avx\{-m32,-m64\}
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
Iain Sandoe changed:
What|Removed |Added
Target|x86_64-apple-darwin*|x86_64-apple-darwin*,x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #4 from Dominique d'Humieres ---
Reduced test
#include
extern void abort(void);
extern void exit(int);
#define BITS 8
static unsigned long long const data[8] = {
0x123456789abcdefULL,
0x2468acf13579bdeULL,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
Dominique d'Humieres changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #2 from Dominique d'Humieres ---
Created attachment 38486
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38486=edit
Assembly for gcc.c-torture/execute/ashldi-1.c compiled with r236090
Assembly for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114
--- Comment #1 from Dominique d'Humieres ---
Created attachment 38485
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38485=edit
Assembly for gcc.c-torture/execute/ashldi-1.c for r236089
Assembly for gcc.c-torture/execute/ashldi-1.c
25 matches
Mail list logo
