https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #11 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #10)
> Hmm... maybe I am being too hasty here.
>
> If the coroutine has a definition in a header, then the coroutine frame type
> _should_ be the same for each instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #15 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #14)
> Are you guys really sure you want to blame the user here,
I apologise if this hasn't been a nice experience for you.
I'm not blaming anyone, least o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104852
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763
--- Comment #7 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:1f83aee5864129c4147a95c1a4e35d37c7eb7e59
commit r13-6463-g1f83aee5864129c4147a95c1a4e35d37c7eb7e59
Author: Iain Buclaw
Date: Fri M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #1 from Andrew Pinski ---
On aarch64, both get vectorized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
Andrew Pinski changed:
What|Removed |Added
Blocks||53947
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Alexander Monakov changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #14 from Bill Wendling ---
(In reply to Martin Uecker from comment #9)
> > > Considering that the GNU extensions is rarely used, one could consider
> > > redefining the meaning of
> > >
> > > int n = 1;
> > > struct {
> > > int n;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #4 from Jakub Jelinek ---
Hacker's Delight has also a variant for popcount, either .POPCOUNT ((x - 1) &
~x)
or bitsize - .POPCOUNT (x | -x), though a question is if there are any targets
which have vector popcount and don't have vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #5 from Jakub Jelinek ---
And to answer myself, as x86 has vplzcnt* just for 32-bit and 64-bit elts with
-mavx512cd (perhaps -mavx512vl also depending on vecsize), there is also 8-bit
and 16-bit element vector popcount (guarded by di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109017
Bug ID: 109017
Summary: ICE on unexpanded pack from C++20
explicit-template-parameter lambda syntax
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871
--- Comment #8 from Jonny Grant ---
Another test case.
https://godbolt.org/z/qss7jj51x
I noticed when not using -fanalyzer gcc still warns about __builtin_puts being
passed NULL. However gcc doesn't warn about my own function with attribute
n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #15 from Martin Uecker ---
Am Freitag, dem 03.03.2023 um 20:27 + schrieb isanbard at gmail dot com:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #14 from Bill Wendling ---
> (In reply to Martin Uecker f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #17 from Segher Boessenkool ---
What makes you think we need to tell the user to do something? There is
nothing that needs to be done as far as I can see? /confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42566
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #7 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:d3ef73867e3f70a343ad5aa4e00b270be85fa572
commit r13-6465-gd3ef73867e3f70a343ad5aa4e00b270be85fa572
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
Bug ID: 109018
Summary: decltype of dependent expressions lookup should be
done only when doing template function definition
Product: gcc
Version: 13.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109014
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:56572a08ec4a0fc1a7802d3737cd7f7cc9089c4b
commit r13-6466-g56572a08ec4a0fc1a7802d3737cd7f7cc9089c4b
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
--- Comment #7 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:56572a08ec4a0fc1a7802d3737cd7f7cc9089c4b
commit r13-6466-g56572a08ec4a0fc1a7802d3737cd7f7cc9089c4b
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
--- Comment #2 from Andrew Pinski ---
Also from that page:
> If multiple declarations of the same template differ in the result of name
> lookup, the first such declaration is used
That is GCC gets that part correct even while clang and MSVC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> template
> decltype(g(T())) h()
> return g(T());}
Typo in my example missing {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #8 from David Malcolm ---
(In reply to Jakub Jelinek from comment #6)
> Fixed.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #16 from Bill Wendling ---
(In reply to Martin Uecker from comment #15)
> Am Freitag, dem 03.03.2023 um 20:27 + schrieb isanbard at gmail dot com:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> >
> > --- Comment #14 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109016
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:df0184906a7b86a497c038766366904a20b5601e
commit r13-6467-gdf0184906a7b86a497c038766366904a20b5601e
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109019
Bug ID: 109019
Summary: Failure to optimize b + c -1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109019
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109019
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #12 from Tom Stellard ---
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=6e80a1d164d1f9 is the first bad
commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #6 from Jakub Jelinek ---
Oh, and optabs.cc expands ctz using clz as (bitsize-1) - .CLZ(x & -x) which is
one fewer operations if andn isn't supported, on the other side is undefined at
zero (so could be used for __builtin_ctz but not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
qingzhe huang changed:
What|Removed |Added
Resolution|INVALID |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #5 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
--- Comment #6 from qingzhe huang ---
I agree "Note g can be still found after the declaration via argument dependent
lookup."
Can we view this issue from a different angle? The real work of parsing should
be started at "template function defin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109004
--- Comment #1 from bugreporter66 at gmail dot com ---
Checked g++ 10.4 today, it works as it should.
11.3 and 12.1 were tested to show the issue so far.
The command line for building:
powerpc64le-linux-gnu-g++ -O2 -static test.cpp -o test_p64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
--- Comment #3 from bugreporter66 at gmail dot com ---
Thanks, I will try to find out and be more specific where exactly it leaks.
It was my first attempt at reducing the code that would fit into 1MB
attachment.
Checked g++ 10.4 today, it works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #17 from Martin Uecker ---
Am Freitag, dem 03.03.2023 um 23:18 + schrieb isanbard at gmail dot com:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #16 from Bill Wendling ---
> (In reply to Martin Uecker f
101 - 142 of 142 matches
Mail list logo
