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
Severity: normal
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
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],c[LEN_1D],d[LEN_1D],e
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],aa[LEN_2D][LEN_2D];
void main
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$0x
: normal
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],c
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,
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];
int main
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=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 and s3 benchmark |s311, s312 and s3
|o
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
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];
int main
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],c[LEN_1D],d[LEN_1D
Severity: normal
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
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 mo
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
This testcase (from TSVC) is about 4 times faster on zen3 when built with
clang.
typedef float real_t;
#define iterations 10
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 a[LEN_1D],b[LEN_1D],c[
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=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;
floa
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
s152 is:
void s152s(real_t a[LEN_1D], real_t b[LEN_1D], real_t c[LEN_1D], int i)
{
a[i] += b[i] * c[i];
}
real_t s152(struct
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
s116 loop is:
real_t s116(struct args_t * func_args)
{
//linear dependence testing
initialise_arrays(__func__
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Clang is vectorizing s254 loop with -mtune=archive on znver2 leading to about
758% speedup. Loop is:
real_t s254(struct args_t
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 cont
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=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=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
PE=Re
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: ---
Compared to clang we need significantly longer time to train Firefox (25
minutes
|NEW
CC||hubicka at gcc dot gnu.org
Last reconfirmed||2021-02-14
--- Comment #5 from Jan Hubicka ---
This looks like missed memory copy propagation to me.
We inline the icfed function back but for some reason we
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, CIF_FINAL_
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 comda
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 /lib64/
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Configuring with
../configure --disable-multilib --prefix=/home/jan/trunk-install
--with-build-config=bootstrap-lto --enable-checking=release --disable-plugin
||2021-02-08
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #3 from Jan Hubicka ---
I will check
If I recall correctly, during analysis the vector is only collected for dumps,
so that
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=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> (&D.3185); [return slot optimization]
ipa-modref: call to glm::vec bitC
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
-fprofile-reproducible=serial leads to:
jan@skylake:~> gcc -O2 -fprofile-reproducible=serial
gcc: error: unknown prof
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
|at
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=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 o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98173
Jan Hubicka changed:
What|Removed |Added
Keywords|missed-optimization |
Version|11.0
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
I got curious about overall effect of PTA.
This compares -fno-tree-pta to -ftree-pta.
There is significant regression on
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=97867
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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 41a684995b3..0dba221779
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572
Jan Hubicka changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comm
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=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
5
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 ref
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
compatible_p
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=92535
--- Comment #11 from Jan Hubicka ---
Created attachment 49582
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49582&action=edit
Memory use of GCC 10 release branch with ICF
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: 'DE
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&action=edit
Memory use of GCC trunk (11) without ICF
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&action=edit
Memory use of GCC trunk (11) with 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=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=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
Jan Hubicka changed:
What|Removed |Added
Component|middle-end |bootstrap
--- Comment #1 from Jan Hubicka
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 speculative
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
During profiledbootstrap we get the following warnings:
../libcpp/../../libcpp/mkdeps.c: In function ‘munge.constprop
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Configuring with
../configure --with-build-config=bootstrap-lto --enable-checking=release
--disable-plugin
leads to ICE building stage
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&action=edit
Warnings building cc1plus with LTO
This is current set of wranings building cc1plus with LTO. there are 66
maybe-
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
For a while we get odd looking locations:
D.5677.coeffs[0]’../../gcc/calls.c: In function ‘expand_call’:
../../gcc/dojump.c:118:28
: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
stub-objc provides dummy RID enum which causes ODR violation.
This produces warnings with lto-bootstrap:
../../gcc/c-family/c-common.h:63: warning: type ‘rid’ violates the C
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=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=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 t
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 (def_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 f
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 becom
||2020-11-15
Status|UNCONFIRMED |NEW
CC||hubicka at gcc dot gnu.org
--- Comment #1 from Jan Hubicka ---
Confirmed. Reproduces on aarch64 cross for me, not on x86-64 native.
Warning is on:
#1 0x01343ad5 in
||hubicka at gcc dot gnu.org
--- Comment #3 from Jan Hubicka ---
Confirmed.
The wrong code happens already in fre1 where we do:
main ()
{
int f;
int * _1;
:
_1 = d (&f);
__builtin_abort ();
}
Modref summary for d is:
loads:
Limits: 32 bases, 16 refs
Ba
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
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
The follwing testcase reduced from ssd/t2.c
#include
void dump (void *p, unsigned int len)
{
const char digits[17] = "0123456789abcdef";
unsigned char *a = (unsigne
|1
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Jan Hubicka ---
That value is sizeof(double)*8.
I tpicked double since we have builtin that writes it assumed it is
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #1 from Jan Hubicka ---
indeed this is obviously garbage collected that is weird because all things
should be reachable via the modref summary (where THIS pointer is taken). I
will try cross.
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=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 bi
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Compiling:
test (int *a, int size)
{
__builtin_memset (a, 0, size);
}
gets:
Jump functions:
Jump functions of caller __builtin_memset
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=97593
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=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
Jan Hubicka changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 f
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=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 +10,
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.
601 - 700 of 3467 matches
Mail list logo
