https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
--- Comment #31 from Martin Jambor ---
(In reply to Sam James from comment #30)
> FWIW, I haven't hit this in the wild at all, so it's not pressing for me at
> least even if ofc it should be fixed before release.
It certainly has to be fixed, I
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #29 from Martin Jambor ---
(In reply to Sam James from comment #28)
> The testcase from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097#c26
> fails on trunk still.
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118138
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118138
--- Comment #7 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6y0zq5oni@virgil.suse.cz/T/#u
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #6 from Martin Jambor ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118059
--- Comment #5 from Martin Jambor ---
Indeed, our UBSAN testsuite results are green again, thanks for the fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118097
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118138
--- Comment #3 from Martin Jambor ---
I'll have a look, though I may not be able to do so in December.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110378
--- Comment #11 from Martin Jambor ---
IIUC only the simplest testcase of the three was fixed. I'll try to re-check
soon-ish.
: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Target Milestone: ---
In r15-6296-g5d740f56a16270 (Martin Jambor: ipa: Improve how we derive
value
|1
Status|UNCONFIRMED |NEW
CC||jamborm at gcc dot gnu.org,
||pault at gcc dot gnu.org
--- Comment #1 from Martin Jambor ---
This has started with revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117360
--- Comment #8 from Martin Jambor ---
I can confirm that our UBSAN bootstrap+testsuite buildbot run passed all tests
and is nicely green again. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117142
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117442
--- Comment #4 from Martin Jambor ---
(In reply to David Malcolm from comment #3)
> Sorry about the regression. Should be fixed by the above patch.
No worries, thanks for a quick fix!
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Target Milestone
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Blocks: 86656
Target Milestone: ---
Host: x86_64-linux-gnu
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117360
--- Comment #4 from Martin Jambor ---
(In reply to Jeffrey A. Law from comment #3)
> What's interesting is I did a bootstrap with ubsan a while back to chase
> down this stuff. Could be something recently introduced or a path we didn't
> trigge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117142
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117211
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also|
: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815
--- Comment #9 from Martin Jambor ---
Right, sorry, life intervened. But I am aware of the need to backport.
However, there is a problem with the testcase that should be addressed first:
https://inbox.sourceware.org/gcc-patches/ri6v7xud7pu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #35 from Martin Jambor ---
(In reply to Richard Biener from comment #34)
> This is fixed, right?
Well, yes, but as part of this I promised to go over all VR bits in ipa-cp.*
and ipa-prop.* which is still only half done. But I do ha
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
Blocks: 63426
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114627
--- Comment #3 from Martin Jambor ---
So, should this be marked as fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 116370, which changed state.
Bug 116370 Summary: UBSAN issue in fortran/trans-expr.cc in
arrayfunc_assign_needs_temporary - enum value out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116370
What|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116370
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815
--- Comment #7 from Martin Jambor ---
Fixed on master, I plan to backport the fix (the first patch) to the affected
release branches next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #25 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6ed6kntue@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87332
Bug 87332 depends on bug 115277, which changed state.
Bug 115277 Summary: [13 regression] ICF needs to match loop bound estimates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #20 from Martin Jambor ---
Indeed, the UBSAN failures I see now look like they are all PR 116370. Thanks!
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: pault at gcc dot gnu.org
Blocks: 63426
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #14 from Martin Jambor ---
This issue is still present and unfortunately it is the kind of bug that either
creates manual periodic work because people need to go over logs to verify that
no new other UBSAN failure has appeared or it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116230
--- Comment #6 from Martin Jambor ---
Right, when I saw the equality test of doubles I thought it must be the test. I
forgot about the discrepancy of representation in memory and in the FPU.
Thanks a lot for taking a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116230
--- Comment #1 from Martin Jambor ---
Created attachment 58830
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58830&action=edit
minimized test-case
I have tried to minimize the testcase with cvise and came up with the
attached file. Howe
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: i586-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Martin Jambor changed:
What|Removed |Added
Attachment #58724|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #19 from Martin Jambor ---
(In reply to Richard Biener from comment #18)
> (In reply to Martin Jambor from comment #15)
> > Created attachment 58724 [details]
> > simple (wip) fix
> >
> > I'm wondering whether just simply something l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
--- Comment #15 from Martin Jambor ---
Created attachment 58724
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58724&action=edit
simple (wip) fix
I'm wondering whether just simply something like this would not be enough. I
have looked at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #11 from Martin Jambor ---
Our weekend ubsan bootstrap and test (of revision
r15-2173-ge0d997e913f811) still reported failures when compiling
testcase gfortran.dg/ieee/large_1.f90 (at -O2 and higher).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: law at gcc dot gnu.org
Blocks: 63426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109130
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 109130, which changed state.
Bug 109130 Summary: [13/14/15 Regression] 464.h264ref regressed by 6.5% on a
Neoverse-N1 CPU with PGO, LTO, -Ofast and -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109130
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: linkw at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: sparc-wrs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113646
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: hongyuw at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
The run-time of benchmark
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: crazylht at gmail dot com
Blocks: 26163
Target Milestone: ---
Benchmark 416.gamess from SPECINT 2006 recently regressed on
: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: ubizjak at gmail dot com
Target Milestone: ---
Compiling the testcase (minimized from grub2):
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115310
--- Comment #4 from Martin Jambor ---
(In reply to Sam James from comment #2)
> In such environments, you don't need an explicit
> -Werror=return-type.
I agree I don't need it but it is there.
> So, you're asking presumably about testing with
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Consider:
echo 'main () { return 0; }' > t.c
and then
gcc -S -Werror=re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
--- Comment #2 from Martin Jambor ---
(In reply to Jan Hubicka from comment #1)
> Reproduces on 14 and trunk. GCC 12 is not able to determine the loop bound
> during early optimizations
What about gcc 13?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115174
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #32 from Martin Jambor ---
(In reply to Marc Poulhiès from comment #31)
> Hello Martin,
>
> Any chance the fix that fixes the new test for 32bits can be also backported?
>
> 4923ed49b93352bcf9e43cafac38345e4a54c3f8
> https://gcc.gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #20 from Martin Jambor ---
The IL we generate the jump function from is:
_1 = cclauses_2(D) != 0B;
c_parser_omp_all_clauses (_1);
Which translates to the expected jump function:
callsite void c_parser_omp_teams(int**)/3 ->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #29 from Martin Jambor ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #19 from Martin Jambor ---
The following minimized testcase ICEs with r15-312-g36e877996936ab
cross-compiler to ppc64le with -O2 nicely:
void omp_clause_elt_check(int *, const char *, const char *);
enum { C_OMP_CLAUSE_SPLIT_COUNT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #16 from Martin Jambor ---
I'll have look, hopefully on Monday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106935
Martin Jambor changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
The following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106935
--- Comment #3 from Martin Jambor ---
This ICE no longer happens with GCC 13, in fact after r13-4240-gfeeb0d68f1c708
(Martin Jambor: ipa-cp: Do not consider useless aggregate constants). From the
patch description, it does not look to be a fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102310
Martin Jambor changed:
What|Removed |Added
Known to work||13.1.0
Summary|[11/12/13/14/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
--- Comment #5 from Martin Jambor ---
(In reply to Richard Biener from comment #2)
> No, I think the issue is that ESRA leaves e.f0 alone:
>
> e$f3_7 = e.f3;
> e$f0$f4_8 = e.f0.f4;
> _1 = e$f0$f4_8;
> _2 = (unsigned char) _1;
> e$f3_9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
--- Comment #6 from Martin Jambor ---
(In reply to Paweł Bylica from comment #5)
> (In reply to Martin Jambor from comment #4)
> > In this testcase all (well, both) functions referenced from the array
> > are semantically equivalent which is rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114662
--- Comment #5 from Martin Jambor ---
Thanks a lot for taking care of it before I had a chance to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #75 from Martin Jambor ---
The above fixes the testcase from comment #58. I am not sure if any other
testcases discussed here remain unresolved. I am also not sure to what extent
we want to that patch of mine, I guess I'll re-visit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #26 from Martin Jambor ---
This should be fixed on master, I'll backport the fix in a few weeks to at
least gcc-13 where it was reported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #9 from Martin Jambor ---
On master this has been fixed by r14-9813-g8cd0d29270d4ed where I
unfortunately copy-pasted a wrong bug number :-/
I assume this needs backporting to at least gcc-13 and gcc-12. I'll do
that in a week or tw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
--- Comment #4 from Martin Jambor ---
Oops. I made a mistake, the commit above fixes PR 114247, sorry :-/
This one is the next in my queue. Sorry again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #7 from Martin Jambor ---
Thanks, I will bootstrap and test the patch on x86_64 and submit it
for review then.
Can I ask you, can you please modify the testcase so that it does not
use printf but simply calls __builtin_abort in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #24 from Martin Jambor ---
(In reply to Jan Hubicka from comment #23)
> I however wonder if we really guarantee to copy the paddings everywhere else
> then the total scalarization part?
> (i.e. in all paths through the RTL expansion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #71 from Martin Jambor ---
I have sent the patch to the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6le5s25kl@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
Martin Jambor changed:
What|Removed |Added
Summary|[13/14 Regression] ICE in |[13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #4 from Martin Jambor ---
I don't seem to be able to get riscv64 qemu running in reasonable
time. Can someone please verify that the following patch fixes
the issue?
diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipu
at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #3 from Martin Jambor ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #22 from Martin Jambor ---
Created attachment 57828
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57828&action=edit
Potential fix
I'm testing this patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
Martin Jambor changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #66 from Martin Jambor ---
Created attachment 57750
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57750&action=edit
Patch comparing jump functions
I'm testing this patch. (Not sure how to best check that it does not
inadvert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114254
Martin Jambor changed:
What|Removed |Added
Summary|[11/12/13/14 regression]|[11/12/13 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802
Martin Jambor changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #65 from Martin Jambor ---
I hope to have some jump-function comparison functions ready for testing later
today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #5 from Martin Jambor ---
I'd like to ping this, are there plans to implement this in the near-ish term?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
--- Comment #4 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6r0gbwf7l@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113757
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114254
--- Comment #1 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6r0gkzvi4@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802
--- Comment #8 from Martin Jambor ---
I have proposed an improved patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6r0gkzvi4@virgil.suse.cz/T/#u
: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: jamborm at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
Target Milestone: ---
Created attachment 57634
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57634&action=edit
t
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802
--- Comment #7 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6y1bdx3yg@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111573
--- Comment #2 from Martin Jambor ---
I cannot see any difference at -O3 with or without -fno-early-inlining.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112312
--- Comment #4 from Martin Jambor ---
It seems this has been fixed in current master (which is to become gcc 14).
If my bisecting is correct, it has been fixed by r14-5628-g53ba8d669550d3 (Jan
Hubicka: inter-procedural value range propagation).
1 - 100 of 1284 matches
Mail list logo
