https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108403
Bug ID: 108403
Summary: -Wanalyzer-null-dereference false negative with *q ==
0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402
--- Comment #1 from Andrew Pinski ---
This has nothing to do with ftrivial-auto-var-init=pattern . But rather you are
passing an uninitiated struct to a function that takes a pointer to a const
type. That causes the warning.
Can you attach the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402
Bug ID: 108402
Summary: False positive Wuninitialized with
ftrivial-auto-var-init=pattern
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #16 from Alexandre Oliva ---
Sorry it took me so long to react, I'd missed the question.
IIRC the scheduler was the hardest part of GCC to make work with debug insns.
The general strategy is that nondebug insns never depend on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331
--- Comment #7 from Jerry DeLisle ---
I biffed the PR number on this commit. It should have been here. I will have
to look into amending the ChangeLog correctly.
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536
--- Comment #5 from Ed Catmur ---
PR: https://github.com/ecatmur/gcc/pull/5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401
Bug ID: 108401
Summary: gcc defeats vector constant generation with intrinsics
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42093
--- Comment #9 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:31aaa6ef5a952d4f64fb04010459f28e0e793702
commit r13-5161-g31aaa6ef5a952d4f64fb04010459f28e0e793702
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40457
--- Comment #15 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:acddf6665f067bc98a2529a699b1d4509a7387cb
commit r13-5160-gacddf6665f067bc98a2529a699b1d4509a7387cb
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #7 from Kees Cook ---
(In reply to Kees Cook from comment #6)
> Sorry, I forgot to include those details fully! Here's how I'm seeing it:
>
> $ gcc --version
> gcc (GCC) 13.0.0 20230105 (experimental)
> ...
> $ gcc -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #6 from Kees Cook ---
Sorry, I forgot to include those details fully! Here's how I'm seeing it:
$ gcc --version
gcc (GCC) 13.0.0 20230105 (experimental)
...
$ gcc -O2 -fno-strict-overflow -fsanitize=shift -Warray-bounds -c -o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273
--- Comment #7 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:ccd4df81aa6537c3c935b026905f6e2fd839654e
commit r13-5159-gccd4df81aa6537c3c935b026905f6e2fd839654e
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67046
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108395
--- Comment #2 from Andrew Pinski ---
This is will most likely fix it, but I am not 100% sure it fixes all of the
constexpr cases though:
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index e06f052eb46..3a169eceece 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #5 from Andrew Macleod ---
The full comment is the test case is:
/* Verify offsets in an anti-range. */
<...>
/* The initial source range is valid but the final range after the access
has complete cannot be. The value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107467
--- Comment #9 from Jan Hubicka ---
>
> so it's ICFed compare_pairs having modref TBAA info that makes the
> stores dead. I suppose ICF needs to reset / alter the modref summaries?
Well, matching that ICF does should be enough to verify that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #4 from Andrew Macleod ---
Created attachment 54270
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54270=edit
possible patch
When the on-entry cache is updated for a block, all incoming ranges are unioned
together and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105546
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108274
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108274
--- Comment #4 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:4fa6845b4b29f33cc7ea3d8ff49b61bb1f460561
commit r13-5157-g4fa6845b4b29f33cc7ea3d8ff49b61bb1f460561
Author: Eric Botcazou
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108368
--- Comment #2 from Andrew Macleod ---
Not sure why it looks expensive, it is a lot cheaper than the original cache
propagation was, but still gets all the cases.
Regardless, the upcoming fix for 108356 fixes this PR as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
--- Comment #7 from Andrew Macleod ---
Created attachment 54269
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54269=edit
patch in testing
Patch is in testing.
We added relation processing to GORI during stage 1, but its very lightly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108395
Andrew Pinski changed:
What|Removed |Added
Blocks||89180
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #14 from Jerry DeLisle ---
the '-x f77' id documented here:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Overall-Options.html#Overall-Options
All it does is tell the compiler the source is fixed form or free-form.
Admittedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #8 from Jakub Jelinek ---
-fsanitize=undefined with no diagnostics doesn't mean code is UB free.
This testcase is still invalid.
Before the first g--;, g == , so g-- will set g to g - sizeof (int). That is
UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #7 from Siddhesh Poyarekar ---
Thanks, is that from the code in prima[1] or the Red Hat bugzilla report? The
latter is undefined as per the above discussion.
[1] https://github.com/dk/Prima/issues/78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #5 from Siddhesh Poyarekar ---
Ack, I had a thinko with
unsigned steps[] = {1, 1};
because in that case too n_steps doesn't get decremented, resulting in OOB
access. I'm going to look at the original report[1] to see if the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108397
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-01-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108400
Bug ID: 108400
Summary: false positive: null dereference
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108132
--- Comment #8 from CVS Commits ---
The master branch has been updated by Alexander Monakov :
https://gcc.gnu.org/g:733a1b777f16cd397b43a242d9c31761f66d3da8
commit r13-5154-g733a1b777f16cd397b43a242d9c31761f66d3da8
Author: Alexander Monakov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
--- Comment #17 from CVS Commits ---
The master branch has been updated by Alexander Monakov :
https://gcc.gnu.org/g:733a1b777f16cd397b43a242d9c31761f66d3da8
commit r13-5154-g733a1b777f16cd397b43a242d9c31761f66d3da8
Author: Alexander Monakov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #3 from Siddhesh Poyarekar ---
Oops, sorry I messed up the reproducer, here's the correct one. The principles
don't really change though:
unsigned steps[2];
int main(void) {
unsigned n_steps = sizeof (steps) / sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108399
Bug ID: 108399
Summary: wrong locations generated for OMP_FOR
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #2 from Siddhesh Poyarekar ---
Yeah, I've been ping-ponging about the validity too, which is why I filed a bug
to get some consensus position. I suppose if we don't treat it as a bug, should
we try and support it in cases we can by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Bug ID: 108398
Summary: tree-object-size trips up with pointer arithmetic if
an intermediate result is an invalid pointer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #20 from Jonathan Wakely ---
Strange, maybe something different about my newlib build. Anyway, what matters
is that you can build it. I only need to be able to verify my changes compile!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108285
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108285
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3456db4de8940235b303ca38a689353854c9239f
commit r13-5152-g3456db4de8940235b303ca38a689353854c9239f
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #13 from Jerry DeLisle ---
Created attachment 54267
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54267=edit
FM509 that I have here.
This morning I also recall there was one NIST test that had an error. I
contacted them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #19 from Jan Dubiec ---
(In reply to Jonathan Wakely from comment #17)
> (but I still get the assembler errors for h8300-elf using
> latest binutils).
This is strange. I have just successfully built binutils edf64cd2 and then gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
--- Comment #8 from Vincent Lefèvre ---
Isn't it the same as PR56020, which is due to the fact that the STDC
FENV_ACCESS pragma is not implemented and assumed to be OFF (PR34678)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108397
Bug ID: 108397
Summary: Missed optimization with [0, 0][-1U,-1U] range
arithmetics
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107131
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 Regression] wrong |[11/12 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107131
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:254cf9552ffb1693f0bc74f6d25601dafafbc144
commit r13-5150-g254cf9552ffb1693f0bc74f6d25601dafafbc144
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107131
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
Bug ID: 108396
Summary: PPCLE: vec_vsubcuq missing
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393
--- Comment #2 from Jonathan Wakely ---
Specifically, ADL for __t == __u finds this function:
template
friend constexpr bool operator==(unreachable_sentinel_t, const _Iter&)
noexcept;
making it an overload resolution candidate. It's not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393
--- Comment #1 from Jonathan Wakely ---
The concept C checks whether S satisfies the constraint
for the iterator_traits specialization. That performs ADL for operator== with
S and unreachable_sentinel_t as associated classes.
That finds the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #13 from jinci kang ---
(In reply to Jonathan Wakely from comment #12)
> (In reply to jinci kang from comment #8)
> > Clang has a problem with ABI breaking.
> > https://reviews.llvm.org/D8467
>
> Ah yes. The most recent attempt to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #12 from Steve Kargl ---
On Fri, Jan 13, 2023 at 11:49:44AM +, ben.brewer at codethink dot co.uk
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
>
> --- Comment #11 from Ben Brewer ---
> So I was using "-x f77"
-but-set-variable.
Using version `13.0.0 20230113 (experimental)'.
# echo 'int f() { constexpr int v = 0; return v; }' | gcc -c -xc -std=c2x -Wall
-Wextra -
: In function 'f':
:1:25: warning: variable 'v' set but not used
[-Wunused-but-set-variable]
As a workaround any operation on v (cast
/aarch64/cpunative/native_cpu_18.c scan-assembler \\.arch
armv8.6-a\\+crc\\+fp16\\+aes\\+sha3\\+rng
=== gcc Summary ===
# of expected passes1
# of unexpected failures1
/home/polacek/x/trunk/gcc/xgcc version 12.2.1 20230113 (GCC)
# GCC_CPUINFO=info_18 gcc -mcpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #12 from Jonathan Wakely ---
(In reply to jinci kang from comment #8)
> Clang has a problem with ABI breaking.
> https://reviews.llvm.org/D8467
Ah yes. The most recent attempt to fix it is at:
https://reviews.llvm.org/D112921
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108392
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107131
--- Comment #7 from Jakub Jelinek ---
If I change the testcase to:
/* PR target/107131 */
/* { dg-do run } */
/* { dg-options "-Os -fno-ipa-vrp -fno-tree-bit-ccp -Wno-psabi" } */
typedef unsigned char C;
typedef unsigned long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393
Bug ID: 108393
Summary: circular concept false-positive
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #11 from jinci kang ---
OK
redi at gcc dot gnu.org 于2023年1月13日周五 21:53写道：
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
>
> --- Comment #10 from Jonathan Wakely ---
> I've already closed it
>
> --
> You are receiving
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #10 from Jonathan Wakely ---
I've already closed it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #9 from jinci kang ---
This issue can be closed, but I don't know how to close this, can you help me
to close it.Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86419
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #8 from jinci kang ---
(In reply to Jakub Jelinek from comment #7)
> Grep shows that clang predefines that macro if -fsized-deallocation is used.
> But why that option doesn't default to on for C++14 is hard to understand.
Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108331
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86419
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:02dab998665dda0f6df31740e8897c42de3d740f
commit r13-5144-g02dab998665dda0f6df31740e8897c42de3d740f
Author: Dimitrij Mijoski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108331
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:e2fc12a5dafadf15d804e1d2541528296e97a847
commit r13-5143-ge2fc12a5dafadf15d804e1d2541528296e97a847
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #7 from Jakub Jelinek ---
Grep shows that clang predefines that macro if -fsized-deallocation is used.
But why that option doesn't default to on for C++14 is hard to understand.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
Aldy Hernandez changed:
What|Removed |Added
Attachment #54253|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108392
Bug ID: 108392
Summary: Unexpected optimization in presence of
'__attribute__((noipa))'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383
--- Comment #4 from eebssk1 at godaftwithebk dot pub ---
The problem occurs at final linking.
x86_64-w64-mingw32-g++ -o src/dxgi/dxgi.dll src/dxgi/dxgi.dll.p/version.o
src/dxgi/dxgi.dll.p/dxgi_adapter.cpp.obj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #29 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #27)
> "elide an overflow" should be probably "elide an overflow or division by
> zero" I think,
> because finite / 0.0 returns infinity and raises FE_DIVBYZERO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #5 from jinci kang ---
(In reply to Jakub Jelinek from comment #4)
> No, but:
> #include
>
> int main() {
> void* p = ::operator new[](2);
> #if __cpp_sized_deallocation >= 201309
> ::operator delete[](p, 2);
> #else
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108377
--- Comment #4 from Thomas Schwinge ---
Thanks, Andrew, for looking into this.
(In reply to Andrew Pinski from comment #2)
> If calc_n(259) returns (__SIZE_TYPE__)-1 (aka 18446744073709551615) [...]
> the warning is correct ([...]) in some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383
--- Comment #3 from eebssk1 at godaftwithebk dot pub ---
Exactly same problem with -Os on lto.(Seems reflect the problem in that github
issue)
The project seems only supports mingw target.
I'll get back when have more information.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #3 from jinci kang ---
(In reply to Jonathan Wakely from comment #2)
> Oh clang isn't using it, you're using it explicitly. So then that's a bug in
> your code. You shouldn't use it unless the macro is defined to say that it's
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108344
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ---
To gather more information, I've tried a -g3 -O0 build. The failures
still occur, but the failure mode is slightly different: all the 64-bit
tests in gm2/iso/pass now SEGV in cc1gm2:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #2 from Jonathan Wakely ---
Oh clang isn't using it, you're using it explicitly. So then that's a bug in
your code. You shouldn't use it unless the macro is defined to say that it's
usable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
--- Comment #11 from Mark Rutland ---
Further, at `-O1` and above GCC seems to silently drop the alignment of any
implementation of abort(), apparently implicitly marking it as cold.
I assume that may be true for other special functions.
For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108391
--- Comment #1 from Jonathan Wakely ---
(In reply to jinci kang from comment #0)
> * The reason is that clang does not define the macro
> __cpp_sized_deallocation.
Well then that's a clang bug. It shouldn't be trying to use sized delete if it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108274
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108197
--- Comment #3 from Richard Biener ---
(In reply to Stephen from comment #2)
> Richard, are you saying this a bug in the boost code? It's not quite clear
> to me from your message. Can you be more specific about what the bug is in
> that case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107558
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 107129, which changed state.
Bug 107129 Summary: [13 Regression] False positive -Wstringop-overflow warning
with -O2 or -O3 since r13-137-gee1cb43bc76de800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107129
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #4 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107516
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
1 - 100 of 144 matches
Mail list logo
