https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114494
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673
Andrew Pinski changed:
What|Removed |Added
CC||akihiko.odaki at daynix dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 114494, which changed state.
Bug 114494 Summary: false-positive with -O2 -Wstringop-overflow=2
-fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114494
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114167
Andrew Pinski changed:
What|Removed |Added
CC||andipeer at gmx dot net
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114495
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114167
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114414
--- Comment #1 from Richard Biener ---
I'll note the performance is now again close to that of 12/13 but improvements
have been lost (so it might be not called a 14 regression).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114482
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477
--- Comment #5 from Jiang An ---
(In reply to 康桓瑋 from comment #0)
> Since P3059R0 is closed (although I feel bad about this)
BTW, now I think this is somehow unfortunate.
P3059 behaved like a follow-up paper of P2711 IMO. Both papers effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114496
Bug ID: 114496
Summary: Documentation: "Non-Bugs" page should update/mention
something about -Wsign-conversion
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477
--- Comment #6 from 康桓瑋 ---
(In reply to Jiang An from comment #5)
> (In reply to 康桓瑋 from comment #0)
> > Since P3059R0 is closed (although I feel bad about this)
>
> BTW, now I think this is somehow unfortunate.
> P3059 behaved like a follow-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114496
--- Comment #1 from Andrew Pinski ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485
--- Comment #3 from Richard Biener ---
Huh.
_75 = [vec_duplicate_expr] pretmp_34;
_76 = -_75;
_77 = VEC_PERM_EXPR <_75, _76, { 0, POLY_INT_CST [4, 4], 1, POLY_INT_CST [5,
4], 2, POLY_INT_CST [6, 4], ... }>;
# c_lsm.7_8 = PHI <_2(9), pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114496
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-27
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
Richard Biener changed:
What|Removed |Added
Summary|[14 regression] ICE when|ICE when building libsdl2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302
--- Comment #1 from Richard Sandiford ---
The decision to stop narrowing division was deliberate, see the comments in
PR113281 for details. Is the purpose of the test to check vectorisation
quality, or to check for the right ABI routines?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114481
--- Comment #1 from Richard Biener ---
Looks like speed is back to 12/13, so possibly not a regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302
--- Comment #2 from Andrew Stubbs ---
The execution test checks that each of the libgcc routines work correctly, and
the scan assembler tests make sure that we're getting coverage of all of them.
In this case, the failure indicates that we're n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302
--- Comment #3 from Richard Sandiford ---
Ah, ok. If the main aim is to test the libgcc routines, it might be safer to
use something like:
typedef char v64qi __attribute__((vector_size(64)));
v64qi f(v64qi x, v64qi y) { return x / y; }
instea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670
Bug 88670 depends on bug 112787, which changed state.
Bug 112787 Summary: Codegen regression of large GCC vector extensions when
enabling SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
Eric Botcazou changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
--- Comment #2 from Uroš Bizjak ---
(In reply to Richard Biener from comment #1)
> (insn 6 5 0 (set (reg/v:SF 99 [ gamma ])
> (reg:SF 20 xmm0)) "testautomation-testautomation_pixels.i":15:17 -1
> (nil))
>
> I'm not sure what's wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
--- Comment #3 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #2)
> Adding -msse to the second compilation works OK, removing -mfpmath=sse from
> the first compilation also works OK.
Which makes this PR a LTO reincarnation of PR6604
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > Adding -msse to the second compilation works OK, removing -mfpmath=sse from
> > the first compilation also works OK.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477
--- Comment #7 from Jonathan Wakely ---
The notes say it was closed because you didn't want to work on it.
https://github.com/cplusplus/papers/issues/1726#issuecomment-2014094319
It sounds like the Ranges study group supported the direction. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
Jakub Kulik changed:
What|Removed |Added
CC||jakub.kulik at oracle dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #7 from Jakub Kulik ---
Hmm, I just realized that you referred to the same sections, so my previous
comment might not make it clearer...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #8 from Eric Botcazou ---
> Hmm, I just realized that you referred to the same sections, so my previous
> comment might not make it clearer...
Yes, the fields in question have array types so the rules about scalar values
do not obvi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #9 from Eric Botcazou ---
> Thank you for the proposed fix! I tested it with several programs that I
> used to find/reproduce the issue and it seems to work now (I talked about
> this with Rainer initially).
OK, thanks for the testi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113885
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114497
Bug ID: 114497
Summary: Alias CTAD crashes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
--- Comment #12 from Richard Biener ---
OK, so I think the change is that we get to "correctly" notice
-vec.h:380:9: note: node (external) 0x6a2e9d8 (max_nunits=2, refcnt=1)
vector(2) float
-vec.h:380:9: note: stmt 0 _164 = MEM[(const real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114490
--- Comment #4 from Kang-Che Sung ---
1. I just read "AMD64 Architecture Programmer's Manual - Volume 3:
General-Purpose and System Instructions"
(https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114497
Centurion changed:
What|Removed |Added
CC||centurionn009 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
--- Comment #13 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0b02da5b99e89347f5f8bf875ec8318f84adff18
commit r14-9687-g0b02da5b99e89347f5f8bf875ec8318f84adff18
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114057
--- Comment #14 from Richard Biener ---
I wasn't able to reproduce the miscompare on a Zen4 machine (but with
-march=znver2). But the original vectorizataion of bondfree.c should be
restored and thus the miscompare gone. I'll verify tomorrow w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90745
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90745
--- Comment #8 from Jonathan Wakely ---
Replacing delctype(auto) on the cell::operator=(X&&) function (or constraining
that function to not be instantiated for non-assignable cells) will fix the
code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100381
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302
--- Comment #4 from Andrew Stubbs ---
Yes, that's what the simd-math-3* tests do.
The simd-math-5* tests are explicitly supposed to be doing this in the context
of the autovectorizer.
If these tests are being compiled as (newly) intended then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114490
Kang-Che Sung changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302
--- Comment #5 from Richard Sandiford ---
(In reply to Andrew Stubbs from comment #4)
> Yes, that's what the simd-math-3* tests do.
Ah, OK.
> The simd-math-5* tests are explicitly supposed to be doing this in the
> context of the autovectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114498
Bug ID: 114498
Summary: Consider deprecating then removing TR1 headers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #18 from Xi Ruoyao ---
(In reply to chenglulu from comment #17)
> The results of spec2006 on LA464 are:
> -falign-labels=4 -falign-functions=32 -falign-loops=16 -falign-jumps=16
Would you send a patch for them or prefer I to do it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
--- Comment #6 from Jonathan Wakely ---
(In reply to Piotr Nycz from comment #0)
> It looks that std library code start requiring this to pass:
> std::is_nothrow_constructible...
Indeed, that's what the standard requires (Clang and MSVC reject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
--- Comment #6 from Richard Biener ---
I'd say ix86_function_sseregparm should be decided at a specific point and
recorded for later use. Alternatively there needs to be a (target) IPA
phase where we can mark functions we cannot turn into ssere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111966
Thomas Schwinge changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114498
--- Comment #1 from Richard Biener ---
I'd say deprecating them for a release aka hiding behind a
-D_YES_I_WANT_TR1_HEADERS and otherwise issueing #error and then axing them
should be OK.
Preferably tell people about a suitable replacement (or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
--- Comment #7 from Jonathan Wakely ---
(In reply to Viktor Ostashevskyi from comment #1)
> I have another example, but probably related:
No, this is a completely different problem. See Bug 102257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-03-27
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
--- Comment #5 from Jonathan Wakely ---
I think this is the same bug, reduced from Bug 100667 comment 1 (where it
wasn't related):
struct allocator_arg_t { explicit allocator_arg_t() = default; };
class string{};
class Foo{};
struct tuple
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
--- Comment #8 from Jakub Jelinek ---
Looking at other intrinsics with {,unsigned }__int64{, const} * arguments, I
see
void _mm_maskstore_epi64 (__int64* mem_addr, __m128i mask, __m128i a)
void _mm256_maskstore_epi64 (__int64* mem_addr, __m256i m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
--- Comment #6 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #2)
> See https://wg21.link/cwg1228 this might be invalid code and GCC is correct
> in rejecting it.
So dup of PR 84849 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
--- Comment #9 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #7)
> The other option is to change how intrinsics work on x86 and use resolve
> overloads inside the backend like how aarch64, arm and rs6000 backends all
> handle int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
*To be removed from our mailing list, please respond to this message with
UNSUBSCRIBE in the subject line*
--
**
11th INTERNATIONAL SCHOOL ON DEEP LEARNING
(and the Future of Artificial Intelligence)
DeepLearn 2024
Porto – Maia, Por
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #18 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858
Richard Biener changed:
What|Removed |Added
Summary|[14 Regression] nvptx: |nvptx: 'unresolved symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114499
Bug ID: 114499
Summary: MVE: scatter base offset constraints incorrect
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #19 from chenglulu ---
(In reply to Xi Ruoyao from comment #18)
> (In reply to chenglulu from comment #17)
>
> > The results of spec2006 on LA464 are:
> > -falign-labels=4 -falign-functions=32 -falign-loops=16 -falign-jumps=16
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
--- Comment #8 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Piotr Nycz from comment #0)
> > It looks that std library code start requiring this to pass:
> > std::is_nothrow_constructible...
>
> Indeed, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
--- Comment #9 from Jonathan Wakely ---
The changes in
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1285r0.pdf mean that
it's only undefined if the result of is_constructible_v would change
were T completed. So there's no benefit to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114377
--- Comment #3 from Patrick Palka ---
*** Bug 114497 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114497
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485
--- Comment #4 from Robin Dapp ---
Yes, the vectorization looks ok. The extracted live values are not used
afterwards and therefore the whole vectorized loop is being thrown away.
Then we do one iteration of the epilogue loop, inverting the ori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
--- Comment #10 from Jonathan Wakely ---
Oh interestingly __is_constructible(Incomplete&&, Incomplete) is already
allowed, but __is_nothrow_constructible and __is_convertible give errors:
__is_nothrow_constructible(Incomplete&&, Incomplete)
:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114377
Patrick Palka changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303
--- Comment #13 from Jakub Jelinek ---
Created attachment 57821
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57821&action=edit
gcc14-pr112303.patch
This patch fixes the ICE for me.
Seems we already did something like that in other spots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #49 from Sarah Julia Kriesch ---
(In reply to Sam James from comment #44)
> I'm really curious as to if there's other test cases which could be shared,
> as Andreas mentioned distributions were complaining about this even. That's
> u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111426
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114492
--- Comment #3 from Hans-Peter Nilsson ---
(In reply to Andrew Pinski from comment #1)
> >Please be advised that the argument is *not* evaluated with release checking
>
> Actually it is evaluated with release checking as release checking enable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067
--- Comment #7 from Jonathan Wakely ---
(In reply to Jason Merrill from comment #3)
> Hmm? but the standard says that a precondition for std::is_constructible is
> the type being complete, and we enforce that with a static_assert (since
> PR71579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114498
--- Comment #2 from Jonathan Wakely ---
(In reply to Richard Biener from comment #1)
> I'd say deprecating them for a release aka hiding behind a
> -D_YES_I_WANT_TR1_HEADERS and otherwise issueing #error and then axing them
> should be OK.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:86b80b049167d28a9ef43aebdfbb80ae5deb0888
commit r13-8501-g86b80b049167d28a9ef43aebdfbb80ae5deb0888
Author: Richard Sand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114496
--- Comment #3 from Eric Gallager ---
Maybe the update could be just to clarify the "EnabledBy" rules for the
warning? i.e., something like "-Wsign-conversion is only and will only ever be
enabled by -Wconversion in C, and we will never have it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824
--- Comment #13 from Eric Gallager ---
(In reply to Iain Sandoe from comment #12)
> what input is this waiting for at the moment?
>From checking the bug history, it looks like Martin Liška was the one to put
this in the WAITING status, which ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111426
--- Comment #3 from Marek Polacek ---
I meant that g++5 emitted
111426.C:7:3: error: use of deleted function ‘D::D()’
D d;
^
111426.C:6:7: note: ‘D::D()’ is implicitly deleted because the default
definition would be ill-formed:
class D : p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114500
Bug ID: 114500
Summary: go.test/test/fixedbugs/issue23781.go FAILs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #50 from GCC Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:839bc42772ba7af66af3bd16efed4a69511312ae
commit r14-9692-g839bc42772ba7af66af3bd16efed4a69511312ae
Author: Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 Regression] ICE on |[13/14 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109925
--- Comment #4 from Jakub Jelinek ---
Doesn't reproduce on the trunk since
r14-4089-gd45ddc2c04e471d0dcee016b6edacc00b8341b16
Doesn't reproduce on 13 branch either, the PR113372 fixed it there.
So, I think we should just add the testcase to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #51 from Segher Boessenkool ---
(In reply to Richard Biener from comment #46)
> Maybe combine already knows that it just "keeps i2" rather than replacing it?
It never does that. Instead, it thinks it is making a new I2, but it ends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
Martin Jambor changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
Xi Ruoyao changed:
What|Removed |Added
Status|REOPENED|NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
--- Comment #5 from Jakub Jelinek ---
Started with r13-6145-gb2287a4d9a640fdc2caef6a067830ea65044deb7
I must say I have no idea what is different from this POV on Darwin vs. Linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696
--- Comment #7 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:51e1629bc11f0ae4b8050712b26521036ed360aa
commit r12-10296-g51e1629bc11f0ae4b8050712b26521036ed360aa
Author: Richard San
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31418
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #42 from Dmitry Kazakov ---
Hi, Avraham!
> Does it remain true that the only option to get around this bug without
> killing all AVX2 is to pass "-Wa,-muse-unaligned-vector-move" when compiling
> using GCC on Windows 64? Thank you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> But I think it would be best to fix it in the compiler, so that we always
> allow directly binding T&& or const T& to T, even if T is incomplete.
> Otherwis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112303
--- Comment #14 from Jan Hubicka ---
> This patch fixes the ICE for me.
> Seems we already did something like that in other spots (e.g. in apply_scale).
In general if the overflow happens, some pass must have misbehaved and
do something crazy w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #29 from Andrew Pinski ---
Looking back at this one, I (In reply to Wilco from comment #8)
> Here is a much simpler example:
>
> void f (int *p, int y)
> {
> int a = y & 14;
> *p = a | p[a];
> }
After r14-9692-g839bc42772ba7af66a
1 - 100 of 190 matches
Mail list logo
