https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
Jan Hubicka changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #27 from Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99751
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
--- Comment #15 from Jan Hubicka ---
I also tried to reproduce this locally w/o luck.
Looking at the backtrace in detail, there is no DEF_STMT involved. It walks
from dwarf dies, to RTL constant pool address that points to tree which has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99646
Bug ID: 99646
Summary: s111 benchmark of TSVC preffers -mprefer-avx128 on
zen3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99638
Jan Hubicka changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99638
Bug ID: 99638
Summary: s132 benchmarks of TSVC on zen3 benefits from -mno-fma
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99414
Jan Hubicka changed:
What|Removed |Added
Summary|s235 and s233 benchmarks of |s235, s2233 and s233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99414
Jan Hubicka changed:
What|Removed |Added
Summary|s235, s2233 and s233|s235, s2233, s275 and s233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99633
Bug ID: 99633
Summary: s1113 benchmark of TSVC is unrolled by icc and not by
gcc and runs faster on znver3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99414
Jan Hubicka changed:
What|Removed |Added
Summary|s235, s2233, s275 and s233 |s235, s2233, s275, s2275
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99414
Jan Hubicka changed:
What|Removed |Added
Summary|s235 benchmark of TSVC is |s235 and s233 benchmarks of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99634
Bug ID: 99634
Summary: s2102 benchmarks of TSVC is vectorized better by icc
than gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #24 from Jan Hubicka ---
I do not think there is problem with pdom for cyclic WRT acyclic paths. Both
notions are equivalent here.
If you have instruction I in, say, header of a loop and you determine it live
then the condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
Bug ID: 99395
Summary: s116 benchmark of TSVC is vectorized by clang and not
by gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99394
--- Comment #1 from Jan Hubicka ---
Here we fail with:
tsvc.c:1526:27: note: vect_is_simple_use: operand x_30 = PHI <_2(8),
x_18(3)>, type of def: unknown
tsvc.c:1526:27: missed: Unsupported pattern.
tsvc.c:1527:26: missed: not vectorized:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99397
Bug ID: 99397
Summary: s152 benchmark of TSVC is vectorized by clang and not
by gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99394
Bug ID: 99394
Summary: s254 benchmark of TSVC is vectorized by clang and not
by gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #1 from Jan Hubicka ---
Loop is:
real_t s116 (struct args_t * func_args)
{
int i;
int nl;
static const char __func__[5] = "s116";
struct timeval * _1;
int _2;
float _3;
float _4;
float _5;
int _6;
float _7;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99394
--- Comment #3 from Jan Hubicka ---
testcase is:
typedef float real_t;
#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
// array definitions
real_t flat_2d_array[LEN_2D*LEN_2D];
real_t x[LEN_1D];
real_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407
Bug ID: 99407
Summary: s243 benchmark of TSVC is vectorized by clang and not
by gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407
--- Comment #1 from Jan Hubicka ---
Here we get:
s243.c:27:18: missed: not vectorized, possible dependence between data-refs
a[i_29] and a[_9]
s243.c:26:27: missed: bad data dependence.
s243.c:26:27: note: * Analysis failed with vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99408
Bug ID: 99408
Summary: s3251 benchmark of TSVC vectorized by clang runs about
7 times faster compared to gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99409
Bug ID: 99409
Summary: s252 benchmark of TSVC is vectorized by clang and not
by gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99411
Bug ID: 99411
Summary: s311 benchmark of TSVC is vectorized by clang better
than by gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99411
Jan Hubicka changed:
What|Removed |Added
Summary|s311 benchmark of TSVC is |s311 and s3 benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99411
Jan Hubicka changed:
What|Removed |Added
Summary|s311 and s3 benchmark |s311, s312 and s3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99411
Jan Hubicka changed:
What|Removed |Added
Summary|s311, s312 and s3 |s311, s312, s3 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99411
Jan Hubicka changed:
What|Removed |Added
Summary|s311, s312, s3 and |s311, s312, s3 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99412
Bug ID: 99412
Summary: s352 benchmark of TSVC is vectorized by clang and not
by gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99411
Jan Hubicka changed:
What|Removed |Added
Summary|s311, s312, s3 and |s311, s312, s3, s3,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99414
Bug ID: 99414
Summary: s235 benchmark of TSVC is vectorized better by icc
than gcc (loop interchange)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #3 from Jan Hubicka ---
ICC version seems to run faster
0040a050 :
40a050: 55 push %rbp
40a051: 48 89 e5mov%rsp,%rbp
40a054: 48 83 e4 e0 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99415
Bug ID: 99415
Summary: s115 benchmark of TSVC is vectorized by icc and not by
gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99416
Bug ID: 99416
Summary: s211 benchmark of TSVC is vectorized by icc and not by
gcc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99857
--- Comment #6 from Jan Hubicka ---
Thanks for a testcase, it makes things easier to debug indeed :)
The problem is that openmp uses declare_vairant_alt on symbols to make them
special definitions, but the definition flag is not set. That makes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309
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
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|NEW
Summary|[10/11 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80726
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265
Jan Hubicka changed:
What|Removed |Added
CC||cuzdav at gmail dot com
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100010
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92394
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #15 from Jan Hubicka ---
GCC10 testing time is:
Testing Time: 656.80s
Unsupported : 104
Passed : 21273
Expectedly Failed:26
I will see tomorrow if I can get GCC11 testing to finish.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
Jan Hubicka changed:
What|Removed |Added
Summary|profile streaming scales|[11 regression] profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #17 from Jan Hubicka ---
I am testing
diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
index e32e69cd3ad..612880240dc 100644
--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -3137,11 +3137,18 @@ compute_fn_summary (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
--- Comment #1 from Jan Hubicka ---
Also linker used is gold which may be a problem since:
So the problem ssems to be wrong call to strcmp:
Program received signal SIGSEGV, Segmentation fault.
0x77886372 in __strcmp_avx2 () from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265
--- Comment #5 from Jan Hubicka ---
We do not inline CwiseNullaryOp because it uses comdat local symbols.
This is because we do split the function and the .part stays local.
At least we should recompute if function calls comdat local after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265
--- Comment #6 from Jan Hubicka ---
I am testing
diff --git a/gcc/cif-code.def b/gcc/cif-code.def
index 2f430cf1c39..39b89da155f 100644
--- a/gcc/cif-code.def
+++ b/gcc/cif-code.def
@@ -125,7 +125,7 @@ DEFCIFCODE(OPTIMIZATION_MISMATCH,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96252
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
Bug ID: 99097
Summary: profiledbootstrap fails with LTO and disabled plugin
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
Bug ID: 99105
Summary: profile streaming scales poorly to projects with many
source files
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #1 from Jan Hubicka ---
I use following:
cmake -G 'Unix Makefiles' /home/jan/llvm-project/llvm
-DCLANG_TABLEGEN=/home/jan/llmm-build2-lto-fdo/stage1/bin/clang-tblgen
-DCMAKE_AR=/home/jan/trunk-instal/bin/gcc-ar -DCMAKE_BUILD_TY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296
--- Comment #7 from Jan Hubicka ---
"every access" means that we no longer track individual bases+offsets+sizes and
everything matching the base/ref alias set will be considered conflicting.
I planned to implement smarter merging of accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101257
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97565
--- Comment #6 from Jan Hubicka ---
has_gimple_body_p really cares about the WPA unit (we should probably note that
in the comment). Here you seem to have function that is in the WPA translation
unit but lands in different partition and in that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908
Bug ID: 101908
Summary: cray regression with -O2 -ftree-slp-vectorize compared
to -O2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92740
Jan Hubicka changed:
What|Removed |Added
Summary|induct2 (from polyhedron) |induct2 (from polyhedron)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101909
Bug ID: 101909
Summary: 73% regression on tfft benchmark for -O2
-ftree-loop-vectorize compared to -O2 on zen hardware
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101910
Bug ID: 101910
Summary: tsvc regressions for -O2 -ftree-loop-vectorize at zen
hardware
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102687
--- Comment #1 from Jan Hubicka ---
Sorry, I accidentally commited an unrelated change I had in my tree.
I am testing
diff --git a/gcc/ipa-modref-tree.h b/gcc/ipa-modref-tree.h
index 52f225b1aae..9795e2b8405 100644
--- a/gcc/ipa-modref-tree.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720
--- Comment #7 from Jan Hubicka ---
simplified testcase is:
typedef unsigned char uint8_t;
typedef __SIZE_TYPE__ size_t;
extern void* malloc (size_t);
extern void* memset (void*, int, size_t);
#define test(T, U)\
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720
--- Comment #11 from Jan Hubicka ---
Aha, the problem is in the way I updated computing use/clobber sets. I
accidentally disabled code that copies the solution from solver local
representation into the final form. As a result we failed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102646
Bug ID: 102646
Summary: large performance changes between
1932e1169a236849f5e7f1cd386da100d9af470f and
9cfb95f9b92326e86e99b50350ebf04fa9cd2477 (probably
jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102557
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720
--- Comment #8 from Jan Hubicka ---
so it is really pt_solutions_intersect in ref_maybe_used_by_call returning
false.
We get:
(gdb) p *pt1
$6 = {anything = 0, nonlocal = 1, escaped = 1, ipa_escaped = 0, null = 0,
vars_contains_nonlocal = 0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720
--- Comment #10 from Jan Hubicka ---
copied ealias dump rather than alis dump in previous comment.
alias dump is
int main ()
{
void * p;
long unsigned int _1;
[local count: 1073741824]:
# PT = null { D.2014 }
# ALIGN = 8, MISALIGN =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720
--- Comment #9 from Jan Hubicka ---
OK, with -alias dump we have:
int main ()
{
uint8_t * q;
void * p;
long unsigned int _2;
:
# PT = null { D.2008 }
# ALIGN = 8, MISALIGN = 0
# USE = anything
# CLB = anything
p_5 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474
--- Comment #3 from Jan Hubicka ---
may be dup of PR102581 (where I attached fix I am testing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102557
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296
--- Comment #8 from Jan Hubicka ---
so smarter merging in modref is now implemented ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102310
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102081
Jan Hubicka changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #5 from Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102079
--- Comment #3 from Jan Hubicka ---
I think the problem here is that fortran uses "long int" while size_t
interoperate with "unsigned long int".
Does fortran standard promise that the value should inter-operate with size_t
as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103584
--- Comment #1 from Jan Hubicka ---
This is (probably bit preliminary) optimization in tree-ssa-structalias.c:
/* Create constraints for the builtin call T. Return true if the call
was handled, otherwise false. */
static bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
Bug ID: 103585
Summary: fatigue2 requires inlining of peridida to work well
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103585
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103592
Bug ID: 103592
Summary: fatigue2 benchmarks on zen runs 43% faster with
-fno-tree-vectorize -fno-tree-slp-vectorize
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103766
--- Comment #6 from Jan Hubicka ---
This is yet another stupid early exit in the propagation code (next stage1 i
guess I will want to go through them and make it more systematic - those
originate from quite early versions of modref when it was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103669
--- Comment #2 from Jan Hubicka ---
Created attachment 52030
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52030=edit
Patch in testing
The problem here is a mixup with do_dataflow flag which prevents the name from
being analyzed. I am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103766
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103766
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=103669
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88602
--- Comment #3 from Jan Hubicka ---
In addition to Skia, Firefox gfx library now contains more clang specific
vector code:
gfx/wr/swgl/src/vector_type.h
control vector implementation of some shader rountines (seen in the
rasterflood-gradient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from Jan Hubicka ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103903
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 103903, which changed state.
Bug 103903 Summary: Loops handling r,g,b values are not vectorized to use power
of 2 vectors even if they can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103903
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797
--- Comment #11 from Jan Hubicka ---
Aha, I did not noticed that we need special patterns (I extecpted this is
problem to solve in machine independent code). So I guess we have
1) SLP should vectorize the 3 accesses with -ffast-math to only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797
Bug ID: 103797
Summary: Clang vectorized LightPixel while GCC does not
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Jan Hubicka changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103168
--- Comment #13 from Jan Hubicka ---
Concerning comment #10, the problem was that the loop walking all accesses was
missing loads->every_base check. This is used to represent that we track no
useful info about loads performed at all.
Anyway
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103369
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97783
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103264
--- Comment #2 from Jan Hubicka ---
OK, the test wants to verify that main() became single basic block that has
correct frequency. This is still true. What we get wrong is that the function
t() gets mismatches:
int t ()
{
int i;
int _7;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93358
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 93358, which changed state.
Bug 93358 Summary: [10/11/12 Regression] 447.dealII regresses by 15% after
r10-6025-gf5b25e15165adde1356af42e9066ab75c5b37a19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93358
101 - 200 of 698 matches
Mail list logo
