https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97496
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97496
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:a335f6f4ee5cb4f7dbfef52e17bf854ae42c1216
commit r11-4084-ga335f6f4ee5cb4f7dbfef52e17bf854ae42c1216
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #28 from Christophe Leroy ---
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 00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #29 from Christophe Leroy ---
Created attachment 49406
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49406&action=edit
skbuff.s from build of net/core/skbuff.o with GCC 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #30 from Christophe Leroy ---
Created attachment 49407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49407&action=edit
skbuff.i from build of net/core/skbuff.o with GCC 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97500
Bug ID: 97500
Summary: [11 Regression] ICE in vect_schedule_slp_instance, at
tree-vect-slp.c:5094 since r11-3823-g126ed72b9f48f853
Product: gcc
Version: 11.0
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97500
Martin Liška changed:
What|Removed |Added
Known to work||10.2.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97478
--- Comment #3 from Martin Liška ---
(In reply to Jakub Jelinek from comment #2)
> It breaks bootstrap on x86_64-linux and i686-linux too.
Can you please create an upstream bug for it then?
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.
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=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=97487
Jakub Jelinek changed:
What|Removed |Added
Keywords|openmp |
Summary|[10/11 Regression] I
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=97500
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
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
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=97414
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #4 from Martin Liška
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=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=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=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=95917
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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 #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 #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
>
> 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 #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
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=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=97501
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Priority|P3
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=97493
suochenyao at 163 dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
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=97502
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.0
Priority|P3
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=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=97502
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
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=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 #7 from Matthias Klose ---
commit 872d5034baa1007606d405e37937908602fbbe51
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=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=97501
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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=97010
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=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 #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
--- 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=82239
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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=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=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=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 #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=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 #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
--- 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=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=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=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=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=97471
Nathan Sidwell changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
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=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=97501
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=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=59325
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|
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=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=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=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=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=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=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=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=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=43892
Christophe Leroy changed:
What|Removed |Added
CC||christophe.leroy at csgroup
dot eu
-
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
--- 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=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=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=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=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=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=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=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=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=66552
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
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=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=97506
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #2 f
1 - 100 of 108 matches
Mail list logo