https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110131
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> So I have a VRP patch which gets us to:
/* If the value range is defined by more than one pair,
try to optimize to a singularity if either
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
Bug ID: 110956
Summary: gcc_assert is hit at
gcc-13.2.0/libgcc/unwind-dw2-fde.c#L291 with some
special library
Product: gcc
Version: 13.2.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #3 from Petr Sumbera ---
(In reply to Andrew Pinski from comment #1)
> Are you sure this is NOT a LLVM JIT issue?
> There was a similar issue on aarch64 too; PR 108994 which was fixed in LLVM
> side.
Don't really know. But the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #18 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:b8ec3c952324f866f191883473922e250be81341
commit r14-3098-gb8ec3c952324f866f191883473922e250be81341
Author: Paul Thomas
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109893
--- Comment #2 from Andrew Pinski ---
# j_10 = PHI <0B(4), (6)>
...
_21 = j_10 == 0B;
_22 = j_10 ==
_23 = _21 | _22;
The only pass which is able to optmize the above is pre.
That is take:
```
int e;
void g();
int f(int a, int b)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
Bug ID: 110955
Summary: SIGSEGV in
libgcc_s.so.1`classify_object_over_fdes+0x140 on
Solaris SPARC with GCC 13 runtime
Product: gcc
Version: 13.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110540
--- Comment #2 from Andrew Pinski ---
So what is happening is EVRP is able to figure out _35 in the below:
# RANGE [irange] int [-8, 0]
_12 = (intD.6) j_16;
# RANGE [irange] unsigned char [0, 0][248, +INF]
b.7_32 = (unsigned char) j_16;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #51 from Jakub Jelinek ---
The easiest would be to bisect gcc in the suspected ranges, that way you'd know
for sure which git commit introduced the problem and which fixed/"fixed" it.
If it is about what the compiler emits, one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110957
Bug ID: 110957
Summary: -ffpe-trap and -ffpe-summary options issues
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110832
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2023-08-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #50 from Jürgen Reuter ---
How to proceed here? Since almost exactly a month the current gcc git master
doesn't show this problem anymore, from our CI I can deduce that the version on
July 3rd still failed, while the version on July
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110458
--- Comment #3 from Franz Sirl ---
Actually Comment 2 is only true for the original testcode (which was quite
fragile to reproduce). The reduced testcode started to fail with the backwards
jump threader rewrite in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
--- Comment #10 from Richard Biener ---
(In reply to Eric Botcazou from comment #7)
> > I suppose that argues for a tighter coupling of -fnon-call-exceptions
> > and -ftrapping-math and in particular not enabling -ftrapping-math
> > by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110958
Bug ID: 110958
Summary: [CWG 2137][accepts-invalid] Copy-list-initialization
with single element of same class only considers
converting constructors as viable
Product:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
Rainer Orth changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56612
--- Comment #2 from Richard Biener ---
We now try hard to generate lane extracts for those uses but still when we fail
(and know so during analysis - there's some support for "late" fails) we try
to adjust costing for this.
double x[1024];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110779
--- Comment #11 from CVS Commits ---
The releases/gcc-13 branch has been updated by Gaius Mulley
:
https://gcc.gnu.org/g:9043e8a8d82ac2afaf8b5fcdfcbbd12f759b14d4
commit r13-7702-g9043e8a8d82ac2afaf8b5fcdfcbbd12f759b14d4
Author: Gaius Mulley
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |13.3
Summary|gcc_assert is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587
--- Comment #22 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:b66e613a1a8d5b8fc9d8b03f7b60260700acf833
commit r14-3095-gb66e613a1a8d5b8fc9d8b03f7b60260700acf833
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #15 from Paul Thomas ---
(In reply to kargl from comment #14)
> (In reply to Paul Thomas from comment #13)
> > (In reply to Steve Kargl from comment #12)
> > > On Mon, Aug 07, 2023 at 10:04:54PM +, kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #16 from Paul Thomas ---
>
> I am wondering about the pureness test itself, however. Surely, the test
> should be for impure procedures that are referenced and not just accessible?
>
> Paul
Cancel that comment - it's nonsense!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #17 from Tomáš Trnka ---
(In reply to kargl from comment #10)
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 3cd470ddcca..b0bb8bc1471 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #1 from Thomas Neumann ---
The assert says that the code tries to de-register a frame that it did not
register before or that was deregistered before. If you see that failing you
might want to add some print statements to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #2 from Andreas Schwab ---
Maybe the .eh_frame section is not properly terminated, like PR 110066.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #5 from Rainer Orth ---
(In reply to Andrew Pinski from comment #1)
> Are you sure this is NOT a LLVM JIT issue?
I certainly cannot exclude that. Currently, the Solaris LLVM build includes a
local
JIT patch that I tried to get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110952
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-08-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110950
--- Comment #4 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:c4d618143048ac781f435638ef6e788ba870dc53
commit r14-3099-gc4d618143048ac781f435638ef6e788ba870dc53
Author: Juzhe-Zhong
Date: Wed Aug 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #19 from CVS Commits ---
The releases/gcc-13 branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:ed049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7
commit r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7
Author: Paul Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #6 from Rainer Orth ---
(In reply to Rainer Orth from comment #5)
> > There was a similar issue on aarch64 too; PR 108994 which was fixed in LLVM
> > side.
>
> It looks similar indeed. However, AFAICS the LLVM JIT code has been
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110950
--- Comment #3 from JuzheZhong ---
Fix patch here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626795.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #5 from Thomas Neumann ---
The assert itself is old, it was just updated due to code changes. And
asserting there makes sense, if we keep an old frame around we might see a
crash later during unwinding if the unwinder tries to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #4 from Thomas Neumann ---
I am not sure what caused that, but in GCC 13 the unwinding logic now looks
into the table when registering the frame, while previously the table was only
inspected on the first exception. Which means we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110959
Bug ID: 110959
Summary: gdc: internal compiler error: in layout_aggregate_type
in recursive templated class
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56612
--- Comment #3 from Richard Biener ---
Another example is derived from gcc.dg/vect/bb-slp-46.c (which has 'int'
instead of 'unsigned int'):
unsigned int a[4], b[4];
unsigned int foo ()
{
unsigned int tem0 = a[0] + b[0];
unsigned int temx =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960
--- Comment #2 from John Platts ---
Created attachment 55711
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55711=edit
Test program to reproduce SatWidenMulPairwiseAdd compilation bug (requires
CMake and Google Highway)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960
--- Comment #3 from John Platts ---
Here is the output of running the "./tests/mul_test" program in the Google
Highway test suite when compiled with the "-mcpu=power8
-DHWY_DISABLED_TARGETS=6917951240106147840" options when compiled with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56482
--- Comment #7 from Karlson2k ---
Sorry, I can't check it, my build environment was lost a long time ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110961
--- Comment #3 from Marek Polacek ---
Probably a dup of bug 105667.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #4 from Richard Biener ---
(In reply to Thomas Neumann from comment #1)
> The assert says that the code tries to de-register a frame that it did not
> register before or that was deregistered before.
Did we assert for these cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110961
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960
Bug ID: 110960
Summary: TestSatWidenMulPairwiseAdd in the Google Highway Test
suite fails when compiled with GCC 12 or later with
the -mcpu=power9 option
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110961
Bug ID: 110961
Summary: internal compiler error: segmentation fault
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110961
--- Comment #1 from Bogdan Burlacu ---
Note that I couldn't make an attachment due to file size restrictions (despite
my attempts to compress the file), so I uploaded preprocessed source generated
by -freport-bug here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #8 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:165b1f6ad1d3969e2c23417797362d0528e65c79
commit r14-3092-g165b1f6ad1d3969e2c23417797362d0528e65c79
Author: Kewen Lin
Date: Wed Aug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #9 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:4a8e6fa8016f8daf184dec49f371ca71b1cb0f01
commit r14-3093-g4a8e6fa8016f8daf184dec49f371ca71b1cb0f01
Author: Kewen Lin
Date: Wed Aug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #10 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:0412f0e374de1f66e20c407e0b519324af3fd5b6
commit r14-3094-g0412f0e374de1f66e20c407e0b519324af3fd5b6
Author: Kewen Lin
Date: Wed Aug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110779
--- Comment #10 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:e3476ed2233911e6a578488899179bd91e818947
commit r14-3097-ge3476ed2233911e6a578488899179bd91e818947
Author: Gaius Mulley
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
--- Comment #11 from Richard Biener ---
Internally we might want to introduce
HONOR_FPE_{DIVBYZERO,INEXACT,INVALID,OVERFLOW,UNDERFLOW} so transforms can
be appropriately annotated. There might be a difference between preserving
and not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #2 from Rainer Orth ---
Confirmed. Same issue on current trunk.
Seems to call for a reghunt given the large number of unwinder changes since
GCC 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110950
--- Comment #2 from JuzheZhong ---
Confirm. Will fix it soon.
Thanks for report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960
--- Comment #1 from John Platts ---
Created attachment 55710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55710=edit
Test program to reproduce SatWidenMulPairwiseAdd compilation bug
The attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110131
--- Comment #6 from Andrew Macleod ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > So I have a VRP patch which gets us to:
>
> /* If the value range is defined by more than one pair,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100095
Andrew Pinski changed:
What|Removed |Added
Known to work||12.1.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #25 from Andrew Pinski ---
We have this now:
if (tmp.3_3 > 0)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 633507679]:
_10 = _12 == 0;
[local count: 1073741824]:
# iftmp.2_5 = PHI <_10(3), 0(2)>
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #55 from Ed Catmur ---
(In reply to Roman Krotov from comment #54)
[[nodiscard]] is in C23, so we can expect that attribute to be adopted where
people intend that behavior (warning suppressible by cast to void) as opposed
to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108119
Eric Gallager changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|m2rte Seems like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95643
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.0
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95643
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83247
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Roman Krotov changed:
What|Removed |Added
CC||romato.san1337 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #7 from Thomas Neumann ---
Thanks for the pointer, I could reproduce the problem in a VM now.
That shared library uses an usual table encoding that has to reference the
original base pointer within get_pc_range. But when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66678
--- Comment #4 from Andrew Pinski ---
So in GCC 12+ after evrp
# RANGE [0, 4294967294] NONZERO 4294967295
_1 = (long unsigned intD.16) i_9;
# RANGE [0, 17179869176] NONZERO 17179869180
_2 = _1 * 4;
...
# RANGE [1, 4294967295]
i_17 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80641
--- Comment #16 from Andrew Pinski ---
Note starting in GCC 13 at -O3, we are able to optimize this all the way to:
```
int f ()
{
int * _54;
[local count: 114863531]:
_54 = operator new (16);
MEM [(char * {ref-all})_54] =
ilib --with-abi=lp64d
--with-arch=rv64gc --with-tune= --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2
-mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medany'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230809 (experimental) (g5c27c911f6b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110954
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95747
Freddie Witherden changed:
What|Removed |Added
CC||freddie at witherden dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #22 from Tomáš Trnka ---
(In reply to Steve Kargl from comment #21)
> I missed your comment #7 as simply grabbed the "slightly
> more simplified" attachment and started a bug hunt from there.
> Do either of the other testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #6 from ro at manam dot mail-host-address-is-not-set ---
> --- Comment #3 from Rainer Orth ---
> (In reply to Thomas Neumann from comment #1)
>> The assert says that the code tries to de-register a frame that it did not
>> register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110963
Bug ID: 110963
Summary: [14 Regression] Dead Code Elimination Regression since
r14-2946-g46c8c225455
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109761
--- Comment #11 from CVS Commits ---
The releases/gcc-11 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:60a8421ee457d94880e4dcbb93a663c633f2e96e
commit r11-10944-g60a8421ee457d94880e4dcbb93a663c633f2e96e
Author: Patrick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181
Patrick Palka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927
--- Comment #3 from Patrick Palka ---
*** Bug 109181 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927
Bug 110927 depends on bug 109181, which changed state.
Bug 109181 Summary: requires expression type requirement rejects valid type
when it is a nested member template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110963
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #21 from Steve Kargl ---
On Wed, Aug 09, 2023 at 10:08:45AM +, trnka at scm dot com wrote:
>
> --- Comment #17 from Tomáš Trnka ---
> (In reply to kargl from comment #10)
> > diff --git a/gcc/fortran/resolve.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960
--- Comment #5 from John Platts ---
The version of Google Highway with the TestSatWidenMulPairwiseAdd changes to
get TestSatWidenMulPairwiseAdd to pass successfully on POWER9 with the
"-mcpu=power9 -DHWY_DISABLED_TARGETS=6918232715082858496
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #23 from Steve Kargl ---
On Wed, Aug 09, 2023 at 04:19:52PM +, trnka at scm dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
>
> --- Comment #22 from Tomáš Trnka ---
> (In reply to Steve Kargl from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
th-abi=lp64d
--with-arch=rv64gc --with-tune= --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2
-mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medany'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230809 (experimental) (g5c27c911f6b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960
--- Comment #4 from John Platts ---
I had made some changes to TestSatWidenMulPairwiseAdd in hwy/tests/mul_test.cc
that would get TestSatWidenMulPairwiseAdd to pass successfully on POWER9 when
compiled with GCC 12 with the "-mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109761
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279
--- Comment #1 from Di Zhao ---
Here's a small example for the issue exposed in 508.namd_r:
#define LOOP_COUNT 8
typedef double data_e;
#include
__attribute_noinline__ data_e
foo (data_e a, data_e b, data_e c, data_e d,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100798
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:7fb65f102851248bafa0815401d8bdcea6d7626c
commit r14-3110-g7fb65f102851248bafa0815401d8bdcea6d7626c
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110937
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:7fb65f102851248bafa0815401d8bdcea6d7626c
commit r14-3110-g7fb65f102851248bafa0815401d8bdcea6d7626c
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110954
--- Comment #3 from Andrew Pinski ---
Cleaned and simplified up testcase:
```
#define comparison (f < 0)
int main() {
int f = 0;
int d = comparison | !comparison;
if (d != 1)
__builtin_abort();
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 105523, which changed state.
Bug 105523 Summary: Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100798
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110937
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110963
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-08-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83247
--- Comment #3 from Andrew Pinski ---
This was literally 4 lines which needed to change now.
The use of range_of_expr inside simplify_casted_compare just needed to be
passed the statement and that fixed it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83247
--- Comment #5 from Andrew Pinski ---
Some failures ...
gnat.dg/opt86a.adb: pattern found 1 times
FAIL: gnat.dg/opt86a.adb scan-tree-dump-times optimized ">>" 4
+FAIL: gnat.dg/opt86b.adb scan-tree-dump-not optimized "> 13"
+FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83247
--- Comment #4 from Andrew Pinski ---
Created attachment 55714
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55714=edit
Patch which I am testing
99 matches
Mail list logo
