https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89992
Bug ID: 89992
Summary: Vectorizer is very sensitive to function calls
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: midd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Jeffrey A. Law changed:
What|Removed |Added
CC||segher at kernel dot
crashing.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382
--- Comment #5 from Steve Kargl ---
On Fri, Apr 05, 2019 at 10:24:15AM +, janus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382
>
> --- Comment #4 from janus at gcc dot gnu.org ---
> (In reply to kargl from com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89968
--- Comment #4 from Martin Sebor ---
The alignment is respected for members of other types than char so the order of
the attributes doesn't seem to matter here (it does matter in pr89950):
$ cat pr89968-2.c && gcc -S -O2 -Wall -fdump-tree-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89950
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89986
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87431
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89993
Bug ID: 89993
Summary: Inconsistent incoming stack boundary
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382
--- Comment #6 from Steve Kargl ---
On Fri, Apr 05, 2019 at 11:15:30PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> We could add
>
> #define GFC_STD_OPT_GNU03 (GFC_STD_OPT_F03 | GFC_STD_GNU)
> #define GFC_STD_OPT_GNU08 (GFC_STD_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #40 from Segher Boessenkool ---
You'll get much better results if you don't use insv in your machine
description; writing it with the input and output separate (and then
using a "0" constraint) is much friendlier to the optimisers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #41 from Segher Boessenkool ---
Seeing that the code in your examples can be expressed as a bitfield insert
requires that combine sees that only the low 8 bits of reg 93 can be non-zero,
by the way. It usually does not know this. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960
--- Comment #19 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #18)
> Hmm, so if we'd have numbered stmts in an EBB we could check the
> distance between set and use and not combine when that gets too big?
Yeah. Or we c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #11 from Segher Boessenkool ---
(In reply to Wilco from comment #8)
> push{r4, lr}
> mov r4, r0
> cmp r4, #0
Why does it copy r0 to r4 and then compare r4? On more modern machines it
is faster to compar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #12 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #11)
> (In reply to Wilco from comment #8)
> > mov r4, r0
> > cmp r4, #0
>
> Why does it copy r0 to r4 and then compare r4? On more modern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
--- Comment #3 from t.sprodowski at web dot de ---
Octave 4.2.2: ans = 2.6284e-20 + 4.2924e-04i
101 - 117 of 117 matches
Mail list logo
