https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335
--- Comment #2 from Federico Kircheis ---
> Well s::~s could touch the reference std::unique_ptr (ps1).
In both cases, s::~s is called only once.
Also during the move-assignment no user-provided-code is involved (except the
destruction of ps1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335
--- Comment #3 from Federico Kircheis ---
Or maybe I've misunderstood your comment.
Do you have a specific scenario in mind where the two snippets would exhibit
different behaviors?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335
--- Comment #4 from Andrew Pinski ---
(In reply to Federico Kircheis from comment #2)
> > Well s::~s could touch the reference std::unique_ptr (ps1).
>
> In both cases, s::~s is called only once.
>
> Also during the move-assignment no user-pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112331
--- Comment #2 from JuzheZhong ---
Reduced case:
#include
#define LEN 32000
#define ntimes 20
#define TYPE int
#define lll LEN
#define LEN2 256
#define ALIGNMENT 16
__attribute__ ((aligned(ALIGNMENT))) TYPE X[lll],Y[lll],Z[lll],U[lll],V[l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
--- Comment #11 from Xi Ruoyao ---
I cherry-picked f87cf663af71e5d78c8d647fa48562102f3b0615 for Binutils 2.41 and
get some better error message:
t.s:98064: Error: Reloc overflow
t.s:101127: Error: Reloc overflow
t.s:101453: Error: Reloc overflo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
--- Comment #12 from chenglulu ---
(In reply to Xi Ruoyao from comment #11)
> I cherry-picked f87cf663af71e5d78c8d647fa48562102f3b0615 for Binutils 2.41
> and get some better error message:
>
> t.s:98064: Error: Reloc overflow
> t.s:101127: Err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335
--- Comment #5 from Federico Kircheis ---
Ok, the described case would be something like
std::unique_ptr t;
__thread bool tt;
inline s::~s()
{
if (tt)
return;
tt = true;
t.reset(new s);
tt = false;
}
std::unique_ptr t2;
bar(t,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
--- Comment #13 from Xi Ruoyao ---
(In reply to chenglulu from comment #12)
> (In reply to Xi Ruoyao from comment #11)
> > I cherry-picked f87cf663af71e5d78c8d647fa48562102f3b0615 for Binutils 2.41
> > and get some better error message:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112313
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112316
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112319
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112320
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112345
Bug ID: 112345
Summary: ice in mark_block_for_update
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112345
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112345
--- Comment #2 from Andrew Pinski ---
We have now:
# DEBUG p => D#1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112345
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112320
--- Comment #11 from Andrew Pinski ---
*** Bug 112345 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112328
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112320
--- Comment #12 from Andrew Pinski ---
*** Bug 112328 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112328
--- Comment #5 from Andrew Pinski ---
Before the patch:
# DEBUG s => s_42
After:
# DEBUG s => D#1
And no reference to D#1 ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
--- Comment #14 from chenglulu ---
(In reply to Xi Ruoyao from comment #13)
> (In reply to chenglulu from comment #12)
> > (In reply to Xi Ruoyao from comment #11)
> > > I cherry-picked f87cf663af71e5d78c8d647fa48562102f3b0615 for Binutils 2.41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314
--- Comment #2 from Jose Dapena Paz ---
(In reply to Jonathan Wakely from comment #1)
> For the second one, I did start work on a patch that attempts to verify that
> the provided length is not more than __builtin_object_size. I can't remember
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112346
Bug ID: 112346
Summary: Wrong code produced with -O2
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112346
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111519
Andrew Pinski changed:
What|Removed |Added
CC||fchelnokov at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112346
Shaohua Li changed:
What|Removed |Added
CC||shaohua.li at inf dot ethz.ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112346
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112346
--- Comment #4 from Fedor Chelnokov ---
According to referenced stackoverflow discussion, the code is reduced from
https://github.com/vermaseren/form see
https://github.com/vermaseren/form/issues/461
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #30 from Robin Dapp ---
On my machine it is not nearly as bad as insn-emit.cc. What dominates for me
with a GCC 13 host compiler is the already fixed insn-opinit problem.
How long does it take for you (maybe in % of the total build)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
Noam Lewis changed:
What|Removed |Added
CC||noamlewis at google dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112339
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
el: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231102 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112325
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
Sergei Trofimovich changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #2 from Sergei Trofimovich ---
A bit of debugging:
Program received signal SIGSEGV, Segmentation fault.
0x007bfff6 in convert_for_assignment (location=location@entry=263654,
expr_loc=expr_loc@entry=0, type=type@entry=0x7fffe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112331
Richard Biener changed:
What|Removed |Added
Summary|middle-end: Fail|Fail vectorization after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112340
Richard Biener changed:
What|Removed |Added
Keywords||testsuite-fail
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112344
Richard Biener changed:
What|Removed |Added
Status|NEW |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112331
--- Comment #4 from JuzheZhong ---
I see.
It does vectorize it with -fno-vect-cost-model -fno-loop-interchange:
https://gcc.godbolt.org/z/8EEWcPro3
Codegen same as LLVM.
I am gonna revisit it in GCC-15 (GCC-14 stage 1 is closing soon).
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112348
Bug ID: 112348
Summary: [C++23] defect in struct
hash>
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #3 from Martin Uecker ---
Thanks for reporting. I will fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112320
--- Comment #13 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:c05f748218a0d556972212d6aecfce0eb4c8a31c
commit r14-5075-gc05f748218a0d556972212d6aecfce0eb4c8a31c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112320
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112331
--- Comment #5 from Richard Biener ---
I'm not sure what the problem is with a zero DR step for an inner loop
reference
(possibly dependence analysis runs into some unhandled cases - who knows). The
following vectorizes the inner loop (the loa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
--- Comment #8 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:01c18f58d37865d5f3bbe93e666183b54ec608c7
commit r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec608c7
Author: Robin Dapp
Date: Wed Sep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330
Xi Ruoyao changed:
What|Removed |Added
Keywords|build |
Summary|[14 Regression] LoongAr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #4 from Martin Uecker ---
Created attachment 56489
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56489&action=edit
patch
This should fix it. I am running some tests and will commit this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
Martin Uecker changed:
What|Removed |Added
Attachment #56489|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
Martin Uecker changed:
What|Removed |Added
Attachment #56490|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69549
--- Comment #12 from jwjagersma at gmail dot com ---
(In reply to Xi Ruoyao from comment #11)
> Generally a patch should be sent to gcc-patc...@gcc.gnu.org. See
> https://gcc.gnu.org/contribute.html. The patches attached to a Bugzilla
> ticket a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112317
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:c71028c979d55f98b7727f9387bbe2f4ffe6de13
commit r14-5080-gc71028c979d55f98b7727f9387bbe2f4ffe6de13
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112317
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112329
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Summar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334
--- Comment #1 from Richard Earnshaw ---
This might be a side issue, but:
@defbuiltin{{void} __builtin_return (void *@var{result})}
This built-in function returns the value described by @var{result} from
the containing function. You should spe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102383
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100457
Bug 100457 depends on bug 102383, which changed state.
Bug 102383 Summary: Missing optimization for PRE after enable O2 vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102383
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349
Bug ID: 112349
Summary: ranges::max makes unecessary copies
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #8 from Sergei Trofimovich ---
(In reply to Martin Uecker from comment #6)
> Created attachment 56491 [details]
> patch
>
> Ok, let's try again...
The change fixes jemalloc and boehm-gc builds for me. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #9 from CVS Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:f432a594fe6d3a0de1330ba69200d158e6248083
commit r14-5084-gf432a594fe6d3a0de1330ba69200d158e6248083
Author: Martin Uecker
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
--- Comment #13 from Jan Hubicka ---
So I re-tested it with current mainline and clang 16/17
For mainline I get (megapixels per second, bigger is better):
13.39
13.38
13.42
clang 16:
20.06
20.06
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:6afa984f47e16e8bd958646d7407b74e61041f5d
commit r14-5085-g6afa984f47e16e8bd958646d7407b74e61041f5d
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
--- Comment #2 from Stam Markianos-Wright ---
Created attachment 56492
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56492&action=edit
creduced reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112351
Bug ID: 112351
Summary: libstdc++ locale init doesn't handle __gthread_once
failure
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
--- Comment #3 from Stam Markianos-Wright ---
Created attachment 56493
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56493&action=edit
Full preprocessor reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112351
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #9 from Vineet Gupta ---
(In reply to Patrick O'Neill from comment #8)
> Updated regression list using r14-5070-g4ea36076d66 on rv64gcv:
>
> Failure list from:
> https://github.com/patrick-rivos/gcc-postcommit-ci/issues/109
And jus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314
--- Comment #5 from Jose Dapena Paz ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Jose Dapena Paz from comment #2)
> > In any case, the failing test is actually passing -1, my understanding is
> > that that one should always a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112316
Paul Thomas changed:
What|Removed |Added
Last reconfirmed||2023-11-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314
--- Comment #6 from Jonathan Wakely ---
Created attachment 56494
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56494&action=edit
Check [ptr,end) and [ptr,ptr+n) ranges with _GLIBCXX_ASSERTIONS
With this change we could add:
__glibcxx_re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112350
--- Comment #1 from Andrew Pinski ---
With optimization enabled and without -fsanitize=address we get:
: In function 'const int& foo1()':
:12:18: warning: using a dangling pointer to 'x' [-Wdangling-pointer=]
12 | return s.get();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112354
Bug ID: 112354
Summary: mismatched types 'B' and 'B&' for generic
lambda noexcept-specifier referencing enclosing
function parameter
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112353
--- Comment #1 from Andrew Pinski ---
https://github.com/google/sanitizers/issues/1470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #8 from Patrick O'Neill ---
Updated regression list using r14-5070-g4ea36076d66 on rv64gcv:
=== gcc: Unexpected fails for rv64gcv lp64d medlow ===
FAIL: gcc.c-torture/execute/memset-3.c -O3 -fomit-frame-pointer
-funroll-lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110116
Thomas Koenig changed:
What|Removed |Added
Summary|[12/13/14 Regression] ICE |[12/13 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112354
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112353
Bug ID: 112353
Summary: asan-enabled, aarch64-gcc cross-compiled elf
executables fail ro run in qemu-user on x86
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314
--- Comment #7 from Jonathan Wakely ---
(In reply to Jose Dapena Paz from comment #5)
> - The length is less than the possible pointer difference (checked with
> numeric_limits).
That seems too lenient to me, because for wchar_t, char16_t and c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112096
--- Comment #4 from Andrew Pinski ---
Another testcase:
```
int f(int a, int b, int d)
{
bool t = a == 0;
bool t1 = d == 0;
int c = a + b;
if (t & t1) return b;
return c;
}
int f1(int a, int b, int d)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
--- Comment #4 from Stam Markianos-Wright ---
Bisected to f55cdce3f8dd8503e080e35be59c5f5390f6d95e
Attached preprocessed source and a creduced-reproducer of it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #10 from Robin Dapp ---
As a general remark: Some of those are present on other backends as well, some
have been introduced by recent common-code changes and some are bogus test
prerequisites or checks. I'm not saying we are in per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #10 from David Binderman ---
When this patch was tested, did that include a build of libgfortran ?
I am getting some strange new warnings:
../../../trunk.year/libgfortran/io/async.c:265:24: warning: allocation of
insufficient size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102138
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #11 from Martin Uecker ---
In this case this is by design because the size of an element should be second
argument to calloc. ("The calloc function allocates space for an array of nmemb
objects, each of whose size is size.")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102138
--- Comment #4 from Andrew Pinski ---
This is the generic solution to what was done to fix PR 104639.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112355
Bug ID: 112355
Summary: Internal compiler error when exporting using
declaration of function template
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112355
David Stone changed:
What|Removed |Added
CC||davidfromonline at gmail dot
com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112355
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106849
Andrew Pinski changed:
What|Removed |Added
CC||davidfromonline at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 112355, which changed state.
Bug 112355 Summary: Internal compiler error when exporting using declaration of
function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112355
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112355
--- Comment #3 from Andrew Pinski ---
(In reply to David Stone from comment #1)
> Looks like this is a new bug in trunk. Works in 13.2
It is not, just extra checking is enabled by default when compiling the trunk
(unless you use the configure o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106849
--- Comment #2 from David Stone ---
Looks like it works in 13.2 but fails in trunk.
13.2: https://godbolt.org/z/d54ToW7zW
trunk: https://godbolt.org/z/eej9d7ccM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106849
--- Comment #3 from David Stone ---
Oh, as per https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112355#c3 it's just
that the 13.2 build isn't checked, so it's not a new bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314
--- Comment #4 from Jonathan Wakely ---
(In reply to Jose Dapena Paz from comment #2)
> In any case, the failing test is actually passing -1, my understanding is
> that that one should always assert no matter what we are passing as const
> char*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112350
Bug ID: 112350
Summary: gcc is not triggering a dangling reference indicating
stack use after return
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity:
1 - 100 of 130 matches
Mail list logo
