https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66678
--- Comment #5 from rguenther at suse dot de ---
On Wed, 9 Aug 2023, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66678
>
> --- Comment #4 from Andrew Pinski ---
> So in GCC 12+ after evrp
> # RANGE [0, 42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110963
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #8 from Thomas Neumann ---
Created attachment 55715
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55715&action=edit
patch to use the correct base pointer
The attached patch fixes the test case by using the correct base pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110966
Bug ID: 110966
Summary: should matmul_c8_avx512f be updated with
matmul_c8_x86-64-v4.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110965
--- Comment #1 from Andrew Pinski ---
Note I found this while working on PR 83247 because of the Ada failures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83247
Andrew Pinski changed:
What|Removed |Added
Depends on||110965
--- Comment #6 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110965
Bug ID: 110965
Summary: missing combining if ranges due to cast differences
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhanc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110832
--- Comment #12 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:0c563a935c47e507ad97e15860ac017c14877b31
commit r14-3118-g0c563a935c47e507ad97e15860ac017c14877b31
Author: liuhongt
Date: Wed Aug
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: gnat.dg/opt8
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&action=edit
Patch which I am testing
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 #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=108119
Eric Gallager changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|m2rte Seems like i
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=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] = 0x300020
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 nonpo
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 = i
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 deregisteri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Roman Krotov changed:
What|Removed |Added
CC||romato.san1337 at gmail dot com
--- Comme
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 suspec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83247
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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=100095
Andrew Pinski changed:
What|Removed |Added
Known to work||12.1.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95747
Freddie Witherden changed:
What|Removed |Added
CC||freddie at witherden dot org
--- Com
mustang/gcc --enable-multilib --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=110963
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-08-09
Status|UNCONFIRM
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=110963
Bug ID: 110963
Summary: [14 Regression] Dead Code Elimination Regression since
r14-2946-g46c8c225455
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
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=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=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: Mo
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: Mo
--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=101188
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=110927
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
S
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|Remov
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, data
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=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 Palka
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 b
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=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 attachm
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
-DHW
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
-DHWY_DI
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 b/gcc/fortran/re
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=110961
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
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://gist.githubusercon
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=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
Dat
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: c+
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 access
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 be
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=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=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,
> tr
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 12:
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&action=edit
Test program to reproduce SatWidenMulPairwiseAdd compilation bug (requires
CMake and Google Highway)
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&action=edit
Test program to reproduce SatWidenMulPairwiseAdd compilation bug
The attached ppc9_sat_widen_mul_pairwise_add_te
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=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 = t
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
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110952
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-08-09
Status|UNCONFI
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=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=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 upst
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 mi
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=110956
Rainer Orth changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |13.3
Summary|gcc_assert is hit
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=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=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 introduci
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 (u
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: gcc
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
__register_
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
D
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=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 binar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110832
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2023-08-09
Keywords|needs-bisec
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];
doubl
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: fort
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 doesn
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 r12-2591-g2e96b5f14e4025691b57d
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=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: We
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!
P
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 wrote:
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=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: U
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=110955
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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;
100 matches
Mail list logo
