https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97508
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-10-21
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #28 from Christophe Leroy ---
Looks like we have a way to do it. Works at least with GCC 5.5, 8.2, 9.2, 10.1
unsigned long g(unsigned long a, unsigned long b)
{
unsigned long long s = (unsigned long long)a + (unsigned long lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97506
--- Comment #3 from Richard Biener ---
Targets shouldn't ICE on unsimplified stuff - the testcase explicitely disables
constant propagation so I guess we get what was asked for.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #36 from Paul Thomas ---
Created attachment 49412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49412&action=edit
An updated patch
The patch has been evolving... slowly.
I found that dependency_57.f90 segfaulted in runtime so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #3 from Jim Wilson ---
The basic idea here is that the movqi pattern in riscv.md currently emits RTL
for a load that looks like this
(set (reg:QI target) (mem:QI (address)))
As an experiment, we want to try changing that to somethin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97502
Andreas Krebbel changed:
What|Removed |Added
Last reconfirmed||2020-10-21
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #47 from Christophe Leroy ---
(In reply to Segher Boessenkool from comment #46)
> (In reply to Christophe Leroy from comment #43)
> > int g(int x)
> > {
> > return __builtin_clz(0);
> > }
> >
> > Gives
> >
> > 0018 :
> > 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97506
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
jiawei changed:
What|Removed |Added
CC||jiawei at iscas dot ac.cn
--- Comment #2 from j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66706
Bug 66706 depends on bug 66552, which changed state.
Bug 66552 Summary: Missed optimization when shift amount is result of signed
modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
--- Comment #18 from CVS Commits ---
The releases/gcc-10 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:574ab3c85bb393e0ed0171b96eb42e0dd1e91de4
commit r10-8927-g574ab3c85bb393e0ed0171b96eb42e0dd1e91de4
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
--- Comment #12 from Sergei Trofimovich ---
Aha, makes sense.
My hack did not survive bootstrap anyway as libgcc.a started referring
pthread_once() as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97505
--- Comment #3 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:292c92715b282f7c6617c94351d3e38ec027d637
commit r11-4141-g292c92715b282f7c6617c94351d3e38ec027d637
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #46 from Segher Boessenkool ---
(In reply to Christophe Leroy from comment #43)
> int g(int x)
> {
> return __builtin_clz(0);
> }
>
> Gives
>
> 0018 :
> 18: 38 60 00 20 li r3,32
> 1c: 4e 80 00 20 blr
That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97508
Bug ID: 97508
Summary: lto1: internal compiler error: decompressed stream:
Destination buffer is too small
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #35 from Segher Boessenkool ---
Send it to gcc-patches@ please, with explanation and everything?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97507
Bug ID: 97507
Summary: Move __gcov_exit from per-object .fini_array.00100 to
libgcov
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #27 from Joakim Tjernlund ---
It has been 10 years, it is not that hard :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #26 from Segher Boessenkool ---
It isn't easy to do. Feel free to try your hand at it :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97506
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-10-20
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
Christophe Leroy changed:
What|Removed |Added
CC||christophe.leroy at csgroup
dot eu
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97505
--- Comment #2 from Aldy Hernandez ---
Created attachment 49411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49411&action=edit
proposed patch
We should disable the assert while this PR is fixed, so it doesn't hold anyone
else up.
Patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97505
--- Comment #1 from Aldy Hernandez ---
We are calculating ranges for the following:
(gdb) dd stmt
_18 = .UBSAN_CHECK_SUB (_58, _57);
which gets turned into a MINUS_EXPR. Then we call
extract_range_from_binary_expr on the MINUS_EXPR:
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #9 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #7)
> So, can we use this for anything but modulo 3, or 5, or 17, or 257 (all of
> those have 2^32 mod N == 2^64 mod N == 2^128 mod N == 1)
I think so, too.
> probabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97506
Bug ID: 97506
Summary: [11 Regression] ICE: in extract_insn, at recog.c:2294
(unrecognizable insn) with -mavx512vbmi -mavx512vl
Product: gcc
Version: 11.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97505
Martin Liška changed:
What|Removed |Added
Known to work||10.2.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97505
Bug ID: 97505
Summary: [11 Regression] ICE in extract_range_basic, at
vr-values.c:1439 since
r11-4130-g16e4f1ad44e3c00b8b73c9e4ade3d236ea7044a8
Product: gcc
Versi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #45 from Jakub Jelinek ---
> > __attribute__ ((noinline))
> > int
> > my_fls64 (__u64 x)
> > {
> > asm volatile ("movl $-1, %eax");
> > return (__builtin_clzll (x) ^ 63) + 1;
> > }
>
> Aha, bsr is not doing anything if parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
--- Comment #1 from Jakub Jelinek ---
Created attachment 49409
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49409&action=edit
gcc11-pr97503.patch
While that is something that can and often is done during ifcvt, I think for
various archit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #34 from Peter Bergner ---
(In reply to Peter Bergner from comment #32)
> (In reply to Richard Biener from comment #31)
> > > > Is this really the correct fix?
> >
> > Yes.
>
> Just to verify, this is an approval for Andrew's patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97501
--- Comment #5 from Andrew Macleod ---
Just to further annotate why this is the correct fix for posterity..
evrp/vrp calls adjust_range_with_scev:
/* Start with the input range... */
tree vrmin = vr->min ();
tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90629
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
--- Comment #1 from Andreas Schwab ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556477.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97501
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97501
--- Comment #3 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:5d53ec27015b916640171e891870adf2c6fdfd4c
commit r11-4129-g5d53ec27015b916640171e891870adf2c6fdfd4c
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
Bug ID: 97504
Summary: [11 regress] Ada bootstrap error after r11-4029
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97471
Nathan Sidwell changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
--- Comment #8 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to andysem from comment #2)
> > (In reply to Jonathan Wakely from comment #1)
> > > You can use a #pragma to disable -Wdeprecated locally
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
Bug ID: 97503
Summary: Suboptimal use of cntlzw and cntlzd
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #33 from rguenther at suse dot de ---
On October 20, 2020 4:16:37 PM GMT+02:00, "bergner at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>
>--- Comment #32 from Peter Bergner ---
>(In reply to Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82239
--- Comment #2 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:953277ba3fa39a9285cf89f59932b0169e7f6b9d
commit r11-4126-g953277ba3fa39a9285cf89f59932b0169e7f6b9d
Author: Marek Polacek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82239
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
--- Comment #7 from Jonathan Wakely ---
(In reply to andysem from comment #4)
> I just think that all these hoops could be avoided if libstdc++ was a little
> more friendly in this regard. After all, there's no harm in using e.g.
> auto_ptr in C+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #44 from Jakub Jelinek ---
Then perhaps some backends need to be improved.
Try e.g.:
void bar (void);
void
foo (int x)
{
if (__builtin_clz (x) == 32)
bar ();
}
with trunk GCC if you don't trust me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-10-20
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #43 from Christophe Leroy ---
(In reply to Christophe Leroy from comment #42)
> (In reply to Jakub Jelinek from comment #41)
> > It is documented to be undefined:
> > -- Built-in Function: int __builtin_clz (unsigned int x)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #42 from Christophe Leroy ---
(In reply to Jakub Jelinek from comment #41)
> It is documented to be undefined:
> -- Built-in Function: int __builtin_clz (unsigned int x)
> Returns the number of leading 0-bits in X, starting at t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #41 from Jakub Jelinek ---
It is documented to be undefined:
-- Built-in Function: int __builtin_clz (unsigned int x)
Returns the number of leading 0-bits in X, starting at the most
significant bit position. If X is 0, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #32 from Peter Bergner ---
(In reply to Richard Biener from comment #31)
> (In reply to Andrew Macleod from comment #30)
> > On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=973
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97502
--- Comment #6 from Jakub Jelinek ---
With
--- gcc/config/s390/vx-builtins.md.jj 2020-04-30 09:26:01.0 +0200
+++ gcc/config/s390/vx-builtins.md 2020-10-20 16:08:31.847698827 +0200
@@ -812,6 +812,16 @@
DONE;
})
+(define_expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82239
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97502
--- Comment #5 from Jakub Jelinek ---
The vector comparison optabs are:
OPTAB_CD(vec_cmp_optab, "vec_cmp$a$b")
OPTAB_CD(vec_cmpu_optab, "vec_cmpu$a$b")
OPTAB_CD(vec_cmpeq_optab, "vec_cmpeq$a$b")
therefore they need two modes in their names - the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97502
--- Comment #4 from Richard Biener ---
Or rather, it doesn't make sense to not have vec_cmp[u]{,eq} optabs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97502
Richard Biener changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97502
--- Comment #2 from Richard Biener ---
So the following is problematic:
vector(16) _12;
vector(16) _14;
vector(16) _32;
_14 = vect__1.7_3 != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
_12 = vect__2.10_15 == { 0, 0, 0, 0, 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #40 from Christophe Leroy ---
(In reply to Jakub Jelinek from comment #39)
> (In reply to Christophe Leroy from comment #38)
> > But on powerpc that's already the case and it doesn't solve the issue.
> >
> > static inline int fls(uns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97010
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97010
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:257bbf154cd2b83eb02c99db73537e3b8ba3a6e7
commit r10-8915-g257bbf154cd2b83eb02c99db73537e3b8ba3a6e7
Author: Marek Polacek
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97501
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #39 from Jakub Jelinek ---
(In reply to Christophe Leroy from comment #38)
> But on powerpc that's already the case and it doesn't solve the issue.
>
> static inline int fls(unsigned int x)
> {
> return 32 - __builtin_clz(x);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #38 from Christophe Leroy ---
(In reply to Jan Hubicka from comment #32)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
> >
> > --- Comment #31 from Segher Boessenkool ---
> > (In reply to Jan Hubicka from comment #27)
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323
--- Comment #7 from Matthias Klose ---
commit 872d5034baa1007606d405e37937908602fbbe51
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96129
--- Comment #4 from Kewen Lin ---
As the regressed failures, it's highly suspected to be duplicated of PR96376.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323
--- Comment #6 from Matthias Klose ---
this is triggered by:
2015-05-19 Jan Hubicka
* tree.c (verify_type_variant): Fix #undef.
(gimple_canonical_types_compatible_p): Move here from lto.c
(verify_type): Verify TYPE_CANON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97502
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #37 from Jan Hubicka ---
Hi,
this implements the heuristics increasing bounds for functions having
__builtin_constant_p on parameters. Note that for get_order this is
still not enough, since we increase the bound twice if hint applie
Hi,
this implements the heuristics increasing bounds for functions having
__builtin_constant_p on parameters. Note that for get_order this is
still not enough, since we increase the bound twice if hint applies, so
it goes from 70 to 140 and not to 190 needed, however it will handle
ohter similar c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97501
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-10-20
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97502
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97502
Bug ID: 97502
Summary: [11 Regression] PGO bootstrap failure on s390x-linux
with -march=z13 starting with r11-3426
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97493
suochenyao at 163 dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97493
--- Comment #4 from suochenyao at 163 dot com ---
I made mistake, Jelinek is right.
This testcase is invalid and I can not reproduce it as well.
Sorry for wasting your time, my fault.
I apologize for wasting you time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97501
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
--- Comment #6 from Andreas Krebbel ---
Alternatively I could also mark r12 as preserved across function calls for
-fpic in the backend. In fact all the bits we care about are preserved. Since
the register is fixed all the accesses do come from t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96129
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> Quite some revs, two vectorizer changes. Do the FAILs still occur?
Both still do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #36 from Jan Hubicka ---
> Find attached the temporary files for net/core/skbuff.c, as it is indeed what
> initially triggered my focus on this issue. I don't expect such a function at
> all:
>
> 0cc8 :
> cc8: 48 00 00
>
> Original asm is:
>
> __attribute__ ((noinline))
> int fls64(__u64 x)
> {
> int bitpos = -1;
> asm("bsrq %1,%q0"
> : "+r" (bitpos)
> : "rm" (x));
> return bitpos + 1;
> }
>
> There seems to be bug in bsr{q} pattern. I can make GCC produce same
> code with:
>
> __attribute__ ((n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #35 from Jan Hubicka ---
>
> Original asm is:
>
> __attribute__ ((noinline))
> int fls64(__u64 x)
> {
> int bitpos = -1;
> asm("bsrq %1,%q0"
> : "+r" (bitpos)
> : "rm" (x));
> return bitpos + 1;
> }
>
> There seems to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #34 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #33 from Jakub Jelinek ---
> (In reply to Jan Hubicka from comment #32)
> > get_order is a wrapper around ffs64. This can be implemented
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #33 from Jakub Jelinek ---
> (In reply to Jan Hubicka from comment #32)
> > get_order is a wrapper around ffs64. This can be implemented w/o asm
> > statement as follows:
> > int
> > my_fls64 (__u64 x)
> > {
> > if (!x)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #33 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #32)
> get_order is a wrapper around ffs64. This can be implemented w/o asm
> statement as follows:
> int
> my_fls64 (__u64 x)
> {
> if (!x)
> return 0;
> ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:94fd05f1f76faca9dc9033b55d44c960155d38e9
commit r11-4120-g94fd05f1f76faca9dc9033b55d44c960155d38e9
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
--- Comment #5 from rsandifo at gcc dot gnu.org
---
I think the problem is a disconnect between compute_transp
and the code in gcse.c itself. compute_transp considers %r12
to be transparent in all blocks despite the partial clobbers.
But whethe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #32 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #31 from Segher Boessenkool ---
> (In reply to Jan Hubicka from comment #27)
> > It is because --param inline-insns-single was reduced for
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
>
> --- Comment #31 from Segher Boessenkool ---
> (In reply to Jan Hubicka from comment #27)
> > It is because --param inline-insns-single was reduced for -O2 from 200
> > to 70. GCC 10 has newly different set of parameters for -O2 and -O3 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95917
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97414
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #4 from Martin Liška
efix=/data/mwindsor/old_compilers/gcc-snapshots/2020-10-20
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201020 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O2' '-v' '-save-temps' '-mtune=generic' '-march=x86-64'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #31 from Segher Boessenkool ---
(In reply to Jan Hubicka from comment #27)
> It is because --param inline-insns-single was reduced for -O2 from 200
> to 70. GCC 10 has newly different set of parameters for -O2 and -O3 and
> enables a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97500
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
--- Comment #11 from Jonathan Wakely ---
It's not plausible because it doesn't work for non-pthreads targets where
gthr-default.h is not gthr-posix.h
We can't use pthread_once anyway, see PR 66146, so I'm rewriting it entirely in
terms of either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97487
Jakub Jelinek changed:
What|Removed |Added
Keywords|openmp |
Summary|[10/11 Regression] I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97366
--- Comment #6 from Hongtao.liu ---
(In reply to Alexander Monakov from comment #5)
> afaict LRA is just following IRA decisions, and IRA allocates that pseudo to
> memory due to costs.
>
> Not sure where strange cost is coming from, but it depe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394
--- Comment #10 from Sergei Trofimovich ---
How about something as simple as:
--- a/libgcc/gthr-posix.h
+++ b/libgcc/gthr-posix.h
@@ -697,7 +697,12 @@ static inline int
__gthread_once (__gthread_once_t *__once, void (*__func) (void))
{
if (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97478
--- Comment #4 from Jakub Jelinek ---
Well, it looks like glibc might be reverting that change:
https://sourceware.org/pipermail/libc-alpha/2020-October/118791.html
Apparently that removal also breaks SPEC2k6 and SPEC2017.
So let's wait and see.
1 - 100 of 108 matches
Mail list logo
