https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97389
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
at 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=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
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
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=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
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.
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
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
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
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
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=edit
testcase
Building the testc
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
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=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=edit
proposed patch
This was reported to me by Mark Williams (who also did the testcase and
proposed patch)
% g++ -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Summary|[9/10
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
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
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
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
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 devirtualized
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
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
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=edit
another related testcase
> But that means we now miscompile the later two tests.
Good point, those are my testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90869
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Jan Hubicka ---
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=edit
possible fix
After some discussion with Richard it is my understanding now that FRE is
considering two stores equal if
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
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=
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
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://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
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
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
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
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
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
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
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=20725e2c319ad69128f075248bc41a0e97029437=try=8a26cb77fed6ccc6752c6ad906a8e20767b454a1=1
while it used
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=edit
inliner size stats parser
It took me a while to find some reasonable way to analyze code size regressions
caused by
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
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=227.70.0
So we need to
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
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92077
--- Comment #4 from Jan Hubicka ---
We have --param comdat-sharing-probablity which says that average comdat
function has only 20% chance to be shared with another copy of same comdat in
other unit. This was introduced because of Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
--- Comment #5 from Jan Hubicka ---
Also I think it is violation of C++ memory model since we introduce load+store
pair where there was none before?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
Jan Hubicka changed:
What|Removed |Added
Keywords|wrong-code |
Target|i?86-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
--- Comment #2 from Jan Hubicka ---
Fails at least for gcc 4.9+, but it must be regression compared to pre-tree-ssa
GCCs (which I don't have installed :)
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
hubicka@lomikamen-jh:~$ cat t2.c
#include
union test {int a; float b;};
__attribute__ ((noinline)) union test set()
{
union test r;
r.a = 0x7f842335;
return r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91576
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92600
--- Comment #6 from Jan Hubicka ---
Well, because the source files differs, the comdat group differs and the
loosing one has fewer symbols in it. So we end up keeping some symbols from
the other comdat group that happens to have same name. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358
--- Comment #19 from Jan Hubicka ---
I think backporting would be a good idea :) If you beat me on it even better.
Now I need to set up my trees in git...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93144
--- Comment #5 from Jan Hubicka ---
Well, the problem was debug info getting bigger due to more inlining? I guss in
that case we could close it. That patch is expected to allow more inlines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92749
--- Comment #2 from Jan Hubicka ---
This is intentional, we got less aggressive at inlining inline functions for
-O2 (since we do not need to do all inlining we want for -O3 when we have
independent set of attributes).
Indeed -Winline -Werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92240
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91576
--- Comment #18 from Jan Hubicka ---
OK, other testcases does not reproduce for me. However if they do it seems like
fallout from the change dropping type checking from call statements.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91576
--- Comment #17 from Jan Hubicka ---
Created attachment 47651
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47651=edit
proposed patch
This is patch I plan to test which fixes the last testcase. It adds warning
about TREE_ADDRESSABLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91576
--- Comment #16 from Jan Hubicka ---
OK, i get an ICE because type is not compatible with its main variant. the two
types are:
constant 384>
unit-size constant 48>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
In the testcase (reduced from folly by Mark Williams):
typedef int a;
template struct d { static constexpr b e = c; };
template
701 - 800 of 3454 matches
Mail list logo
