https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103211
--- Comment #5 from Jan Hubicka ---
There is wrong change in my patch (I mixed up this_looping variable for
looping)
diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index b831844afa6..5056850c0a8 100644
--- a/gcc/ipa-pure-const.c
+++ b/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103175
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103209
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=103200
--- Comment #3 from Jan Hubicka ---
Sorry, I managed to include last minute change that was wrong. Currently
modref does not track if function is deterministic so we can not detect looping
pure/consts. I am testing.
diff --git a/gcc/ipa-modref
Version: 12.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: ---
This is seen at LTN here
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103189
--- Comment #1 from Jan Hubicka ---
I wonder if you can attach .optimized dumps of valid revision and broken one.
It may be related to modref/PTA changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103182
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103168
--- Comment #1 from Jan Hubicka ---
Sorry the testcase should have pure in it
__attribute__((pure)) int test();
int
main()
{
int ret;
int a[10];
for (int i=0; i<10;i++)
if (test())
a[i]++;
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
In the following testcase the call to test is loop invariant because memory
modified is not escaping. While value numbering of pure functions we however
add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97403
--- Comment #2 from Jan Hubicka ---
Martin,
I think we can close this (possibly adding the testcase)
: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Compiling tramp3d with -Ofast -fwhole-program -fipa-pta I get:
Alias oracle query stats:
refs_may_alias_p: 3820161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Jan Hubicka changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103142
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103117
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98925
Jan Hubicka changed:
What|Removed |Added
Summary|Extend modref to handle |Extend ipa-prop to handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103055
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #25 from Jan Hubicka ---
LNT sees new regresion on WRF build times (around 6%) at Nov 3
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=287.548.8
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=289.270.8
The revis
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
For the following
struct a {int v; struct a *next;};
struct a*
next(struct a *a)
{
if (!a || a->v)
return 0;
return a->next;
}
(we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103070
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035
Bug 103035 depends on bug 103073, which changed state.
Bug 103073 Summary: [12 Regression] ICE in insert_access, at
ipa-modref-tree.h:578 since r12-4401-gfecd145359fc981b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
What|R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 103082, which changed state.
Bug 103082 Summary: [12 Regression] gcc/poly-int.h:1162:5: runtime error: left
shift of negative value -40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103082
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103082
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058
--- Comment #12 from Jan Hubicka ---
So the problem in this case really isn't fortran bug, but somewhat weird
iteraction between visibility predicates. In particular we make
binds_to_current_def to return false if symbol can be discarded and
ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083
--- Comment #3 from Jan Hubicka ---
Just for the record, the problem is the ancestor jump function being used to
model two things - pointer plus which originates from ADDR_EXPR of component
reference and also C++ casts which checks whether param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86389
--- Comment #12 from Jan Hubicka ---
Since the vector_subscript testcase seems indeed to be frontend issue triggered
by -fipa-pta (and soon by modref). I wonder if we should have fortran bug
tracking this or change component here?
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Building testcase with:
/aux/hubicka/trunk/build5/gcc/testsuite/gfortran2/../../gfortran
-B/aux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
Jan Hubicka changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103070
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103058
Jan Hubicka changed:
What|Removed |Added
Component|ipa |fortran
--- Comment #6 from Jan Hubicka
|ASSIGNED
Last reconfirmed||2021-11-04
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #1 from Jan Hubicka ---
The compuation is supposed to be working for negative values. Later we add the
bitoffset which can
y: 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: ---
struct b {int b;};
struct a {int a; struct b b;};
long i;
__attribute__ ((noinline))
static void test2 (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #9 from Jan Hubicka ---
mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103050
--- Comment #1 from Jan Hubicka ---
Martin,
do we know that the retslot change is the bad commit? I proofread the patch
and did not see anything obviously wrong, however as seen in PR103040 the
previous behaviour that made return slots to escap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103040
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #7 from Jan Hubicka ---
this is compile time plot
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=227.270.8
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=289.270.8
(-O2 and -Ofast with lto)
Things has improved but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102058
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
6fca1761a16c68740f875fc487b98b6bde8e9be7 on Zen
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908
--- Comment #6 from Jan Hubicka ---
zen
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=198.639.0&plot.1=180.639.0&plot.2=201.639.0&plot.3=150.639.0&plot.4=246.639.0&plot.5=256.639.0&plot.6=176.639.0&;
kabylake
https://lnt.opensuse.org/d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908
Jan Hubicka changed:
What|Removed |Added
Summary|cray regression with -O2|[12 regression] cray
|-
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
https://lnt.opensuse.org/db_default/v4/SPEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102947
--- Comment #1 from Jan Hubicka ---
It seems enough to lookat the WRP benchmark build time.
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=322.270.8&plot.1=307.270.8&plot.2=343.270.8&plot.3=266.270.8&plot.4=395.270.8&plot.5=412.270.8&p
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
This is seen in
https://lnt.opensuse.org/db_default/v4/SPEC/graph
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 updat
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 = malloc
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, vars
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 #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)\
__attribute__((noinline
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
++
threading)
Product: gcc
Version: 12.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/bugzilla/show_bug.cgi?id=102310
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #5 fro
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=101296
--- Comment #8 from Jan Hubicka ---
so smarter merging in modref is now implemented ;)
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=102581
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=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=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=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 so
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?younger_in_days=14&older_in_days=0&all_ch
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?younger_in_days=14&older_in_da
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
This should be easy to track since cray is stupid benchmark.
According to run
https://lnt.opensuse.org/db_default/v4/CPP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92740
Jan Hubicka changed:
What|Removed |Added
Summary|induct2 (from polyhedron) |induct2 (from polyhedron)
at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Last reconfirmed||2021-06-30
Ever confirmed|0 |1
--- Comment #1 from Jan Hubicka ---
mine.
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=100483
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
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=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 fr
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]
at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #2 from Jan Hubicka ---
mine.
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=98265
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
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=99447
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #20 from Jan Hubicka
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&action=edit
small refactoring
this patch moves the removal to release_body and removes the calls on those
paths where remova
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 bo
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 a
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
abstra
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=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 100
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 bef
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...
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #7 from Jan Hubicka ---
mine.
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 re
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 inliner
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
typedef float real_t;
#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
real_t a[LEN_1D],b[LEN_1D],aa[LEN_2D][LEN_2D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99638
Jan Hubicka changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
Summ
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
typedef float real_t;
#define iterations 100
#define LEN_1D 32000
#define LEN_2D 256
// array definitions
real_t flat_2d_array[LEN_2D*LEN_2D];
real_t x
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
typedef float real_t;
#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
// array definitions
real_t
a[LEN_2D],d
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, s2233 and s233|s235, s2233, s275 and s233
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
|TS
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
501 - 600 of 3465 matches
Mail list logo
