public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization
@ 2014-01-29 20:31 ebotcazou at gcc dot gnu.org
2014-01-29 21:06 ` [Bug middle-end/59990] " joseph at codesourcery dot com
` (27 more replies)
0 siblings, 28 replies; 29+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2014-01-29 20:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
Bug ID: 59990
Summary: [4.7/4.8/4.9 regression] incorrect memcpy optimization
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ebotcazou at gcc dot gnu.org
Target: i?86-*-*
This is a regression introduced in the 4.7.x series of compilers, visible on
x86 but probably reproducible on other platforms. If you compile:
extern void abort (void);
unsigned char value[4] = { 66, 9, 160, 255 };
int main (void)
{
volatile float f;
unsigned char a[4];
__builtin_memcpy ((void *)&f, value, 4);
__builtin_memcpy (a, (void *)&f, 4);
if (a[2] != 160)
abort ();
return 0;
}
with optimization enabled, it aborts at run time because FP instructions are
incorrectly used to implement the memcpy operations.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
@ 2014-01-29 21:06 ` joseph at codesourcery dot com
2014-01-29 21:17 ` [Bug target/59990] " pinskia at gcc dot gnu.org
` (26 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: joseph at codesourcery dot com @ 2014-01-29 21:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Seems rather like bug 58416 to me, if I understand it correctly (SFmode
and DFmode x87 floating-point loads wrongly used when the result is used
other than for arithmetic). Should only affect platforms where loads and
stores extend signaling NaNs to a wider format and so convert them to
quiet NaNs with an exception raised.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
2014-01-29 21:06 ` [Bug middle-end/59990] " joseph at codesourcery dot com
@ 2014-01-29 21:17 ` pinskia at gcc dot gnu.org
2014-01-29 22:28 ` [Bug middle-end/59990] " ebotcazou at gcc dot gnu.org
` (25 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: pinskia at gcc dot gnu.org @ 2014-01-29 21:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|middle-end |target
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Each target has its own code to do expansion of memcpy. The middle-end code
for memcpy uses the integer modes to do the copying and if the target gets that
incorrect then it is a bug in the target code.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
2014-01-29 21:06 ` [Bug middle-end/59990] " joseph at codesourcery dot com
2014-01-29 21:17 ` [Bug target/59990] " pinskia at gcc dot gnu.org
@ 2014-01-29 22:28 ` ebotcazou at gcc dot gnu.org
2014-01-30 3:45 ` [Bug target/59990] " hjl.tools at gmail dot com
` (24 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2014-01-29 22:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|target |middle-end
--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Each target has its own code to do expansion of memcpy. The middle-end code
> for memcpy uses the integer modes to do the copying and if the target gets
> that incorrect then it is a bug in the target code.
No, and that's precisely the bug...
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug target/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (2 preceding siblings ...)
2014-01-29 22:28 ` [Bug middle-end/59990] " ebotcazou at gcc dot gnu.org
@ 2014-01-30 3:45 ` hjl.tools at gmail dot com
2014-01-30 8:10 ` [Bug middle-end/59990] " ebotcazou at gcc dot gnu.org
` (23 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: hjl.tools at gmail dot com @ 2014-01-30 3:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-01-30
CC| |hjl.tools at gmail dot com,
| |kirill.yukhin at intel dot com,
| |ubizjak at gmail dot com
Component|middle-end |target
Target Milestone|--- |4.7.4
Ever confirmed|0 |1
--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
It is caused by r174489.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (3 preceding siblings ...)
2014-01-30 3:45 ` [Bug target/59990] " hjl.tools at gmail dot com
@ 2014-01-30 8:10 ` ebotcazou at gcc dot gnu.org
2014-01-30 8:15 ` jakub at gcc dot gnu.org
` (22 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2014-01-30 8:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|target |middle-end
--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
This is really annoying, please conduct at least a minimal analysis before
recategorizing a PR, it's a MIDDLE END issue, namely fold_builtin_memory_op
wrongly choosing a floating-point type to implement the memcpy.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (4 preceding siblings ...)
2014-01-30 8:10 ` [Bug middle-end/59990] " ebotcazou at gcc dot gnu.org
@ 2014-01-30 8:15 ` jakub at gcc dot gnu.org
2014-01-30 8:31 ` ebotcazou at gcc dot gnu.org
` (21 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-30 8:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I guess the important thing is if it is allowed to raise exceptions on a simple
load and store of a floating point value. So:
extern void abort (void);
union U
{
unsigned char value[4];
float f;
} u = { { 66, 9, 160, 255} };
int
main (void)
{
volatile union U v;
v.f = u.f;
if (v.value[2] != 160)
abort ();
return 0;
}
If it is ok that thiscase aborts and the #c0 should not, then the bug would be
in fold-const.c and we should use integral types instead of floating point
types to fold the copy. If this testcase shouldn't abort too, then it is a
target issue, where it should avoid the i387 loads if the result isn't used in
some arithmetic instruction.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (5 preceding siblings ...)
2014-01-30 8:15 ` jakub at gcc dot gnu.org
@ 2014-01-30 8:31 ` ebotcazou at gcc dot gnu.org
2014-01-30 12:08 ` rguenth at gcc dot gnu.org
` (20 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2014-01-30 8:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> If it is ok that thiscase aborts and the #c0 should not, then the bug would
> be in fold-const.c and we should use integral types instead of floating
> point types to fold the copy. If this testcase shouldn't abort too, then it
> is a target issue, where it should avoid the i387 loads if the result isn't
> used in some arithmetic instruction.
I disagree, using FP types to implement memcpy in the middle-end is a no-no,
i387 isn't the only architecture which can fiddle with FP values.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (6 preceding siblings ...)
2014-01-30 8:31 ` ebotcazou at gcc dot gnu.org
@ 2014-01-30 12:08 ` rguenth at gcc dot gnu.org
2014-01-30 12:49 ` rguenth at gcc dot gnu.org
` (19 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-01-30 12:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #7)
> > If it is ok that thiscase aborts and the #c0 should not, then the bug would
> > be in fold-const.c and we should use integral types instead of floating
> > point types to fold the copy. If this testcase shouldn't abort too, then it
> > is a target issue, where it should avoid the i387 loads if the result isn't
> > used in some arithmetic instruction.
>
> I disagree, using FP types to implement memcpy in the middle-end is a no-no,
> i387 isn't the only architecture which can fiddle with FP values.
I agree and I have a fix. Fortunately it's very easy and cleans up the code
even ;)
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (7 preceding siblings ...)
2014-01-30 12:08 ` rguenth at gcc dot gnu.org
@ 2014-01-30 12:49 ` rguenth at gcc dot gnu.org
2014-01-30 12:53 ` rguenth at gcc dot gnu.org
` (18 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-01-30 12:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (8 preceding siblings ...)
2014-01-30 12:49 ` rguenth at gcc dot gnu.org
@ 2014-01-30 12:53 ` rguenth at gcc dot gnu.org
2014-01-30 13:15 ` jakub at gcc dot gnu.org
` (17 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-01-30 12:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 31991
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31991&action=edit
patch
Must resist turning this fn upside down ...
Anyway, untested patch attached. We can surely do better selecting a
type, but IIRC most targets have an integer mode that covers all other
modes (even vector modes).
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (9 preceding siblings ...)
2014-01-30 12:53 ` rguenth at gcc dot gnu.org
@ 2014-01-30 13:15 ` jakub at gcc dot gnu.org
2014-01-30 16:43 ` joseph at codesourcery dot com
` (16 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-30 13:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That will likely break -fsanitize=enum as you are removing the handling of the
enums. Can you please handle it the same if -fsanitize=enum (or always?).
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (10 preceding siblings ...)
2014-01-30 13:15 ` jakub at gcc dot gnu.org
@ 2014-01-30 16:43 ` joseph at codesourcery dot com
2014-01-30 17:38 ` jakub at gcc dot gnu.org
` (15 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: joseph at codesourcery dot com @ 2014-01-30 16:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 30 Jan 2014, jakub at gcc dot gnu.org wrote:
> I guess the important thing is if it is allowed to raise exceptions on a simple
> load and store of a floating point value. So:
At C level, if we follow draft TS 18661-1 (WG14 N1778) for specification
of signaling NaNs, "Whether C assignment (6.5.16) (and conversion as if by
assignment) to the same format is an IEC 60559 convertFormat or copy
operation is implementation-defined, even if <fenv.h> defines the macro
FE_SNANS_ALWAYS_SIGNAL". I think it's most useful for such assignments,
function calling etc. to be implemented not to raise exceptions - doing
otherwise prevents properly implementing issignaling. But when actual
floating-point assignments are involved (as in bug 56831) it's only really
a bug with -fsignaling-nans (although if there isn't any significant
performance cost it's probably best not to depend on that).
When, as in bug 58416 and here, there are no floating-point assignments
involved, it's entirely unambiguously a bug to raise exceptions.
> If it is ok that thiscase aborts and the #c0 should not, then the bug would be
> in fold-const.c and we should use integral types instead of floating point
> types to fold the copy. If this testcase shouldn't abort too, then it is a
> target issue, where it should avoid the i387 loads if the result isn't used in
> some arithmetic instruction.
And if the value is both used in arithmetic and copied with memcpy, the
copy can't reuse the value that was loaded into a floating-point register
for the arithmetic (because the copy needs to copy the original signaling
NaN to the destination, not the quiet NaN that resulted from the
floating-point load).
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (11 preceding siblings ...)
2014-01-30 16:43 ` joseph at codesourcery dot com
@ 2014-01-30 17:38 ` jakub at gcc dot gnu.org
2014-01-31 11:39 ` rguenth at gcc dot gnu.org
` (14 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-30 17:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #9)
> Created attachment 31991 [details]
> patch
>
> Must resist turning this fn upside down ...
>
> Anyway, untested patch attached. We can surely do better selecting a
> type, but IIRC most targets have an integer mode that covers all other
> modes (even vector modes).
Besides the GET_MODE_SIZE -> GET_MODE_BITSIZE fix and handling ENUMERAL_TYPEs
similarly for -fsanitize=enum, do you think you could add the
build_aligned_type call too? I mean, if say the floating
point/boolean/complex/enum type has certain alignment and the integral type we
are going to use instead has different, it would be better to preserve the
alignment info.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (12 preceding siblings ...)
2014-01-30 17:38 ` jakub at gcc dot gnu.org
@ 2014-01-31 11:39 ` rguenth at gcc dot gnu.org
2014-01-31 11:55 ` [Bug middle-end/59990] [4.7/4.8 " rguenth at gcc dot gnu.org
` (13 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-01-31 11:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (13 preceding siblings ...)
2014-01-31 11:39 ` rguenth at gcc dot gnu.org
@ 2014-01-31 11:55 ` rguenth at gcc dot gnu.org
2014-01-31 11:55 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-01-31 11:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P3
Known to work| |4.9.0
Summary|[4.7/4.8/4.9 regression] |[4.7/4.8 regression]
|incorrect memcpy |incorrect memcpy
|optimization |optimization
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for trunk sofar.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (14 preceding siblings ...)
2014-01-31 11:55 ` [Bug middle-end/59990] [4.7/4.8 " rguenth at gcc dot gnu.org
@ 2014-01-31 11:55 ` rguenth at gcc dot gnu.org
2014-01-31 11:55 ` [Bug middle-end/59990] [4.7/4.8/4.9 " rguenth at gcc dot gnu.org
` (11 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-01-31 11:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8/4.9 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (15 preceding siblings ...)
2014-01-31 11:55 ` rguenth at gcc dot gnu.org
@ 2014-01-31 11:55 ` rguenth at gcc dot gnu.org
2014-02-10 15:25 ` [Bug middle-end/59990] [4.7/4.8 " rguenth at gcc dot gnu.org
` (10 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-01-31 11:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Fri Jan 31 11:54:26 2014
New Revision: 207338
URL: http://gcc.gnu.org/viewcvs?rev=207338&root=gcc&view=rev
Log:
2014-01-31 Richard Biener <rguenther@suse.de>
PR middle-end/59990
* builtins.c (fold_builtin_memory_op): Make sure to not
use a floating-point mode or a boolean or enumeral type for
the copy operation.
* gcc.dg/torture/pr59990.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.dg/torture/pr59990.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (16 preceding siblings ...)
2014-01-31 11:55 ` [Bug middle-end/59990] [4.7/4.8/4.9 " rguenth at gcc dot gnu.org
@ 2014-02-10 15:25 ` rguenth at gcc dot gnu.org
2014-02-10 15:29 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-02-10 15:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Backporting this to 4.8 regresses
//-m32
FAIL: gcc.target/i386/pr49168-1.c scan-assembler movdqu[\t ]*%xmm[0-9]+,[^,]*
flt128_va:
.LFB0:
.cfi_startproc
movl 4(%esp), %eax
movdqa 20(%esp), %xmm0
movlps %xmm0, (%eax)
movhps %xmm0, 8(%eax)
ret
expanding from
flt128_va (void * mem, __float128 d)
{
uint128_t _2;
;; basic block 2, loop depth 0
;; pred: ENTRY
_2 = VIEW_CONVERT_EXPR<uint128_t>(d_5(D));
MEM[(char * {ref-all})mem_3(D)] = _2;
return;
which doesn't end up using a UNSPEC_STOREU insn as on trunk but
(insn 8 7 0 2 (set (mem:V2SF (plus:SI (reg/v/f:SI 60 [ mem ])
(const_int 8 [0x8])) [0 MEM[(char * {ref-all})mem_3(D)]+8 S8
A8])
(vec_select:V2SF (subreg:V4SF (reg/v:TF 61 [ d ]) 0)
(parallel [
(const_int 2 [0x2])
(const_int 3 [0x3])
])))
/space/rguenther/src/svn/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr49168-1.c:10
-1
(nil))
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (17 preceding siblings ...)
2014-02-10 15:25 ` [Bug middle-end/59990] [4.7/4.8 " rguenth at gcc dot gnu.org
@ 2014-02-10 15:29 ` rguenth at gcc dot gnu.org
2014-06-12 13:46 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-02-10 15:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
seems to be TARGET_SSE_TYPELESS_STORES tuning dependent (and that was changed
on trunk for generic).
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.7/4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (18 preceding siblings ...)
2014-02-10 15:29 ` rguenth at gcc dot gnu.org
@ 2014-06-12 13:46 ` rguenth at gcc dot gnu.org
2014-12-19 13:29 ` [Bug middle-end/59990] [4.8 " jakub at gcc dot gnu.org
` (7 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-06-12 13:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.7.4 |4.8.4
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (19 preceding siblings ...)
2014-06-12 13:46 ` rguenth at gcc dot gnu.org
@ 2014-12-19 13:29 ` jakub at gcc dot gnu.org
2015-02-16 13:19 ` anders.blomdell at control dot lth.se
` (6 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-12-19 13:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.8.4 |4.8.5
--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (20 preceding siblings ...)
2014-12-19 13:29 ` [Bug middle-end/59990] [4.8 " jakub at gcc dot gnu.org
@ 2015-02-16 13:19 ` anders.blomdell at control dot lth.se
2015-02-16 13:20 ` anders.blomdell at control dot lth.se
` (5 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: anders.blomdell at control dot lth.se @ 2015-02-16 13:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
anders.blomdell at control dot lth.se changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anders.blomdell at control dot lth
| |.se
--- Comment #19 from anders.blomdell at control dot lth.se ---
Created attachment 34775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34775&action=edit
preprocessed program
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (21 preceding siblings ...)
2015-02-16 13:19 ` anders.blomdell at control dot lth.se
@ 2015-02-16 13:20 ` anders.blomdell at control dot lth.se
2015-02-16 13:23 ` anders.blomdell at control dot lth.se
` (4 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: anders.blomdell at control dot lth.se @ 2015-02-16 13:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #20 from anders.blomdell at control dot lth.se ---
Created attachment 34776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34776&action=edit
Shell-script for testing flag variations
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (22 preceding siblings ...)
2015-02-16 13:20 ` anders.blomdell at control dot lth.se
@ 2015-02-16 13:23 ` anders.blomdell at control dot lth.se
2015-02-16 13:25 ` anders.blomdell at control dot lth.se
` (3 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: anders.blomdell at control dot lth.se @ 2015-02-16 13:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #21 from anders.blomdell at control dot lth.se ---
Sorry attachments belongs to bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (23 preceding siblings ...)
2015-02-16 13:23 ` anders.blomdell at control dot lth.se
@ 2015-02-16 13:25 ` anders.blomdell at control dot lth.se
2015-02-16 13:26 ` anders.blomdell at control dot lth.se
` (2 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: anders.blomdell at control dot lth.se @ 2015-02-16 13:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #22 from anders.blomdell at control dot lth.se ---
Sorry attachments belongs to bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (24 preceding siblings ...)
2015-02-16 13:25 ` anders.blomdell at control dot lth.se
@ 2015-02-16 13:26 ` anders.blomdell at control dot lth.se
2015-06-10 12:53 ` rguenth at gcc dot gnu.org
2015-06-10 13:51 ` rguenth at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: anders.blomdell at control dot lth.se @ 2015-02-16 13:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #23 from anders.blomdell at control dot lth.se ---
Sorry attachments belongs to bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (25 preceding siblings ...)
2015-02-16 13:26 ` anders.blomdell at control dot lth.se
@ 2015-06-10 12:53 ` rguenth at gcc dot gnu.org
2015-06-10 13:51 ` rguenth at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-06-10 12:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Wed Jun 10 12:53:09 2015
New Revision: 224327
URL: https://gcc.gnu.org/viewcvs?rev=224327&root=gcc&view=rev
Log:
2015-06-10 Richard Biener <rguenther@suse.de>
Backport from mainline
2014-04-04 Cong Hou <congh@google.com>
PR tree-optimization/60656
* tree-vect-stmts.c (supportable_widening_operation):
Fix a bug that elements in a vector with vect_used_by_reduction
property are incorrectly reordered when the operation on it is not
consistant with the one in reduction operation.
* gcc.dg/vect/pr60656.c: New test.
2014-01-31 Richard Biener <rguenther@suse.de>
PR middle-end/59990
* builtins.c (fold_builtin_memory_op): Make sure to not
use a floating-point mode or a boolean or enumeral type for
the copy operation.
* gcc.dg/torture/pr59990.c: New testcase.
* gcc.target/i386/pr49168-1.c: Adjust.
Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59990.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr60656.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/builtins.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr49168-1.c
branches/gcc-4_8-branch/gcc/tree-vect-stmts.c
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
` (26 preceding siblings ...)
2015-06-10 12:53 ` rguenth at gcc dot gnu.org
@ 2015-06-10 13:51 ` rguenth at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-06-10 13:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2015-06-10 13:51 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-29 20:31 [Bug middle-end/59990] New: [4.7/4.8/4.9 regression] incorrect memcpy optimization ebotcazou at gcc dot gnu.org
2014-01-29 21:06 ` [Bug middle-end/59990] " joseph at codesourcery dot com
2014-01-29 21:17 ` [Bug target/59990] " pinskia at gcc dot gnu.org
2014-01-29 22:28 ` [Bug middle-end/59990] " ebotcazou at gcc dot gnu.org
2014-01-30 3:45 ` [Bug target/59990] " hjl.tools at gmail dot com
2014-01-30 8:10 ` [Bug middle-end/59990] " ebotcazou at gcc dot gnu.org
2014-01-30 8:15 ` jakub at gcc dot gnu.org
2014-01-30 8:31 ` ebotcazou at gcc dot gnu.org
2014-01-30 12:08 ` rguenth at gcc dot gnu.org
2014-01-30 12:49 ` rguenth at gcc dot gnu.org
2014-01-30 12:53 ` rguenth at gcc dot gnu.org
2014-01-30 13:15 ` jakub at gcc dot gnu.org
2014-01-30 16:43 ` joseph at codesourcery dot com
2014-01-30 17:38 ` jakub at gcc dot gnu.org
2014-01-31 11:39 ` rguenth at gcc dot gnu.org
2014-01-31 11:55 ` [Bug middle-end/59990] [4.7/4.8 " rguenth at gcc dot gnu.org
2014-01-31 11:55 ` rguenth at gcc dot gnu.org
2014-01-31 11:55 ` [Bug middle-end/59990] [4.7/4.8/4.9 " rguenth at gcc dot gnu.org
2014-02-10 15:25 ` [Bug middle-end/59990] [4.7/4.8 " rguenth at gcc dot gnu.org
2014-02-10 15:29 ` rguenth at gcc dot gnu.org
2014-06-12 13:46 ` rguenth at gcc dot gnu.org
2014-12-19 13:29 ` [Bug middle-end/59990] [4.8 " jakub at gcc dot gnu.org
2015-02-16 13:19 ` anders.blomdell at control dot lth.se
2015-02-16 13:20 ` anders.blomdell at control dot lth.se
2015-02-16 13:23 ` anders.blomdell at control dot lth.se
2015-02-16 13:25 ` anders.blomdell at control dot lth.se
2015-02-16 13:26 ` anders.blomdell at control dot lth.se
2015-06-10 12:53 ` rguenth at gcc dot gnu.org
2015-06-10 13:51 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).