https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261
--- Comment #11 from Paul Thomas ---
(In reply to Paul Thomas from comment #10)
> I guess that I should take it :-)
>
> Paul
I have reverted locally and will do a regression test before pushing, just in
case there are subsequent dependencies.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
--- Comment #4 from Bernd Edlinger ---
The DW_AT_ranges indicates that the subroutine is split over
more than one area, in most cases both subroutines do have
multiple subranges, but apparently due to slightly different
optimization levels only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:f6b10fe45b9b704fd6a7124ab02c6e6cbd8efce4
commit r15-3098-gf6b10fe45b9b704fd6a7124ab02c6e6cbd8efce4
Author: Andrew Pinski
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
Andrew Pinski changed:
What|Removed |Added
Assignee|linkw at gcc dot gnu.org |pinskia at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
--- Comment #3 from Kewen Lin ---
(In reply to Andrew Pinski from comment #2)
> The easiest fix is todo:
> ```
> for (int i = 0; i < N; ++i)
> {
> a[i] = BASE1 + i * 5;
> b[i] = BASE2 - i * 4;
> /* b[i] cannot be 0 as tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
Kewen Lin changed:
What|Removed |Added
Target Milestone|--- |15.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116468
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
--- Comment #2 from Andrew Pinski ---
The easiest fix is todo:
```
for (int i = 0; i < N; ++i)
{
a[i] = BASE1 + i * 5;
b[i] = BASE2 - i * 4;
/* b[i] cannot be 0 as that is undefined for `% b[i]`. */
b[i] = b[i] ? b[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96290
--- Comment #2 from Andrew Pinski ---
(In reply to Gabriel Ravier from comment #1)
> I've encountered a similarly nonsensical error on trunk, though not with
> VLAs, instead with a char array of size 0:
It is not nonsensical at all. It just has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116468
Jerry DeLisle changed:
What|Removed |Added
Last reconfirmed||2024-08-23
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116468
Bug ID: 116468
Summary: Segmentation fault at intrinsic assignment to
allocatable array component of derived type with kind
type parameter
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116467
Bug ID: 116467
Summary: missed optimization: zero-extension duplicated on
xtensa
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #185 from Kazumoto Kojima ---
Unfortunately, nothing new showed up in running gcc/g++ testsuite for
sh-elf+sim with -mlra.
OTOH, the segfault can be reproduced on qemu with the patched stage2 compiler
built with -g -O2 -mlra -m4. gd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113454
--- Comment #5 from edison ---
Thanks for your reply, could you provide the patch for gcc 14.1?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111933
rsaxvc at gmail dot com changed:
What|Removed |Added
CC||rsaxvc at gmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116465
--- Comment #2 from Gabriel Ravier ---
Looked into it a bit more and the root cause seems to be that
gcc/tree-eh.cc:lower_eh_constructs_2, when attempting to handle the case where
the user partakes in a little tomfoolery with its builtins (i.e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116465
--- Comment #1 from Gabriel Ravier ---
(PS: I have no idea what this is caused by, somehow an assignment statement
with no left hand side appears to be generated ?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116466
Bug ID: 116466
Summary: The standard instruction pattern of RISC-V addv has
generated an unnecessary instruction.
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116465
Bug ID: 116465
Summary: __builtin_eh_pointer ICEs when passed seemingly any
argument
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96290
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #5 from Tamar Christina ---
Yeah, This is because they generate different gimple sequences and thus
different SLP trees.
The core of the problem is there's no canonical form here, and a missing gimple
simplification rule:
_33 = IM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101139
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 57993 [details]
> Patch but it does not work for the code in this testcase
>
> I have to look into why it is not working for the testcase in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #9 from Alexander Monakov ---
Okay, if you take the addition and the branch from the inlined variant:
addl %eax, %edx
je .L3
and add a 'test' instruction:
addl %eax, %edx
test %edx, %edx
je .L3
then Valgrind doesn't complain. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116464
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:da043f9c7172bcbfda0cdb570fb3a979a4b1a525
commit r15-3096-gda043f9c7172bcbfda0cdb570fb3a979a4b1a525
Author: Andrew Pinski
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116464
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116464
Andrew Pinski changed:
What|Removed |Added
Keywords||testsuite-fail
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116464
Bug ID: 116464
Summary: [15 regression] new test gcc.dg/torture/pr116420.c
from r15-3095-gc9377734b798d8 fails
Product: gcc
Version: 15.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105474
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
--- Comment #7 from Alisdair Meredith ---
Late comment: according to [intro.multithread.general] it is a requirement for
hosted implementations to support more than one thread of execution, but
implementation defined for a free-standing implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #8 from Alexander Monakov ---
Thanks for the reference, but it doesn't help. Something more subtle is going
on, because placing the shift-add combo in a separate function makes Valgrind
properly compute known bits even without the ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #19 from Andrew Pinski ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661228.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707
--- Comment #12 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #11)
> Testing removal of this part from the driver.
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661228.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
--- Comment #2 from Bernd Edlinger ---
no forget it, this might make arm unhappy...
lets try this instead:
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
@@ -1,9 +1,9 @@
-/* Verify that both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #7 from Mark Wielaard ---
You could try --expensive-definedness-checks=yes
--expensive-definedness-checks= [default: auto]
Controls whether Memcheck should employ more precise but also more
expensive (ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
Andrew Pinski changed:
What|Removed |Added
Attachment #58978|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113746
Simon Martin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
Andrew Pinski changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
Andrew Pinski changed:
What|Removed |Added
Attachment #58977|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #6 from Alexander Monakov ---
As for Valgrind false positive, it handles this SSSE3 code really well and
misses the key point by a very narrow margin. We have
found = m1 + (m2 << 16);
where both m1 and m2 hold 16-bit masks from p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #1 from Andrew Pinski ---
Created attachment 58977
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58977&action=edit
Reduced testcase
options: `-ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-commo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
Bug ID: 116463
Summary: [15 Regression] fast-math-complex-mls-{double,float}.c
fail after r15-3087-gb07f8a301158e5
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116420
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
Bug ID: 116462
Summary: [15 regression] new test case
gcc.dg/debug/dwarf2/inline7.c from
r15-3083-gbcb33b1237042e fails
Product: gcc
Version: 15.0
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116420
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:c9377734b798d8d311dfd3a5618dc49407703b93
commit r15-3095-gc9377734b798d8d311dfd3a5618dc49407703b93
Author: Jeff Law
Date: Thu Aug 22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #4 from Andrew Pinski ---
(In reply to Alessandro Astone from comment #1)
> Cannot attach intermediate files because the size is too large.
> Sorry that I don't have a minimal reproducer :/
Is there a place where you could upload th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #18 from Jerry DeL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
Andrew Pinski changed:
What|Removed |Added
Severity|normal |blocker
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106606
Paul Thomas changed:
What|Removed |Added
CC||vehre at gmx dot de
--- Comment #5 from P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
Bug ID: 116461
Summary: New test case gcc.dg/vect/vect-mod-var.c from
r15-3082-g9bbad3685131ec fails
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106606
--- Comment #4 from Paul Thomas ---
Created attachment 58976
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58976&action=edit
Full testcase that fails in runtime
The patch regtests OK but the attached fails in runtime, as it does with ifo
Hi there,
Want to expand your outreach to K-12 schools, colleges, universities? Our email
list of principals, superintendents, and key decision-makers is ideal for you!
Our List Includes:
* Principals
* Superintendents
* Board Members
* Department Heads
List Contains:- First N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #29 from andi at firstfloor dot org ---
The semantics of -foptimize-sibling-calls do not change. However if your
program depends on sbling calls for correctness it should migrate to the
new attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115921
Jovan Vukic changed:
What|Removed |Added
CC||jovan.vu...@rt-rk.com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #3 from Alessandro Astone ---
(In reply to Andrew Pinski from comment #2)
> Can you try adding -fchecking and seeing if that fails differently?
No, it fails in the same way.
BTW i realize i didn't specify this other than mentioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #2 from Andrew Pinski ---
Can you try adding -fchecking and seeing if that fails differently?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #1 from Alessandro Astone ---
Cannot attach intermediate files because the size is too large.
Sorry that I don't have a minimal reproducer :/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
Bug ID: 116460
Summary: ppc64le: LTO ICE during GIMPLE pass: forwprop
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116329
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052
ezannoni changed:
What|Removed |Added
CC||ezannoni at gmail dot com
--- Comment #10 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116439
Patrick Palka changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116420
--- Comment #3 from Jeffrey A. Law ---
Fun.
The DF framework provides us a way to run dataflow problems on sub-graphs.
Naturally a bitmap of interesting blocks is passed into those routines. At a
confluence point, the DF framework will not m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116348
--- Comment #10 from Xi Ruoyao ---
I've tested the change and it fixes PR116314 case as well.
Richard: do you want me to send your change as a patch like before (the
PR116142 fix)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116420
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
--- Comment #8 from Jonathan Wakely ---
(In reply to xiaohuba2021 from comment #0)
> struct Matrix {
> long long mat[2][2];
> Matrix() { memset(mat, 0, sizeof(mat)); }
N.B. there's no miscompilation if you change this to the more idioma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
--- Comment #7 from xiaohuba2021 ---
Created attachment 58975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58975&action=edit
The miscompiled program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
--- Comment #6 from Jonathan Wakely ---
Regression started with with r12-2523 and was fixed by r13-7206, which was
backported as r12-9476.
So this is a dup of either PR ipa/107769 or PR ipa/109318.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
--- Comment #4 from xiaohuba2021 ---
Yes, it seems that only 12.1 and 12.2 are affected. But I wonder what's the
cause of it, and are there any patches for it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116424
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
Richard Biener changed:
What|Removed |Added
Known to fail||12.1.0, 12.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
--- Comment #2 from xiaohuba2021 ---
> Uncomment line 20 (mask = 1) or explicitly add operator= for struct Matrix
> solves this problem.
sorry, the code above produces the correct answer, since line 20 is
uncommented. Comment it and it will ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
xiaohuba2021 changed:
What|Removed |Added
CC||xiaohuba2021 at 163 dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
Bug ID: 116459
Summary: gcc 12.0 optimized out functions which has observable
side affect
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 101390, which changed state.
Bug 101390 Summary: Expand vector mod as vector div + multiply-subtract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101390
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101390
Jennifer Schmitz changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116365
Jennifer Schmitz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361
--- Comment #6 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:a98dd536b1017c2b814a3465206c6c01b2890998
commit r15-3088-ga98dd536b1017c2b814a3465206c6c01b2890998
Author: H.J. Lu
Date: Wed Aug 21 07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116454
Richard Biener changed:
What|Removed |Added
Known to work||15.0
Summary|[12/13/14/15 R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116454
--- Comment #10 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:b07f8a301158e53717b8688cc8ea430b6f02574c
commit r15-3087-gb07f8a301158e53717b8688cc8ea430b6f02574c
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116358
--- Comment #5 from Manolis Tsamis ---
I had some trouble figuring the preferred way to address this. I made a choice
by answering these questions:
1) Should the aarch64 min/max expand pattern be improved?
This comment hints that we should get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261
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=116261
--- Comment #9 from Paul Thomas ---
(In reply to Sam James from comment #7)
> The unreliable nature of the failure keeps confusing people. Any chance of a
> revert until it can be fixed properly?
It is such an unreliable failure that I haven't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116365
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jennifer Schmitz :
https://gcc.gnu.org/g:313aa733e22b654ff822b867018b13ceb624c13a
commit r15-3085-g313aa733e22b654ff822b867018b13ceb624c13a
Author: Jennifer Schmitz
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87440
--- Comment #7 from GCC Commits ---
The master branch has been updated by Bernd Edlinger :
https://gcc.gnu.org/g:bcb33b1237042e9540a905d9de19219f876e26c0
commit r15-3083-gbcb33b1237042e9540a905d9de19219f876e26c0
Author: Bernd Edlinger
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37801
--- Comment #15 from GCC Commits ---
The master branch has been updated by Bernd Edlinger :
https://gcc.gnu.org/g:bcb33b1237042e9540a905d9de19219f876e26c0
commit r15-3083-gbcb33b1237042e9540a905d9de19219f876e26c0
Author: Bernd Edlinger
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261
--- Comment #8 from Xi Ruoyao ---
Raising to P1 because now automatic regression tracker has started to "bisect"
on this and blame random people.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261
Xi Ruoyao changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261
--- Comment #7 from Sam James ---
The unreliable nature of the failure keeps confusing people. Any chance of a
revert until it can be fixed properly?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115716
Simon Martin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |simartin at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116449
--- Comment #4 from Andrew Pinski ---
(In reply to Franz Sirl from comment #3)
> Isn't the missing bounds check on parr[c] on purpose? It's added with
> -fsanitize=bounds-strict.
You might be right, I misread the original qnd gimple dump. But I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116455
--- Comment #7 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #1)
> I think the standard does not define it as constexpr which is why it is not
> constexpr in libstdc++.
Right, the standard does not allow implementations to ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116449
--- Comment #3 from Franz Sirl ---
Isn't the missing bounds check on parr[c] on purpose? It's added with
-fsanitize=bounds-strict.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Host|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #4 from David Binderman ---
(In reply to Alexander Monakov from comment #3)
> David, thanks for Cc'ing me and for running Valgrind builds!
You are welcome. Its a normal weekly part of gcc testing for me.
> "Wobbly values" aside, ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #3 from Alexander Monakov ---
David, thanks for Cc'ing me and for running Valgrind builds!
Richi, I'll check in more detail later today, I think we should unbreak
Valgrind builds ASAP by initializing padding under #ifdef
ENABLE_VALG
1 - 100 of 109 matches
Mail list logo
