https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110168
Bug ID: 110168
Summary: Security issue on FORTIFY_SOURCE for strcpy function
(tested on i386/32 bits)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110152
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2b2bf793d3fb8980cb2b83e9e2a8c236ad2434f5
commit r14-1630-g2b2bf793d3fb8980cb2b83e9e2a8c236ad2434f5
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109939
--- Comment #6 from CVS Commits ---
The releases/gcc-13 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:8f170995aac3fd568652eb208eca62e3937d0cf1
commit r13-7428-g8f170995aac3fd568652eb208eca62e3937d0cf1
Author: Kyrylo Tkachov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109939
--- Comment #7 from CVS Commits ---
The releases/gcc-12 branch has been updated by Kyrylo Tkachov
:
https://gcc.gnu.org/g:a620451032abb28343c31438a4e779ea5d2e1bbf
commit r12-9683-ga620451032abb28343c31438a4e779ea5d2e1bbf
Author: Kyrylo Tkachov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110152
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110138
Hongyu Wang changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110138
--- Comment #5 from Jonathan Wakely ---
Just use a stateful allocator and check that the correct state is propagated.
See testsuite/21_strings/basic_string/allocator/char/operator_plus.cc which
does exactly that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110138
--- Comment #6 from Jonathan Wakely ---
What matters is the "value" of the allocator, not how many times it gets
copied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
--- Comment #18 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #17)
> The new testcase seems to fail on big-endian hosts. I've analyzed this on
> 11 branch:
>
[...]
> So, presumably we need in addition to the
> && thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110147
--- Comment #2 from Jonathan Wakely ---
--- a/libiberty/rust-demangle.c
+++ b/libiberty/rust-demangle.c
@@ -1569,8 +1569,11 @@ str_buf_append (struct str_buf *buf, const char *data,
size_t len)
if (buf->errored)
return;
- memcpy (buf->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109437
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Benjamin Priour :
https://gcc.gnu.org/g:9589a46ddadc8b93c224c3f84fa94746c04596bf
commit r14-1632-g9589a46ddadc8b93c224c3f84fa94746c04596bf
Author: Benjamin Priour
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109439
--- Comment #2 from CVS Commits ---
The trunk branch has been updated by Benjamin Priour :
https://gcc.gnu.org/g:9589a46ddadc8b93c224c3f84fa94746c04596bf
commit r14-1632-g9589a46ddadc8b93c224c3f84fa94746c04596bf
Author: Benjamin Priour
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
--- Comment #2 from Jonathan Wakely ---
The "obvious" alternative impl using a lambda expression is even slower:
template
struct array
{
int data[N];
};
template struct seq { };
#ifndef USE_LAMBDA
template
array
to_array_impl(int (&a)[sizeo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
--- Comment #3 from Jonathan Wakely ---
$ time ~/gcc/9/bin/g++ 110167.cc -c -O3
real0m5.568s
user0m5.497s
sys 0m0.035s
$ time ~/gcc/10/bin/g++ 110167.cc -c -O3
real0m5.393s
user0m5.355s
sys 0m0.028s
$ time ~/gcc/11/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> The "obvious" alternative impl using a lambda expression is even slower:
Actually for GCC 13 it's faster:
$ time ~/gcc/13/bin/g++ 110167.cc -c -O3
real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110169
Bug ID: 110169
Summary: wrong code with '-Ofast'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110169
--- Comment #1 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 55283
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55283&action=edit
The compiler output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
--- Comment #5 from Jonathan Wakely ---
It's hard to bisect where it got slower between 10 and 11, and between 11 and
12, because for --enable-checking builds the extra assertions slow everything
down and the difference between "fast with slow a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170
Bug ID: 110170
Summary: Sub-optimal conditional jumps in conditional-swap with
floating point
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170
--- Comment #1 from Andrew Pinski ---
Is that only valid if not trapping math?
Gcc defaults to -ftrapping-math . Try disabling it and see if you get that
result.
Also is that correct for nans?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110169
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170
--- Comment #2 from Antony Polukhin ---
-fno-trapping-math had no effect
Some tests with nans seem to produce the same results for both code snippets:
https://godbolt.org/z/GaKM3EhMq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #68 from Alexander Klepikov
---
OK, I finished my patch. Let me remind you briefly, what it does.
First, it does not emit library call for ashrsi3 during expand pass. Instead it
emits intermediate 'collapsed' libcall insn which is e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110125
--- Comment #2 from Thorsten Otto ---
Maybe related to this:
MODULE foo;
TYPE Head = RECORD
magic: INTEGER;
END;
Carrier = RECORD
head: Head;
tail: Head;
END;
PROCEDURE test(VAR car
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #69 from Alexander Klepikov
---
Created attachment 55284
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55284&action=edit
Collapsed libcall and additional loop move invariants patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #7 from Martin Jambor ---
I see, thanks! But I wonder whether it would make sense to commit the simple
fix in the meantime so that the test pass. It is easy to miss new regressions
now when I expect the overall result not to be cle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109739
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110171
Bug ID: 110171
Summary: [[nodiscard]] of await_resume ignored when discarding
result of co_await expression
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #70 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #69)
> Created attachment 55284 [details]
> Collapsed libcall and additional loop move invariants patch
Thanks for sharing the patch. I also don't have the GCC SH t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170
--- Comment #3 from Andrew Pinski ---
So for arm, GCC does produce the code you want:
```
vcmpe.f64 d17, d16
vmrsAPSR_nzcv, FPSCR
ite pl
vmovpl.f64 d18, d17
vmovmi.f64 d18, d16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172
Bug ID: 110172
Summary: Leak false positives from -fanalyzer with -fexceptions
(even on C code)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165
--- Comment #4 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #3)
> If zero_one_valued_p is true for [-1, 0] valued cases, then it should be
> fixed.
I think that is the right appoarch in the end, I will go and implement that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110168
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110147
Mark Wielaard changed:
What|Removed |Added
Last reconfirmed||2023-06-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173
Bug ID: 110173
Summary: [14 Regression] Missed Dead Code Elimination when
using __builtin_unreachable since r14-569-g21e2ef2dc25
Product: gcc
Version: 14.0
Status: UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173
--- Comment #1 from Theodoros Theodoridis ---
*The first piece of ASM is generated by gcc 13.1, the second by gcc trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173
--- Comment #2 from Andrew Pinski ---
Hmm
static void i() { *h = j(); }
static int *j(unsigned o) {
I suspect this is just might be another one of these cases where a variable is
uninitialized gets a different value now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110174
Bug ID: 110174
Summary: Using illegal constraints for builtin return_address
gives ICE
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110175
Bug ID: 110175
Summary: [GCC][Crash] GCC Crash on valid code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
Bug ID: 110176
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110177
Bug ID: 110177
Summary: [12/13/14 Regression] Missed Dead Code Elimination
when using __builtin_unreachable since
r12-2305-g398572c1544
Product: gcc
Version: 14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
--- Comment #6 from Jonathan Wakely ---
The bottom line, however, is that this use of std::to_array is not really
reasonable.
You're asking the compiler to create a variadic pack of 262144 integers, and
then create a pack expansion for std::arr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
--- Comment #7 from Jonathan Wakely ---
For some value of 1024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #71 from Alexander Klepikov
---
> There are some formatting nits in your patch, please check again:
Thanks for pointing that out, I'll check again.
> But more interestingly:
> * Do we really need to add that new source file sh_loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
Jonathan Wakely changed:
What|Removed |Added
Summary|excessive compile time when |excessive compile time for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110168
--- Comment #2 from José Ramón Méndez Reboredo
---
I have checked it. And you are right. Source fortification is only enabled when
using -O* options (optimization). Al also checked that the usage of the option
-D_FORTIFY_SOURCE=1 is not enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> if constexpr (_Nm > 1024 && is_trivially_default_constructible_v<_Tp>
> && is_trivially_assignable_v<_Tp&, _Tp&>)
> {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110178
Bug ID: 110178
Summary: [14 regression] gfortran.dg/gomp/target-update-1.f90
fails after r14-1579-g4ede915d5dde93
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110179
Bug ID: 110179
Summary: unwind-dw2-fde-dip.c:406: assignment makes integer
from pointer without a cast
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110180
Bug ID: 110180
Summary: On Fedora 38, egrep is now obsolescent
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110179
David Binderman changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93768
jbeulich at suse dot com changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390
Benjamin Priour changed:
What|Removed |Added
CC||vultkayn at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110168
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106392
Benjamin Priour changed:
What|Removed |Added
CC||vultkayn at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109800
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Alex Coplan
:
https://gcc.gnu.org/g:43619dc6e120a80305d4a52d7f9b8833c110a7db
commit r12-9684-g43619dc6e120a80305d4a52d7f9b8833c110a7db
Author: Alex Coplan
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108490
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
--- Comment #7 from Marek Polacek ---
A similar test. I'm not sure how we want -Wm-f-i to behave here.
#include
struct A {
int a;
std::optional b;
};
int main()
{
auto x = A {
.a = 123 // warns
};
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110175
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=110180
--- Comment #1 from Andrew Pinski ---
https://inbox.sourceware.org/gcc-patches/74ea0c62ebe19db186263053e4051f81d46e9da4.ca...@xry111.site/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Hmm
> static void i() { *h = j(); }
> static int *j(unsigned o) {
>
> I suspect this is just might be another one of these cases where a variable
> is uninitial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173
--- Comment #4 from Andrew Pinski ---
So CCP2 now removes:
Removing dead stmt:iftmp.4_9 = PHI <1(5), 0(6)>
Which allows to remove all of this:
[local count: 1073441178]:
if (t_4(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173
Andrew Pinski changed:
What|Removed |Added
Summary|[14 Regression] Missed Dead |Missed Dead Code
|Cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110173
Andrew Pinski changed:
What|Removed |Added
Summary|Missed Dead Code|[13/14 Regression] Missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #8 from Andrew Macleod ---
I just checked in:
commit cd9c7f898d6e6313465f78227e566f27dce5e5a3
Author: Andrew MacLeod
Date: Wed May 31 13:10:31 2023 -0400
Provide a new dispatch mechanism for range-ops.
As a side effect it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390
--- Comment #4 from Jonathan Wakely ---
I'm not sure that's worthwhile. Unique ownership is orders of magnitude more
common, and lifetime is managed in smaller scopes. Tracking unique ownership
within a single function is tractable, and useful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu
--- Comment #4 from An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390
--- Comment #5 from Benjamin Priour ---
> I agree that this would be a problem, but instead of implying that we need
> two attributes, I think this implies that we should not try to use
> [[gsl::owner]] for shared ownership. If you don't try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106392
--- Comment #2 from Jonathan Wakely ---
(In reply to Benjamin Priour from comment #1)
> [[gnu::invalidate(swap)]] - Both containers should be invalidated. Name
> probably ill-chosen since swapping two lists invalidates nothing.
Swapping doesn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110180
--- Comment #2 from Jonathan Wakely ---
(In reply to David Binderman from comment #0)
> Fedora 38 has decided that egrep is obsolescent and grep -E
> is preferred.
POSIX decided it, not Fedora.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106392
--- Comment #3 from Benjamin Priour ---
> I think the unordered containers might be too hard. I would start with
> std::vector, as that will probably give the best return on investment of
> effort.
>
Indeed, I just found these slides from cla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110104
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|roger at nextmoves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110181
Bug ID: 110181
Summary: longlong.h for RISCV should define count_leading_zeros
and count_trailing_zeros and COUNT_LEADING_ZEROS_0
when ZBB is enabled
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110181
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=81199
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-06-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110181
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #72 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #71)
>
> > * Do we really need to add that new source file sh_loop.cc with the wrapper
> > classes? Can't we just instantiate the passes that are needed in-place wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110177
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.4
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110177
--- Comment #1 from Andrew Pinski ---
Hmm, in ccp1, GCC 11.3 does:
Visiting statement:
# RANGE [0, 0] NONZERO 0
b_33 = (short intD.25) _11;
which is likely CONSTANT
Applying pattern match.pd:3405, gimple-match.c:27041
Applying pattern match.pd:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
Gaius Mulley changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110182
Bug ID: 110182
Summary: GCC generates incorrect results for simple Eigen Casts
/ Subtractions at -O2 or above for a 3 dimensional
vector
Product: gcc
Version: 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165
--- Comment #5 from Andrew Pinski ---
Created attachment 55287
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55287&action=edit
Patch for trunk
Have the testcases but didn't add them to the patch.
Will also Create the GCC 13 patch later t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110182
Andrew Pinski changed:
What|Removed |Added
Component|c++ |target
Summary|GCC generates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110182
--- Comment #2 from Andrew Pinski ---
>but not -O3.
Oh that is because the vectorizer is not enabled at -O2 in GCC 11 but is for
GCC 12+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110182
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110182
Andrew Pinski changed:
What|Removed |Added
Component|target |tree-optimization
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
--- Comment #1 from Andrew Pinski ---
Fre turns:
b.2_4 = b;
_5 = b.2_4 == 0;
_6 = (int) _5;
_7 = _6 <= i_19;
_8 = (int) _7;
b = _8;
Into:
b.2_4 = b;
_5 = b.2_4 == 0;
_6 = (int) _5;
b = 1;
Which is wrong as _6 <= -1 is alway
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
Andrew Pinski changed:
What|Removed |Added
Summary|wrong code at -Os and above |[10/11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
--- Comment #4 from Andrew Pinski ---
10.4.0:
Value numbering stmt = _8 = _7 <= i_19;
Applying pattern match.pd:4279, gimple-match.c:13484
Match-and-simplified _7 <= i_19 to 1
RHS _7 <= i_19 simplified to 1
Setting value number of _8 to 1
GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110183
Bug ID: 110183
Summary: ICE in extract_constrain_insn, at recog.cc:2692 on
s390x-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110181
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110177
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-06-08
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110184
Bug ID: 110184
Summary: [i386] Missed optimisation: atomic operations should
use PF, ZF and SF
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110112
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-06-08
Status|UNCONFIRM
1 - 100 of 128 matches
Mail list logo
