https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104221
Nathaniel Shead changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115008
Nathaniel Shead changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99931
Nathaniel Shead changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118010
--- Comment #3 from Gaius Mulley ---
Ah on reflection I suspect a better fix would be to introduce a COFF_T type
from SYSTEM and allow the user to override its size with a command line option
(and in the future an attribute).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118122
--- Comment #1 from Zdenek Sojka ---
$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20241218221935-r15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118122
Bug ID: 118122
Summary: [15 Regression] ICE: in extract_insn, at recog.cc:2869
(unrecognizable insn) (ior:DI (reg:SI) (reg:DI)) with
-O -fno-tree-ter -fno-forward-propagate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118109
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118046
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118025
--- Comment #5 from Alexandre Oliva ---
The original reported problem is fixed. I'm keeping the PR open to look into
the AVR and PRU fails mentioned in comment 2, though they seem to be an
entirely different problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117915
Alexandre Oliva changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #18 from Alexandre Oliva ---
Created attachment 59915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59915&action=edit
add options to control the new ifcombine features
This may be useful to figure out whether it's ifcombine t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12056
--- Comment #7 from Andrew Pinski ---
(In reply to H.J. Lu from comment #5)
> FWIW, it isn't a problem with GNU linker when all files are compiled
> with the same version of gcc since linker can merge identical strings
> with gcc help.
Except it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118114
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117457
--- Comment #9 from Andrew Pinski ---
Created attachment 59914
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59914&action=edit
Reduced testcase
use:
```
-O2 -flto -fsanitize=address --param=lto-min-partition=1
--param=lto-partitions=2
``
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117457
--- Comment #8 from Andrew Pinski ---
That being said there is a missing optimization with respect to constprop and
cloning. Why didn't it prop the last over to clone instead of passing it via an
argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118114
--- Comment #7 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #6)
> I'm bisecting on binutils-gdb.git to see when exactly it's fixed.
commit 5c3d09c1855b948dd43b9f5f8b3d8aa254d75f43
Author: mengqinggang
Date: Thu Oct 10 16:20:52 202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118114
--- Comment #6 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #5)
> It seems fixed with ld 2.43.50.20241219.
0f18
<_ZZNSt9once_flag18_Prepare_executionC4IZSt9call_onceIRFvvEJEEvRS_OT_DpOT0_EUlvE_EERS6_ENUlvE_4_FUNEv>:
f18:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117920
Alexandre Oliva changed:
What|Removed |Added
Assignee|aoliva at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117457
Andrew Pinski changed:
What|Removed |Added
Summary|regex global buffer |regex global buffer
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118114
--- Comment #5 from Xi Ruoyao ---
It seems fixed with ld 2.43.50.20241219.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117457
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-12-19
Summary|regex glo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118114
--- Comment #4 from Xi Ruoyao ---
One workaround is enabling -flto to do the DESC => IE optimization in GCC,
instead of ld.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117457
--- Comment #5 from Andrew Pinski ---
So the generated code on the gimple level looks fine, which means maybe _M_end
is incorrect and got over-written somehow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118121
--- Comment #5 from Andrew Pinski ---
(In reply to John David Anglin from comment #4)
> Created attachment 59913 [details]
> Patch
>
> Fixes compile error.
>
> Declaration for mkstemps was more or less placed randomly in libiberty.h.
that wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118114
--- Comment #3 from Xi Ruoyao ---
Hmm... This seems like a ld bug:
a.out: file format elf64-loongarch
DYNAMIC RELOCATION RECORDS
OFFSET TYPE VALUE
7d90 R_LARCH_RELATIVE *ABS*+0x0d88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117457
--- Comment #4 from Andrew Pinski ---
So from my reading the sanitizier output, it seems like a check for `_M_current
== _M_end` is missing or is being optimized away incorrectly. I think the
latter.
0x5621f46983b4 is located 0 bytes after glob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118114
chenglulu changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
Xi Ruoyao cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118121
--- Comment #4 from John David Anglin ---
Created attachment 59913
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59913&action=edit
Patch
Fixes compile error.
Declaration for mkstemps was more or less placed randomly in libiberty.h.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118121
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Though I wonder if make_temp_file_with_prefix should be used instead of
> mkstemps directly.
No it can't since in this case we a directory while in the case of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118121
--- Comment #2 from Andrew Pinski ---
Though I wonder if make_temp_file_with_prefix should be used instead of
mkstemps directly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118121
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118121
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
--- Comment #3 from Slava Zakharin ---
Thank you for taking a look!
This code seems to comply with Fortran 2008 standard:
7.2.2 Pointer assignment
... data-pointer-object (bounds-remapping-list ) => data-target
R737 data-target is variable
C7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118010
--- Comment #2 from Gaius Mulley ---
Created attachment 59912
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59912&action=edit
Proposed fix
Many thanks for the bug report.
Here is a proposed patch, (although I've not built it with --Wtyp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118121
Bug ID: 118121
Summary: [15 Regression] lto-wrapper.cc:1878:20: error:
'mkstemps' was not declared in this scope
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117915
--- Comment #4 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:34e6c77da699de4cd172523310123af8e0a36a36
commit r15-6359-g34e6c77da699de4cd172523310123af8e0a36a36
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118025
--- Comment #4 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:f41fba5f14642bdb794e0635e37042250417678a
commit r15-6358-gf41fba5f14642bdb794e0635e37042250417678a
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118046
--- Comment #6 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:2c55a891840425a98d951283273a11cf7bd31816
commit r15-6357-g2c55a891840425a98d951283273a11cf7bd31816
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
--- Comment #2 from Andrew Pinski ---
https://fortran-lang.discourse.group/t/pointer-mapping-between-real-and-complex-arrays/8851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
Andrew Pinski changed:
What|Removed |Added
Keywords||alias, wrong-code
--- Comment #1 from A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118120
Bug ID: 118120
Summary: Wrong aliasing assumptions for Fortran POINTERs
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118115
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118119
Bug ID: 118119
Summary: [15 regression] RISC-V:
gcc.c-torture/execute/va-arg-24.c zvl256b failure
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118118
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118118
Bug ID: 118118
Summary: _Bool extension for C89 is undocumented
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101774
Jonathan Wakely changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #4 from Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118117
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
Andreas Schwab changed:
What|Removed |Added
Keywords||memory-hog
--- Comment #17 from Andrea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101774
Andrew Pinski changed:
What|Removed |Added
Known to work||15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118117
--- Comment #2 from Andrew Pinski ---
So GCC has had problems in the past (and looks like it still) with `typedef
struct {...} name;` Which should be the same as `struct name {...};` for C++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118117
--- Comment #1 from Lorenzo Gomez ---
I should also mention that if undef USE_VIRTUAL, then there is NO issue. So the
combination of array of nested structs (t1::t2 in this case) and having a
virtual method in t1 triggers this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103313
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Note this code was not valid as there is no way to deduce the template
> arguments based on the default argument.
Note I was slightly wrong here. it is deduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118096
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117538
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117538
--- Comment #10 from GCC Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:1d148e0401b599a3cae4183d3f33b7fa65c40464
commit r15-6354-g1d148e0401b599a3cae4183d3f33b7fa65c40464
Author: Simon Wright
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118105
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94409
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118096
--- Comment #6 from GCC Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:ed5ef9b39291e9d76e5caf4d96d7e6b09a35591e
commit r15-6353-ged5ef9b39291e9d76e5caf4d96d7e6b09a35591e
Author: Eric Botcazou
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118117
Bug ID: 118117
Summary: Array Of Nested Structs Makes Inner Struct Anonymous
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118116
--- Comment #6 from Andrew Pinski ---
>You can download full code from
>https://www.ljll.fr/lehyaric/ffcs/packs/index.html.
which specific version did you use? Also if this is not a GCC bug is there a
specific location where we can send a bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35614
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118116
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117920
Alexandre Oliva changed:
What|Removed |Added
Last reconfirmed||2024-12-18
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116871
Eric Gallager changed:
What|Removed |Added
Last reconfirmed||2024-12-18
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117865
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118116
--- Comment #4 from Andrew Pinski ---
(In reply to Prof.Dr. Selçuk Han AYDIN from comment #3)
> As I stated at the beginning, this code is running all g++ version 7 through
> 14.
That does not mean the code is valid or not. Gcc 15 is stricter w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #10 from David Binderman ---
(In reply to Sam James from comment #9)
> Ah, sorry, I see it on the original with -O2. I don't see it on the reduced
> one (though it was invalid anyway). OK.
It looks as if my reduction was invalid. My
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
--- Comment #8 from Vladimir Makarov ---
I reverted the 1st patch variant for PR117248 which resulted in this PR.
I submitted a different patch for PR117248 which does not create new failures
for libgo tests on arm.
Still it would be nice to r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118116
--- Comment #3 from Prof.Dr. Selçuk Han AYDIN ---
As I stated at the beginning, this code is running all g++ version 7 through
14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #24 from GCC Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:24df430108c0cdf83d7cccd69367a977adca7da0
commit r15-6351-g24df430108c0cdf83d7cccd69367a977adca7da0
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
--- Comment #23 from Vladimir Makarov ---
(In reply to GCC Commits from comment #15)
> The master branch has been updated by Vladimir Makarov
> :
>
> https://gcc.gnu.org/g:75e7d1600f47859df40b2ac0feff5a71e0dbb040
>
> commit r15-5997-g75e7d1600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118006
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #8 from Sam James ---
(In reply to Sam James from comment #7)
> Sure, but I can't bisect it if I can't reproduce it...
>
> On godbolt, even, I see the same results for gcc 14.1 and trunk:
> https://godbolt.org/z/o8orfaq6x.
And for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #9 from Sam James ---
Ah, sorry, I see it on the original with -O2. I don't see it on the reduced one
(though it was invalid anyway). OK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118112
--- Comment #9 from Joseph S. Myers ---
We do in fact track when () was interpreted as (void) for use by -Wtraditional,
but only in the c_arg_info, it doesn't get as far as the actual declarations
and types. If using this information in a way th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #6 from David Binderman ---
(In reply to Sam James from comment #3)
> ... ditto the original. So maybe fixed already?
I think not. I just checked today's gcc trunk and the problem
seems to still exist in the original code.
The git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118106
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118116
--- Comment #2 from Andrew Pinski ---
This might not be valid code since E_F0 is not dependent and the class does not
seem to have a member called stack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118116
--- Comment #1 from Andrew Pinski ---
Can you attach the preprocessed source?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
--- Comment #88 from Jakub Jelinek ---
In particular without #embed in the source with the
r15-4377-gf9bac238840155e1539aa68daf1507ea63c9ed80
change for C and
r15-6339-g40f243e91796671701ded90919d1ca32ba9076ad
for C++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118116
Bug ID: 118116
Summary: FreeFem++-cs compilation error with g++-15
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118105
--- Comment #2 from Jonathan Wakely ---
Why does the _BracketMatcher::_M_add_equivalence_class function use
lookup_collatename?
void
_M_add_equivalence_class(const _StringT& __s)
{
auto __st = _M_traits.lookup_collaten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> We should also consider only caching chars in the range 0-127, because
> otherwise as this bug shows we call transform_primary for 128 char values
> which alw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
--- Comment #8 from Jonathan Wakely ---
We should also consider only caching chars in the range 0-127, because
otherwise as this bug shows we call transform_primary for 128 char values which
always fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
--- Comment #7 from Jonathan Wakely ---
I don't know if this has anything to do with regex_constants::collate because
that affects character ranges like "[a-z]". Does that include "[[=A=]]"? My
assumption is it's only for hyphenated ranges, not a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
--- Comment #87 from Ian Lance Taylor ---
Nice, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
--- Comment #86 from Jakub Jelinek ---
The #c13 testcase should be fixed on the trunk (first gcc 14 C and C++ times,
then current trunk C and C++ times):
for i in /usr/src/gcc-14/obj02/gcc/cc1{,plus} /usr/src/gcc/obj14/cc1{,plus}; do
time $i -qui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118105
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> "AÀÁÂÃÄÅaàáâãäå" should all produce the same primary sort key.
Whether this is true or not depends on the locale, but also the string literal
encoding.
Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118088
--- Comment #1 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:15aab0d00ca1ed5ce428555bf89ecfe0525f9b81
commit r15-6347-g15aab0d00ca1ed5ce428555bf89ecfe0525f9b81
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118115
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118115
Bug ID: 118115
Summary: Missed Optimization: Failure to Elide Branch When
Copying Overlapping Union Members
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118007
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117457
Jonathan Wakely changed:
What|Removed |Added
Component|libstdc++ |lto
--- Comment #3 from Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
Bug 102445 depends on bug 118113, which changed state.
Bug 118113 Summary: std::regex construction from string literal causes
out-of-bounds access when compiled with O2 and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118113
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117457
Jonathan Wakely changed:
What|Removed |Added
CC||david.cortes.rivera at gmail
dot c
1 - 100 of 175 matches
Mail list logo
