https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #13 from Jan Hubicka ---
OK, I can reproduce it even though the propagation happens in different
function in dom rather than pre.
The callee is again the operator++ so I start to suspect aliasing violation
there.
I get:
ipa-modref:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #14 from Jan Hubicka ---
So this really seems that the alias set 6 is not conflicting with alias sets
11 or 13. active_cell is
struct active_cell_iterator active_cell;
and the code around seems SRA injected
MEM[(struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #15 from Jan Hubicka ---
So it seems that problem is that store in operator++ is TriaObjectAcessor while
read is DoFCellAccessor. I am however not sure where the type puning happens :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #17 from Jan Hubicka ---
And is it again the operator++ triggering the problem?
It looks like aliasing bug to me, but in a template hell and
-Wstrict-aliasing=3 is happy.
The reason why parameter tracking is necessary seems to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350
--- Comment #11 from Jan Hubicka ---
In WPA we seem to see the store to vector:
Propagated modref for push_without_duplicates/1089577
loads:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350
--- Comment #12 from Jan Hubicka ---
Aha, the code in question is:
# USE = nonlocal null { D.8330 D.22051 D.22054 D.22059 D.22060 } (nonlocal,
escaped, interposable)
# CLB = nonlocal null { D.8330 D.22051 D.22054 D.22059 D.22060 } (nonlocal,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350
--- Comment #10 from Jan Hubicka ---
OK, I was poking a bit about the problem and indeed the bootstrapped gnat with
-O3 and PGO ices, while gnat built normally does not.
We fail:
#2 0x019b7dcb in _Z13variable_sizeP9tree_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350
--- Comment #13 from Jan Hubicka ---
bug in SCC discovery. I am testing
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 4f86b9ccea1..771a0a88f9a 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -1603,6 +1603,11 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97389
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97389
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350
--- Comment #7 from Jan Hubicka ---
Interesting, i get different ICE
during GIMPLE pass: slp
../../gcc/ada/libgnat/s-os_lib.adb: In function
‘system__os_lib__normalize_pathname__missed_drive_letter’:
../../gcc/ada/libgnat/s-os_lib.adb:2133:7:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
--- Comment #8 from Jan Hubicka ---
Generally LTO is organized into a global stream containing types, decls etc.
and local streams containing funtion bodies and initializers.
Global stream thus can not contain references that are local to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #19 from Jan Hubicka ---
get_order unwinds to:
[local count: 1073741824]:
_1 = __builtin_constant_p (size_68(D));
if (_1 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
if (size_68(D) ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97335
--- Comment #10 from Jan Hubicka ---
Created attachment 49338
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49338=edit
disable param tracking on clones
Perhaps this has chance to help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97403
Bug ID: 97403
Summary: Ancestor jump function should be generalized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97133
--- Comment #3 from Jan Hubicka ---
modref is a stale infoa (streaming happens after running the ipa passes and
moref is last). It is Maritn Sebor's change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97244
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97243
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97235
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97244
Jan Hubicka changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576
--- Comment #2 from Jan Hubicka ---
The problem here is that clone materialization invalidates statement pointers
in refs. We clean these at the begining of late optimization, I guess it
should be done on demand during materialization (they are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97593
--- Comment #2 from Jan Hubicka ---
Hmm, this is anoying: we can not store summary to PCH. I guess we want to
collect thunks to a vector and annotate them to callgraph at finalization time
:(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
Jan Hubicka changed:
What|Removed |Added
CC||jakub at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97867
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98173
Bug ID: 98173
Summary: -fno-tree-pta improves tfft2 benchmark by 50% on zen
and -march=natie.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79506
--- Comment #2 from Jan Hubicka ---
badness being a very small negative number is actually normal for large
functions like this one (perhaps I should print it better though). I can check
from where the estimated speedup comes - perhaps we work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79506
--- Comment #3 from Jan Hubicka ---
Actually it is visible from the dump
Scaling time by probability:0.00
means that we expect quite few values to be "almost invariant". It may come
from busted BB profile of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98173
Jan Hubicka changed:
What|Removed |Added
Keywords|missed-optimization |
Version|11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97867
--- Comment #4 from Jan Hubicka ---
Sorry, I lost track of this, because i still hit the strange linker error with
building libjit
The following ghsould fix it.
diff --git a/gcc/symtab-thunks.h b/gcc/symtab-thunks.h
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97775
--- Comment #1 from Jan Hubicka ---
Forgot to say, flags to reproduce are: -Os t2.c -fno-tree-sra -fno-ipa-modref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97775
Bug ID: 97775
Summary: Wrong code with bitfield
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #6 from Jan Hubicka ---
I remember that first_field was returning non-NULL (perhaps it is derived from
empty base)?
My patch touched nothing on the condition: it just improved the alias analysis.
So while previously we tought that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836
--- Comment #5 from Jan Hubicka ---
I forgot to attach the PR number, but I commited the quick fix (to prevent
wrong code) as g:26285af40f98dfdb809b98b08386073c63b65db1
I will discuss the EAF_UNUSED flag today after teaching.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97757
--- Comment #3 from Jan Hubicka ---
This is problem with propagate_in_scc sometimes freeing the summary and losing
track of it. It is fixed in
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559116.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97855
Bug ID: 97855
Summary: [11 regression] Bogus warning locations during
lto-bootstrap
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97854
Bug ID: 97854
Summary: [11 regression] ODR violation in stub-objc.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #8 from Jan Hubicka ---
In my setup I get ICE segfault with
#0 0x011fcf44 in vec::release (this=0x0) at ../../gcc/vec.h:1811
#1 0x011fcf2f in auto_vec::~auto_vec
(this=, this=) at ../../gcc/vec.h:1542
#2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
Jan Hubicka changed:
What|Removed |Added
Component|middle-end |bootstrap
--- Comment #1 from Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #15 from Jan Hubicka ---
Current mainline with
1) fix to COMPONENT_REFs described above
2) improvement of ODR type having for THIS pointers
3) gimple_clobber fix (already approved)
4) compare_ao_refs fix for volatile accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #13 from Jan Hubicka ---
Actually, I did not wait long enough for ICF to finish dumping. Here is the
correct output. Still nice improvement for OBJ_TYPE_REF
8399 false returned: 'parameter type is not compatible' in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #14 from Jan Hubicka ---
I fixed some issues
1) merging of OBJ_TYPE_REF was broken
2) last version of my COMPONENT_REF patch clears incorrectly OEP_ADDRESS_OF
3) gimple clobbers mismatches for no good reason
4) volatile memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
Jan Hubicka changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
--- Comment #11 from Jan Hubicka ---
Jakub,
with code patterns
if (foo)
ininit var
...
if (foo)
use var
the false positive really depends on how far we do jump threading and similar
transforms.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #10 from Jan Hubicka ---
Here are main reason for miscompares:
1125 libxul.so.wpa.076i.icf: false returned: 'variables types are
different' in equals at ../../gcc/ipa-icf.c:1697
1171 libxul.so.wpa.076i.icf: false returned:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #9 from Jan Hubicka ---
Created attachment 49578
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49578=edit
Memory use of GCC trunk (11) without ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #8 from Jan Hubicka ---
Created attachment 49577
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49577=edit
Memory use of GCC trunk (11) with ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #11 from Jan Hubicka ---
Created attachment 49582
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49582=edit
Memory use of GCC 10 release branch with ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
Bug ID: 97857
Summary: profiledbootstrap broken freeing speculative call
summary
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #9 from Jan Hubicka ---
Created attachment 49571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49571=edit
Warnings building cc1plus with LTO
This is current set of wranings building cc1plus with LTO. there are 66
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
Bug ID: 97858
Summary: [11 regression] Bogus warnings about va_list during
profiledbootstrap
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #12 from Jan Hubicka ---
With ODR name hashing fix and fix to streaming the access types we now get:
957 false returned: 'different references' in compare_symbol_references
at ../../gcc/ipa-icf.c:465
961 false returned:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80379
--- Comment #3 from Jan Hubicka ---
The problem here is that the hint is output at decl merging and
-fno-strict-aliasing is a function local flag. At that time we do not even know
what functions will be since units are not streamed in yet. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97757
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #6 from Jan Hubicka ---
I just noticed this PR and wonder if there is anything to do on inliner side.
It uses DECL_DECLARED_INLINE that was invented to distinguish between implicit
inlines and explicit ones. So even if it would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97766
Jan Hubicka changed:
What|Removed |Added
Last reconfirmed||2020-11-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572
Jan Hubicka changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97937
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #2 from Jan Hubicka ---
Ok, so the warning is triggering when uninitialized memory is passed to
function argument declared as const. This happens here but is false positive
since the parameter is not used at all. This may have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #4 from Jan Hubicka ---
And to explain why warning does not trigger without modref, it is because we
are not able to disambiguate the variable with another function call (since we
think it escapes)
(gdb) p debug_gimple_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Jan Hubicka changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
--- Comment #8 from Jan Hubicka ---
OK, I comitted patch as is and we could see if any memory can be conserved by
being more precise. I still think the debug info should not need decls here.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652
--- Comment #1 from Jan Hubicka ---
Actually there is another propagation happening in ipa-cp analysis:
--- aa/pdt_14.f03.077i.cp 2020-10-31 09:00:52.809726530 +0100
+++ pdt_14.f03.077i.cp 2020-10-31 09:10:35.204755828 +0100
@@ -10,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652
Bug ID: 97652
Summary: New pdt14 failure after
g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652
Jan Hubicka changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97672
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
Jan Hubicka changed:
What|Removed |Added
Component|c |ipa
--- Comment #48 from Jan Hubicka ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
Jan Hubicka changed:
What|Removed |Added
Depends on||97519, 97503
--- Comment #49 from Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97519
Bug ID: 97519
Summary: builtin_constant_p (x + cst) should be optimized to
builtin_constant_p (x)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97593
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97300
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97673
--- Comment #2 from Jan Hubicka ---
This should be dup of PR97578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97698
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97735
Bug ID: 97735
Summary: ipa-prop should handle simple casts
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98739
Bug ID: 98739
Summary: -fprofile-reproducible is broken
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836
Jan Hubicka changed:
What|Removed |Added
Summary|[11 Regression] wrong code |wrong code at -O1 on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594
--- Comment #3 from Jan Hubicka ---
The initialization is removed by dse1 pass. We get:
ipa-modref: call stmt D.3199 = bitCount::bitCount_bitfield<1, int,
glm::packed_highp> (); [return slot optimization]
ipa-modref: call to glm::vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98499
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101257
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101270
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785
--- Comment #16 from Jan Hubicka ---
OK,we seem to handle all relevant always_inlines in early passes and then we
produce functions large function with many non-always_inline calls that we
spend a lot of time inlining. This is becuase we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785
--- Comment #15 from Jan Hubicka ---
We run into the size estimate with always inlines because after inlining we
update the size of caller (because that does matter when inlining normal
functions).
We already have special purepose always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #16 from Jan Hubicka ---
I was trying to reproduce some kind of ICE for a while, trying to also rebuild
with ggc forced on every ggc_collect call, but no luck.
I wonder if you happen to know specific gcc regression that was failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #18 from Jan Hubicka ---
> Looking around the only place (we don't know whether this was WPA or LTRANS)
> we'd have a cgraph with edges is during clone materialization which pointed
> me at cgraph_node::release_body which frees the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #19 from Jan Hubicka ---
Created attachment 50485
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50485=edit
small refactoring
this patch moves the removal to release_body and removes the calls on those
paths where removal is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #20 from Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99751
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836
--- Comment #8 from Jan Hubicka ---
indeed, I think for gcc11 we want to make return mark value as used and for
next stage1 we want to design EAF flags bit more carefully...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99751
--- Comment #8 from Jan Hubicka ---
So we wrongly identify nodirectescape in store_to_c this is due to early exit
in analyze_call that does not account for const call possibly returning its
parameter. (An early confusion in EAF tracking logic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99751
--- Comment #9 from Jan Hubicka ---
OK, so actually there is logic to handle return values (even for consts) but it
has wrong if. I am testing the attached fix.
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 7aaf53be8f4..5f33bb5b410
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309
--- Comment #5 from Jan Hubicka ---
As discussed, I can prepare patch to make inliner to redirect
__builtin_constant_p to __builtin_true whenever inliner detect that the
expression is compile time ocnstant. This will avoid us eventually hitting
1 - 100 of 695 matches
Mail list logo
