Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
pdt14 is miscompiled with -fipa-modref. This is triggered by handling fnspec,
but it seems to only trigger latent problem.
The
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=97576
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
--- 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=97445
Jan Hubicka changed:
What|Removed |Added
Depends on||97519, 97503
--- Comment #49 from Jan Hubi
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
As discussed in PR97445 we should optimize builtins_constant_p (var+cst) and
similar cases.
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
--- 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) == 0)
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 functio
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 @@ make_pass_ipa_mo
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 #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 #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 (size=0x7ff
: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
In the following we should be able to propagate through test in ipa-cp, but we
are not.
struct foo {int bar};
__attribute__
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: int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97389
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #1 from Jan Hubicka ---
Mine.
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&action=edit
disable param tracking on clones
Perhaps this has chance to help.
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 the
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 #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 TriaRawIter
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: i
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=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=97243
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=97244
Jan Hubicka changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #4 fro
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=96337
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96482
--- Comment #4 from Jan Hubicka ---
that patch makes ccp to actually use the bit info ipa-cp determines. Before we
used it only to detect pointer alignments if I remember correctly. So it looks
like propagation bug uncovered by the change. Small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #9 from Jan Hubicka ---
scimark
GCC 9:
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to p...@nist.gov)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #8 from Jan Hubicka ---
This is the built withour release flags override as seems to be done by
phoronix:
GCC 9:
y4m [info]: 1920x1080 fps 30/1 i420p8 frames 0 - 599 of 600
raw [info]: output file: /dev/null
x265 [info]: HEVC encod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #7 from Jan Hubicka ---
X265
GCC 9:
y4m [info]: 1920x1080 fps 30/1 i420p8 frames 0 - 599 of 600
raw [info]: output file: /dev/null
x265 [info]: HEVC encoder version 3.1.2+1-76650bab70f9
x265 [info]: build info [Linux][GCC 9.3.1][64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #6 from Jan Hubicka ---
Coremark.
GCC 9 run1:
CoreMark Size: 666
Total ticks : 12310
Total time (secs): 12.31
Iterations/Sec : 24370.430544
Iterations : 30
Compiler version : GCC9.3.1 20200406 [revision
6db83
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #5 from Jan Hubicka ---
OK, I started with checking Himeno where phoronix reports 4377->2681
on my notebook (Intel(R) Core(TM) i7-6600U CPU) there may be around 1-5%
regression that is not inliner related
GCC 10
Loop executed for 74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #4 from Jan Hubicka ---
There was changes to -O2 inliner. I have
- enabled auto-inlininig
- reduced early inlining a bit
- reduced limits for inlining functions declared inline
The second two was needed to keep code size under con
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Created attachment 48675
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48675&action=edit
testcase
Build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #44 from Jan Hubicka ---
Thanks, I am happy we now have real-world use of symver attribute. I have WIP
patch for better control over the symbol visibility, but I have run into
problems with gas limitations which was fixed by HJ about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955
--- Comment #2 from Jan Hubicka ---
Created attachment 48455
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48455&action=edit
testcase
: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Created attachment 48454
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48454&action=edit
proposed patch
This was reported to me by Mark Williams (who also did the testcase and
proposed patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Summary|[9/10 regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94539
--- Comment #2 from Jan Hubicka ---
Hmm, the testcase is mine so I will take a look (and make it dg-do-run :)
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #19 from Jan Hubicka ---
The reason why we get link failure is that we behave differently to mismatched
comdats. While linker choose comdat that wins and eliminate other one we keep
the other symbol and end up compiling it which lead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #11 from Jan Hubicka ---
The problem is that on ARM sizeof (short) == sizeof (int)
and LTO will glob all short and int pointers together. So this is missed
optimization only.
We do this globing sort of by design. For GCC11 I plan to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #17 from Jan Hubicka ---
Note that to fully fix the problem we need to resolve the way aliases works.
In this case ODR violation makes one COMDAT section to contain only ctor, while
other contains ctor and its thunk. The first COMDAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91322
--- Comment #8 from Jan Hubicka ---
Do we have compile farm machine where this can be reproduced?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051
Jan Hubicka changed:
What|Removed |Added
Target Milestone|8.5 |11.0
--- Comment #23 from Jan Hubicka ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91028
Jan Hubicka changed:
What|Removed |Added
Assignee|hubicka at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94243
Jan Hubicka changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #1 fro
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
While working on PR93347 I noticed that we do not devirtualize the following
testcases that clang's testsuite tests to be devirtua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93347
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94202
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #15 from Jan Hubicka ---
The testcase has an ODR violation that makes comdat groups go out of sync. So I
guess it is just about finding way to not make verifier to ICE.
With release settings the testcase will however quietly compile t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92372
--- Comment #10 from Jan Hubicka ---
*** Bug 93351 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93351
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92372
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
--- Comment #15 from Jan Hubicka ---
The following testcase:
union U { long long i; long f; };
struct a {union U u;};
struct aa {struct a a;};
struct b {union U u;};
struct bb {struct b b;};
long
foo (struct bb *bv, void *ptr)
{
struct aa *a =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
--- Comment #14 from Jan Hubicka ---
Created attachment 47901
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47901&action=edit
another related testcase
> But that means we now miscompile the later two tests.
Good point, those are my testc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90869
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Jan Hubicka ---
N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93586
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
--- Comment #12 from Jan Hubicka ---
Created attachment 47898
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47898&action=edit
possible fix
After some discussion with Richard it is my understanding now that FRE is
considering two stores eq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
--- Comment #9 from Jan Hubicka ---
This only work because the directory does not change from build time to train
time. The paths are not relative instead absolute path is put into every .o
file at compile time.
jan@skylake:~> gcc -fprofile-gene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
--- Comment #7 from Jan Hubicka ---
do you have example how the relative paths can be used?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
--- Comment #4 from Jan Hubicka ---
Actually passing phony / is not needed. We could do right thing with
gcc foo.c -o /ibb1/foo.o -fprofile-prefix-map==
-fprofile-generate
or
gcc foo.c -o /ibb1/foo.o -fprofile-strip-prefix=
-fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
--- Comment #3 from Jan Hubicka ---
Just to summarize discussions we had. I think we need to think through setup
where there are different build, train and pgo-buid machines and the
directories are not known in advance.
There -ffile-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #25 from Jan Hubicka ---
I wonder if that is because of parallel updates. There is quite a lot of time
between prunning and streaming out. If Firefox forks while other threads are
running, it will mess up the streamed data quite badly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #24 from Jan Hubicka ---
You can get gcda files from the treeherder links
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GacHgozaSRWbybgeUGzHVQ/runs/0/artifacts/public/build/profdata.tar.xz
https://firefox-ci-tc.services
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #23 from Jan Hubicka ---
This is stat for clang build with current mainline. half of invalidated
counters is pretty high (as expected given large number of runs merged)
== Stats for instrumented-gcc-new/ ==
stats for indirect_call:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #20 from Jan Hubicka ---
And thanks for the gcov-analysis improvemnets. It is quite handy tool now :)
and it is interesting to know where the many-target calls are. Clearly there is
not much to win on walk_tree, but I guess it all dep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #19 from Jan Hubicka ---
Seems that the multi-target speculation fallout is now fixed and also indirect
call profiling works similarly as to gcc9 now if the reproducibility logic is
disabled.
I re-benchmarked Firefox. Reproducible m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384
--- Comment #24 from Jan Hubicka ---
Reading through the PR I understand it as follows
1) we create localalias for a symbol
2) ipa-pure-const founds that the function is noreturn.
Here seems to be a bug, since it does
TREE_THIS_VOLATI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93214
Jan Hubicka changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Jan Hubicka -
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Filename length limit for ext4 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #17 from Jan Hubicka ---
I further hacked the script to record only values that are useful, where useful
means with greater count then all / TOPN_VALUES / 2. I use same test in GCC
itself (that was bug in original luxou's patch that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #15 from Jan Hubicka ---
This is frequency scaled by #of executions:
== Stats for /aux/hubicka/firefox2019-trunktest ==
stats for indirect_call:
total: 160451
invalid: 542 (0.34%) freq:276193364 (33.87%)
tracked values:
0 v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #14 from Jan Hubicka ---
> This seems reasonable well, 542/(21514+3151+866+11) = 2%.
I think one needs to consider only calls that was trained and have at least two
possible targets. With this metric it is more like 542/(3151+866+11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #12 from Jan Hubicka ---
This is stat for Firefox with current mainline.
== Stats for firefox2019-trunktest ==
stats for indirect_call:
total: 160451
invalid: 542
tracked values:
0 values: 134367 times (83.74%)
1 val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #10 from Jan Hubicka ---
-fvpt still has no effect on Firefox
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=20725e2c319ad69128f075248bc41a0e97029437&newProject=try&newRevision=8a26cb77fed6ccc67
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
While analyzing GCC for PR93404 I noticed that gen_rtx_fmt_ee
34 rtx
35 gen_rtx_fmt_ee (code, mode, arg0, arg1)
36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93404
--- Comment #1 from Jan Hubicka ---
Created attachment 47701
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47701&action=edit
inliner size stats parser
It took me a while to find some reasonable way to analyze code size regressions
caused
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
I am looking into this for a while, but lets create a tracking bug to record
some info on the problem.
-O2 code
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
We have __gcov_topn_values_profiler and __gcov_topn_values_profiler_atomic
but only no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mliska at suse dot cz
--- Comment #
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
https://gcc.gnu.org/git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93345
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
--- Comment #10 from Jan Hubicka ---
Concerning:
> Honza, the type_has_components_p check in
>
> if (compare_type_sizes (TREE_TYPE (ref2), type1) >= 0
> && (!end_struct_ref1
> || compare_type_sizes (TREE_TYPE (ref2),
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93318
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93318
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92816
--- Comment #2 from Jan Hubicka ---
It does not reproduce for me on bdver1 and also it does not seem to reproduce
at skylake (with generic tuning)
https://lnt.opensuse.org/db_default/v4/SPEC/graph?highlight_run=8405&plot.70=227.70.0
So we need t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93318
--- Comment #1 from Jan Hubicka ---
So it seems the problem is the following:
Program received signal SIGSEGV, Segmentation fault.
0x00a1ff0e in cgraph_edge::speculative_call_info (this=0x76e26bc8,
direct=@0x7fffd700: 0x90c070 <_s
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Firefox build now crashes with:
36:24.63 0x7756505f ???
36:24.63
/build/glibc-77giwP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92599
Jan Hubicka changed:
What|Removed |Added
Summary|ICE in |[8/9 regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92599
--- Comment #6 from Jan Hubicka ---
I guess the problem is that the code expect lto-stmt-uid and call_stmt to be in
sync. This is not true. If call statements are around lto stmt uids are not
maintained.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92599
--- Comment #5 from Jan Hubicka ---
I also get similar ICE building Firefox
[task 2020-01-17T20:36:04.213Z] 20:36:04 INFO -
../../gcc-source/gcc/ipa-inline-transform.c:722
[task 2020-01-17T20:36:04.213Z] 20:36:04 INFO - 0x9d8315
exec
: dmalcolm at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Bootstrapping with LTO complains about ODR issues in analyzer
../../gcc/analyzer/region-model.h:792: warning: type ‘struct region’ violates
the C++ One Definition Rule [-Wodr]
792 | class region
701 - 800 of 3474 matches
Mail list logo
