https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114494
--- Comment #1 from Andrew Pinski ---
Please note this part of the documentation:
Note that sanitizers tend to increase the rate of false positive warnings, most
notably those around -Wmaybe-uninitialized. We recommend against combining
-Werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114494
--- Comment #3 from Akihiko Odaki ---
(In reply to Andrew Pinski from comment #2)
> Note the minimized testcase seems to be a real issue. hlen can either be 1
> (the only value that works) or more than 1.
Below is the the error message for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114494
Bug ID: 114494
Summary: false-positive with -O2 -Wstringop-overflow=2
-fsanitize=address
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95782
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114495
Bug ID: 114495
Summary: Capture error in lambda fold
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114494
--- Comment #2 from Andrew Pinski ---
Note the minimized testcase seems to be a real issue. hlen can either be 1 (the
only value that works) or more than 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114501
--- Comment #3 from Andrew Pinski ---
Created attachment 57825
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57825=edit
Reduced most of the way (C++14 code now)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114501
Andrew Pinski changed:
What|Removed |Added
Attachment #57825|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
--- Comment #11 from Sam James ---
I'm going to upload the originals in case it offers more insight because the
return type isn't mismatched there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114507
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114507
--- Comment #2 from Sam James ---
That said, I feel as if it's more likely this is better for the analyser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114506
--- Comment #3 from demin.han at starfivetech dot com ---
Hi,
I'm trying to fix this.
The reason is unnecessary live_range added in cost model
> -Original Message-
> From: pinskia at gcc dot gnu.org
> Sent: 2024年3月28日 13:34
> To:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114507
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12411
Andrew Pinski changed:
What|Removed |Added
CC||vt at altlinux dot org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114507
--- Comment #4 from Andrew Pinski ---
Well the diagnostic part was PR 12411 :) (which I filed years ago and decided
to close as won't fix less than 3 years ago).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114508
Bug ID: 114508
Summary: Missed optimization of Dead Code Elimination
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250
--- Comment #15 from Sam James ---
(The workaround flags could be reduced but at this point I just wanted a quick
workaround.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52441
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58166
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65214
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114501
--- Comment #6 from Andrew Pinski ---
Changing he return type of size to be size_t rather than size_type fixes the
issue.
So does adding:
constexpr basic_string_view view;
to the toplevel namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37778
Andrew Pinski changed:
What|Removed |Added
Severity|trivial |normal
Component|preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54446
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114507
Bug ID: 114507
Summary: FR: Randomize order of evluation of function of
arguments
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114506
--- Comment #1 from Andrew Pinski ---
/app/example.cpp:7:27: note: Comparing two main loops (RVVM1QI at VF 32 vs
RVVM8SF at VF 64)
/app/example.cpp:7:27: note: Preferring smaller LMUL loop because it has
unexpected spills
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114501
Andrew Pinski changed:
What|Removed |Added
Known to work||8.5.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250
Sam James changed:
What|Removed |Added
Summary|[12/13/14 regression] |[12/13 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114506
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
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
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=114490
Kang-Che Sung changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
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:
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,
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=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=114480
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to fail|
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114497
Centurion changed:
What|Removed |Added
CC||centurionn009 at gmail dot com
--- Comment
*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,
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
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=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
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=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
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #18 from Richard
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=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=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
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
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=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=110311
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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=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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114506
Bug ID: 114506
Summary: RISC-V: expect M8 but M4 generated with dynamic LMUL
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114487
--- Comment #12 from Sam James ---
Ah, wait, no point with andrew's nicer testcase ;)
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=114485
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
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=114496
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-27
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=112787
Eric Botcazou changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
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
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
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://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=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
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=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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
Jakub Kulik changed:
What|Removed |Added
CC||jakub.kulik at oracle dot com
---
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
---
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:
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
---
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
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
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),
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 #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=114493
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
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
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
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; }
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=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=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
1 - 100 of 187 matches
Mail list logo
