https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Bug 57359 depends on bug 95172, which changed state.
Bug 95172 Summary: [11 Regression] wrong code at -O1 on x86_64-linux-gnu since
r11-272-gb6ff3ddecfa93d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95172
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Bug 57359 depends on bug 94988, which changed state.
Bug 94988 Summary: [11 Regression] FAIL: gcc.target/i386/pr64110.c
scan-assembler vmovd[\\t ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Bug 57359 depends on bug 94988, which changed state.
Bug 94988 Summary: [11 Regression] FAIL: gcc.target/i386/pr64110.c
scan-assembler vmovd[\\t ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Bug 57359 depends on bug 95045, which changed state.
Bug 95045 Summary: [11 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95045
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Bug 57359 depends on bug 94988, which changed state.
Bug 94988 Summary: [11 Regression] FAIL: gcc.target/i386/pr64110.c
scan-assembler vmovd[\\t ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94988
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Bug 57359 depends on bug 95025, which changed state.
Bug 95025 Summary: [11 Regression] ICE in execute_sm_exit at
gcc/tree-ssa-loop-im.c:2224 since r11-161-g283cb9ea6293e813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95025
What|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Richard Biener changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Bug 57359 depends on bug 90668, which changed state.
Bug 90668 Summary: loop invariant moving a dependent store out of a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90668
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #32 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:283cb9ea6293e813e48a1b769e1e0779918ea20a
commit r11-161-g283cb9ea6293e813e48a1b769e1e0779918ea20a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Richard Biener changed:
What|Removed |Added
Attachment #48381|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #30 from Richard Biener ---
Created attachment 48381
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48381&action=edit
more complex approach, POC
Another testcase, this time for store ordering (IIRC we may have a duplicate
for
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #29 from Richard Biener ---
And another testcase showing that with a conditional invariant store we may
_never_ apply store-motion since conditional means we do not know the
original order of stores in the loop. *sigh*
typedef int A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #28 from Richard Biener ---
OK, so more "advanced" testcases are a bit difficult because the
ref_always_accessed_p logic is too simple and it's required for
store-motion of accesses in conditional paths. Basically if
we have if (test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #27 from Richard Biener ---
(In reply to Richard Biener from comment #24)
> (In reply to Richard Biener from comment #22)
> > Created attachment 48311 [details]
> > patch
> >
> > Note that apart from the possible bad impact on optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #26 from rguenther at suse dot de ---
On Mon, 20 Apr 2020, pascal_cuoq at hotmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
>
> --- Comment #25 from Pascal Cuoq ---
> Would it be reasonable to have three s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #25 from Pascal Cuoq ---
Would it be reasonable to have three settings for -fstrict-aliasing, rather
then the current two?
- off
- strict
- assume-no-reuse
(I would let you find a better name for the third one.)
It seems to me that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #24 from Richard Biener ---
(In reply to Richard Biener from comment #22)
> Created attachment 48311 [details]
> patch
>
> Note that apart from the possible bad impact on optimization when fixing this
> bug an actual fix is complicat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #23 from Richard Biener ---
(In reply to Richard Biener from comment #22)
> Created attachment 48311 [details]
> patch
>
> Note that apart from the possible bad impact on optimization when fixing this
> bug an actual fix is complicat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #22 from Richard Biener ---
Created attachment 48311
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48311&action=edit
patch
Note that apart from the possible bad impact on optimization when fixing this
bug an actual fix is comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Richard Biener changed:
What|Removed |Added
CC||pascal_cuoq at hotmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #20 from rguenther at suse dot de ---
On Fri, 17 Jan 2020, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
>
> --- Comment #19 from Andrew Pinski ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #19 from Andrew Pinski ---
(In reply to Richard Biener from comment #14)
> Testcase from PR81028
>
> extern void abort();
>
> typedef int A;
> typedef float B;
>
> void __attribute__((noinline,noclone))
> foo(A *p, B *q, long unk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Andrew Pinski changed:
What|Removed |Added
CC||msl023508 at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #17 from Richard Biener ---
We'd need to peel the last iteration as the following shows. This also means
it is not enough to prove the loop actually iterates. Peeling the last
iteration means we have to be able to identify that iter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Richard Biener changed:
What|Removed |Added
Keywords||alias
Last reconfirmed|2013-05-31 00:
27 matches
Mail list logo
