https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324
--- Comment #3 from David Binderman ---
(In reply to Robert Dubner from comment #2)
> David, I am not familiar with cppcheck. I have installed it, but when I try
> to run it I don't see what you are describing here.
>
> Can you tell me how to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120292
--- Comment #3 from Richard Biener ---
also "..._exec" is not a name of an optab, so this shouldn't be a
(define_expand ...), and this means it's a dead pattern as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120294
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120294
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011
Uroš Bizjak changed:
What|Removed |Added
CC||kaelfandrew at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120303
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-05-16
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120303
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.2
Summary|ICE Segmentatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120303
Bug ID: 120303
Summary: ICE Segmentation fault, in groktypename at
gcc/c/c-decl.cc:5442
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108958
--- Comment #2 from Segher Boessenkool ---
(A good patch is like: we currently generate X (because of Y Z A), but we could
do B C D instead, and generate E).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108958
--- Comment #1 from Segher Boessenkool ---
Sure. What do we need to improve on this? Please propose a patch :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119930
--- Comment #10 from Sam James ---
(In reply to Andrew Pinski from comment #9)
> The only difference between the testcase in comment #8 and the one in the
> testsuite is that the code is moved to a named function other than main and
> then that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120300
--- Comment #2 from Lee Killough ---
> The problem is Wmissing-noreturn happens after optimizations so if a
function is defined in-class it has an implicit vague linkage and not included.
The problem is more with false -Wmissing-noreturn warni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
--- Comment #8 from Andrew Pinski ---
Created attachment 61437
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61437&action=edit
Compile with -O3 -fno-early-inlining
This gets the failure before GCC 5 even.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
Andrew Pinski changed:
What|Removed |Added
Component|ipa |fortran
--- Comment #9 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
--- Comment #7 from Andrew Pinski ---
DCE removes this:
Eliminating unnecessary statements:
Deleting : _gfortran_f2c_specific__conjg_4 (&cmplx.0, &C.4660);
This might be a front-end issue though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
--- Comment #6 from Sam James ---
(In reply to Sam James from comment #5)
> ```
> $ gfortran-14 gfortran.dg/specifics_1.f90 -o a -ff2c -O2 --param
> max-inline-insns-size=50 && ./a
> STOP 1
> ```
It fails with this going back to GCC 9, but GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324
--- Comment #2 from Robert Dubner ---
(In reply to David Binderman from comment #0)
> I tried out the static analyser cppcheck on
> the source code of /cobol/.
>
> The most important things it said were:
David, I am not familiar with cppcheck.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099
--- Comment #5 from Sam James ---
```
$ gfortran-14 gfortran.dg/specifics_1.f90 -o a -ff2c -O2 --param
max-inline-insns-size=50 && ./a
STOP 1
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119793
James K. Lowden changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120292
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-05-15
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120292
Andrew Pinski changed:
What|Removed |Added
Keywords||internal-improvement
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120263
--- Comment #3 from Vineet Gupta ---
But then makes the case for removing following special case handling
```
static bool
frm_unknown_dynamic_p (rtx_insn *insn)
{
/* Return true if there is a definition of FRM. */
if (reg_set_p (gen_rtx_RE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119930
--- Comment #9 from Andrew Pinski ---
The only difference between the testcase in comment #8 and the one in the
testsuite is that the code is moved to a named function other than main and
then that function is called from main. This is to remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119930
--- Comment #8 from Andrew Pinski ---
Created attachment 61436
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61436&action=edit
New testcase that fails at -O2 even with GCC 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120252
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295
--- Comment #8 from Andrew Pinski ---
(In reply to Sam James from comment #7)
> .. and I guess with trunk, it starts to fail with the inlining changes?
The original testcase yes, the one in comment #3 failed before the inlining
changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295
--- Comment #7 from Sam James ---
.. and I guess with trunk, it starts to fail with the inlining changes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632
--- Comment #10 from James K. Lowden ---
> But it should really do that - and allow it for _any_ other standard, not
> only ibm.
We don't want to let nonstandard syntax slip by unnoticed.
IBM Linux COBOL allows SECTION segment numbers as sy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324
--- Comment #1 from James K. Lowden ---
Partly fixed by 9b78ad2cbf0.
1. function eliminated: "Function parameter 'args'":
2. dts::regex_search emulates std::regex_search, which passes cm by reference,
to write to it.
3. done: parameter 'name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120263
--- Comment #2 from Vineet Gupta ---
https://godbolt.org/z/8b1scoWGd
It seems llvm also follows the existing gcc behavior - so maybe this is INVALID
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120280
--- Comment #10 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #9)
> So the easy workaround is not use tree_expr_nonnegative_p as predicate here
> and just do:
> ```
> (simplify
> (cmp @0 zerop@1)
> (if (tree_expr_nonnegativ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295
--- Comment #6 from mcccs at gmx dot com ---
(In reply to Sam James from comment #5)
> (In reply to mcccs from comment #4)
> > (can't bisect, because) not reproducible on aarch64
>
> What about with -fsigned-char?
Thanks, that works. r15-6294-g
: ../configure
--prefix=/carnegie/nobackup/users/abenson/upstream --disable-multilib
--enable-checking=release --enable-host-shared --with-pic
--enable-languages=c,c++,fortran,jit,lto
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250515 (experimental) (GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120161
--- Comment #8 from GCC Commits ---
The releases/gcc-15 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:488c997aeb6669c333287a1f0063ce5fb706a8b5
commit r15-9690-g488c997aeb6669c333287a1f0063ce5fb706a8b5
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120161
Patrick Palka changed:
What|Removed |Added
Summary|[14/15/16 Regression] |[14 Regression] Deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120301
--- Comment #5 from H. Peter Anvin ---
Overlays is something entirely different.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120301
--- Comment #4 from Andrew Pinski ---
overlays is a solved problem with GNU ld and GNU GDB already. to some extend it
is outside of GCC:
https://ftp.gnu.org/pub/old-gnu/Manuals/ld-2.9.1/html_node/ld_22.html
https://sourceware.org/gdb/current/o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120301
--- Comment #3 from Andrew Pinski ---
What i am trying to say this feature is not so obvious of what you want/need.
There have been already proposals before on overlays years ago. That is how
most embedded folks do it except for the Linux kern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120301
--- Comment #2 from H. Peter Anvin ---
It certainly is not specific to the Linux kernel, although perhaps how I
phrased it is (in particular tying it to sections is rather specific to
embedded environments, of which the Linux kernel is but one.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120300
Bug ID: 120300
Summary: -Wmissing-noreturn is handled inconsistently for
in-class and out-of-class definitions
Product: gcc
Version: 16.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120008
--- Comment #5 from H. Peter Anvin ---
Having an -fkernel option would not be a bad thing, either; it could be used to
hide anything the compiler does that is specific to kernel space. On a lot of
platforms that would include stuff like __attrib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120008
--- Comment #4 from H. Peter Anvin ---
So I guess the real question is to what extent you actually want to support the
Linux kernel -- and other kernels -- as a compilation target.
I will agree with you that doing this with type attributes -- i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120301
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120300
--- Comment #1 from Andrew Pinski ---
>The handling of -Wmissing-noreturn should behave the same whether a member
>function is defined in-class or out-of-class.
The problem is Wmissing-noreturn happens after optimizations so if a function
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120301
Bug ID: 120301
Summary: RFE: context variables
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120280
--- Comment #9 from Andrew Pinski ---
Replaced redundant PHI node defining c_3 with c_6
Replaced redundant PHI node defining b_13 with 0
Removing unexecutable edge from if (b_13 != 0)
Removing dead stmt b_13 = PHI <0(3)>
Removing dead stmt c_3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120280
Andrew Pinski changed:
What|Removed |Added
Attachment #61434|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120280
--- Comment #7 from Andrew Pinski ---
Created attachment 61434
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61434&action=edit
Reduced testcase
This is the reduced testcase for running into the ICE issue with the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120280
--- Comment #6 from Andrew Pinski ---
Created attachment 61433
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61433&action=edit
testcase
```
t.cc:14:1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632
--- Comment #9 from Simon Sobisch ---
Note: GnuCOBOL also support that, just in case a paying customer comes around
:-)
To not break NIST85 gcobol should set -std=cobol85 to -dialect ibm, with the
current implementation.
(Note: "stacking" -dia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #11 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Tymi from comment #8)
> > (In reply to Andrew Pinski from comment #7)
> > > (In reply to Tymi from comment #6)
> > > > so it's a godbolt (compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #10 from Tymi ---
Oh okay, well it's not critical and I'm going to sleep now anyway
Thank you for your quick response, and good night
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #9 from Andrew Pinski ---
(In reply to Tymi from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > (In reply to Tymi from comment #6)
> > > so it's a godbolt (compiler explorer) bug...?
> >
> > No, just godbolt build hap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750
--- Comment #15 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:d31ab498b12ebbe4f50acb2aa240ff92c73f310c
commit r16-669-gd31ab498b12ebbe4f50acb2aa240ff92c73f310c
Author: Harald Anlauf
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #8 from Tymi ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Tymi from comment #6)
> > so it's a godbolt (compiler explorer) bug...?
>
> No, just godbolt build happened between the 2 commits.
Can we someone force/ask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #7 from Andrew Pinski ---
(In reply to Tymi from comment #6)
> so it's a godbolt (compiler explorer) bug...?
No, just godbolt build happened between the 2 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #6 from Tymi ---
so it's a godbolt (compiler explorer) bug...?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120008
--- Comment #3 from Andrew Pinski ---
(In reply to H. Peter Anvin from comment #2)
> Could you please clarify why you think this is not a good idea?
Because it is only specific to x86 and more over it is only specific to not
userland. folks wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119809
--- Comment #4 from Simon Sobisch ---
Looking forward to have a compiler targetting ISO COBOL to support that one day
:-)
Note: in C this would be a struct with int : 1, included, I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120008
--- Comment #2 from H. Peter Anvin ---
Could you please clarify why you think this is not a good idea?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #4 from Tymi ---
Why not check for __clang__ and fallback to a compatible solution then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119810
--- Comment #3 from Simon Sobisch ---
Current GCC only raises that error if there is no NL after the final (which
seems an interesting bug as well), so you won't see that error with the code
example.
Just use DATA DIVI. (= a syntax error), may
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #1 from Tymi ---
The following code does not compile with libstdc++ under clang:
```cpp
#include
int main(){}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #3 from Andrew Pinski ---
So the complex part of this is because clang does not implement the C23 defined
types still (https://github.com/llvm/llvm-project/issues/97335) but does
implement __float128 and libstdc++ looks like uses tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #2 from Andrew Pinski ---
For GCC:
# 1923 "/opt/compiler-explorer/gcc-trunk-20250515/include/c++/16.0.0/format" 3
using __flt128_t = _Float128;
# 1955 "/opt/compiler-explorer/gcc-trunk-20250515/include/c++/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295
--- Comment #5 from Sam James ---
(In reply to mcccs from comment #4)
> (can't bisect, because) not reproducible on aarch64
What about with -fsigned-char?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
Bug ID: 120299
Summary: GCC started using __flt128_t with no checking
whatsoever
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120298
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120179
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||j...@bolding-bruggeman.com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119810
James K. Lowden changed:
What|Removed |Added
CC||jklowden at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119809
James K. Lowden changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120298
Bug ID: 120298
Summary: Use of do concurrent breaks use of semicolon as
statement separator
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632
--- Comment #8 from James K. Lowden ---
> But it should really do that - and allow it for _any_ other standard, not
> only ibm.
We don't want to let nonstandard syntax slip by unnoticed.
IBM Linux COBOL allows SECTION segment numbers as syn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120288
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Looks like a missed optimization of non-nullness.
But then again this is at -O1 so there will be less optmizations.
It looks like there is less inlining for GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120288
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
James K. Lowden changed:
What|Removed |Added
CC||jklowden at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120297
Bug ID: 120297
Summary: [16 Regression] RISC-V: Miscompile at -O3
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
Andrew Pinski changed:
What|Removed |Added
Target Milestone|15.2|---
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
--- Comment #5 from Jakub Jelinek ---
And with s/auto/constexpr auto/g after even more errors ICEs starting with
r5-2539-g4a4f287dc1ae6f111b28e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.5
Keywords|needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
--- Comment #3 from Jakub Jelinek ---
With -std=c++0x #c1 ICEs starting with r5-2991-g5e0231c231404677aa1b9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278
--- Comment #10 from Ken Young ---
"Correctness" (no dead code, no dead branches) matters more than performance in
this instance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120291
--- Comment #1 from mcccs at gmx dot com ---
r12-5952-g561414cdf8ef0d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120285
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278
--- Comment #12 from Ken Young ---
For what it's worth, it has worked well for our simple bare metal ARM
applications written in C and this is the first instance where the generated
object code did extra things that were not expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120139
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120107
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120107
--- Comment #4 from GCC Commits ---
The releases/gcc-15 branch has been updated by Thomas Koenig
:
https://gcc.gnu.org/g:c6ec3a9bddb4224a2369b0284ade4b474cd4b0ce
commit r15-9687-gc6ec3a9bddb4224a2369b0284ade4b474cd4b0ce
Author: Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120139
--- Comment #2 from GCC Commits ---
The releases/gcc-15 branch has been updated by Thomas Koenig
:
https://gcc.gnu.org/g:a85776f7f64271d628ae0a04f02717ee6572e6e8
commit r15-9688-ga85776f7f64271d628ae0a04f02717ee6572e6e8
Author: Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120251
--- Comment #6 from Robert Dubner ---
And this time I figured out how to change a locale to test it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-05-15
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112410
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278
--- Comment #11 from Jakub Jelinek ---
Dead branches and dead code definitely appear in -O0 code just about
everywhere, that is not about correctness but about efficiency, which is a
non-goal for -O0.
Even at higher optimization levels compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120251
--- Comment #5 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:fae53928595341981f08ded4edcbba07ee1d5d04
commit r16-667-gfae53928595341981f08ded4edcbba07ee1d5d04
Author: Robert Dubner
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120287
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.2
Summary|[15/16 Regressi
1 - 100 of 181 matches
Mail list logo
