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=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=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
Pr
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
Pr
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
Pr
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
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=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=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
Pr
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
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
Seve
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
Pr
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
|o
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
Pr
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: n
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
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
Prio
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
Prio
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
Severi
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=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, 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, s2233, s275 and s233 |s235, s2233, s275, s2275
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
P
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
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99638
Jan Hubicka changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
Summ
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
Priorit
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
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=99751
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
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...
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=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
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
abstra
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 #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 #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
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #20 from Jan Hubicka
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=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=98265
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=100010
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
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=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=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=92394
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97389
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97389
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=97403
Bug ID: 97403
Summary: Ancestor jump function should be generalized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ip
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
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 #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 #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=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=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=97445
Jan Hubicka changed:
What|Removed |Added
Component|c |ipa
--- Comment #48 from Jan Hubicka ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97519
Bug ID: 97519
Summary: builtin_constant_p (x + cst) should be optimized to
builtin_constant_p (x)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: no
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
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=97578
Jan Hubicka changed:
What|Removed |Added
CC||jakub at redhat dot com,
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=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=97652
Bug ID: 97652
Summary: New pdt14 failure after
g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97672
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Sta
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=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=97698
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=97593
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=97735
Bug ID: 97735
Summary: ipa-prop should handle simple casts
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
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
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=97757
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97766
Jan Hubicka changed:
What|Removed |Added
Last reconfirmed||2020-11-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97775
Bug ID: 97775
Summary: Wrong code with bitfield
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
A
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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
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 #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
--- 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=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=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=97854
Bug ID: 97854
Summary: [11 regression] ODR violation in stub-objc.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97855
Bug ID: 97855
Summary: [11 regression] Bogus warning locations during
lto-bootstrap
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
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-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
Bug ID: 97857
Summary: profiledbootstrap broken freeing speculative call
summary
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
Bug ID: 97858
Summary: [11 regression] Bogus warnings about va_list during
profiledbootstrap
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
1 - 100 of 847 matches
Mail list logo
