https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84522
--- Comment #2 from Ruslan Nikolaev ---
Yes, but not having atomic_load is far less an issue. Oftentimes, algorithms
that use 128-bit can simply use compare_and_exchange only (at least for
x86-64).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84453
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964
--- Comment #10 from Carl Love ---
These builtins were per a request from Steve Monroe. Not sure why he wanted
them or if he actually ever used them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84495
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81116
Thomas Koenig changed:
What|Removed |Added
CC||david.sagan at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
David Malcolm changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84522
--- Comment #3 from Ruslan Nikolaev ---
(In reply to Ruslan Nikolaev from comment #2)
> Yes, but not having atomic_load is far less an issue. Oftentimes, algorithms
> that use 128-bit can simply use compare_and_exchange only (at least for
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84346
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84424
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84424
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Thu Feb 22 22:50:37 2018
New Revision: 257924
URL: https://gcc.gnu.org/viewcvs?rev=257924=gcc=rev
Log:
PR c++/84424 - ICE with constexpr and __builtin_shuffle.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70468
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84424
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84524
Bug ID: 84524
Summary: -O3 causes behavior change
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84522
--- Comment #5 from Ruslan Nikolaev ---
After more t(In reply to Andrew Pinski from comment #1)
> IIRC this was done because there is no atomic load/stores or a way to do
> backwards compatible.
After more thinking about it... Should not it be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781
--- Comment #18 from Thomas Koenig ---
Author: tkoenig
Date: Thu Feb 22 22:01:53 2018
New Revision: 257917
URL: https://gcc.gnu.org/viewcvs?rev=257917=gcc=rev
Log:
2018-02-22 Thomas Koenig
PR fortran/59781
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
--- Comment #12 from Wilco ---
Note PR64242 is related (also frame pointer corruption by __builtin_longjmp).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84525
Bug ID: 84525
Summary: GCC7: generate movaps instruction when assign to
unaligned __int128*
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
--- Comment #9 from Wilco ---
(In reply to Jakub Jelinek from comment #7)
> cfun->has_nonlocal_label instead of cfun->calls_setjmp would cover
> __builtin_setjmp.
Do non-local labels do the same odd thing? It seems to me if the mid-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
--- Comment #10 from Ramana Radhakrishnan ---
(In reply to Jakub Jelinek from comment #4)
> Is the requirement just for functions that contain setjmp? If so, the
> backend could just force frame pointers in cfun->calls_setjmp functions.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
--- Comment #11 from Wilco ---
(In reply to Ramana Radhakrishnan from comment #10)
> (In reply to Jakub Jelinek from comment #4)
> > Is the requirement just for functions that contain setjmp? If so, the
> > backend could just force frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84525
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81228
--- Comment #10 from sudi at gcc dot gnu.org ---
Author: sudi
Date: Thu Feb 22 15:01:05 2018
New Revision: 257901
URL: https://gcc.gnu.org/viewcvs?rev=257901=gcc=rev
Log:
Adding the missing LTGT to plug the ICE in PR81228.
This is a backport of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81228
sudi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84516
Bug ID: 84516
Summary: bitfield temporaries > 32-bits have wrong type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #17 from Tom Tromey ---
The results in comment #13 seem to be missing some compilations --
I would have expected to see more files from libcpp in there.
As it is I only see directives.o and line-map.o.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
--- Comment #7 from Marc Glisse ---
Unless vectors count as aggregates (more or less), in which case we can ignore
my previous comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81572
--- Comment #3 from Vladimir Makarov ---
I am working on this PR. The patch will be ready today or tomorrow.
The problem is that the move insn has one alternative with early clobber and
this move insn is processed on a fast path which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84515
Bug ID: 84515
Summary: missed optimization: expected loop merging
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
101 - 130 of 130 matches
Mail list logo