https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101934
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Andrew Pinski
:
https://gcc.gnu.org/g:f00530266f89b28e8286cdd2f587e046a27d2193
commit r11-9001-gf00530266f89b28e8286cdd2f587e046a27d2193
Author: Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101934
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102358
Bug ID: 102358
Summary: niter_base and miter_base overloaded for move_iterator
missing constexpr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
--- Comment #1 from Andrew Pinski ---
Was there a change to C++ beteween C++17 and C++20 here? A defect report?
Because clang errors out with the same message as GCC for C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78463
--- Comment #2 from Richard Biener ---
There were more instances fixed (like PR70586 was), but there may be still
cases left. Also there's still the missed optimization of
computing/propagating 'notrap'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
--- Comment #2 from jim x ---
This part in c++20 is more clear than c++17, which is added since c++20, see
https://timsong-cpp.github.io/cppwp/n4861/dcl.fct.def.default#2. What the
version I'm testing the code is GCC 12.0 with -std=c++20 command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94302
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
--- Comment #3 from Andrew Pinski ---
So I suspect it is/was DR 2221 :).
Basicallythe editorial changes resolved it.
So yes there is a change between C++17 and C++20.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
--- Comment #4 from jim x ---
I haven't found that pull request. However, the proposal sources from P0641R2,
see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0641r2.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
--- Comment #15 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:a26ff83ed07e33c4aa46f3314553c0d15ca21100
commit r12-3569-ga26ff83ed07e33c4aa46f3314553c0d15ca21100
Author: liuhongt
Date: Thu Sep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102305
--- Comment #8 from Jakub Jelinek ---
Fixed for 11.3+ now too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88578
--- Comment #8 from Jakub Jelinek ---
Fixed for 12.1+ and 11.3+ for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102295
--- Comment #10 from Jakub Jelinek ---
Fixed also for 11.3+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359
Bug ID: 102359
Summary: ICE gimplification failed since
r12-3433-ga25e0b5e6ac8a77a
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102360
Bug ID: 102360
Summary: ICE in can_native_interpret_type_p at
gcc/fold-const.c:8800
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102360
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target Mile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102356
Martin Liška changed:
What|Removed |Added
Summary|compile-time explosion at |[11/12 Regression]
|-O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102360
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #5 from Jonathan Wakely ---
Sure. It's just a question of whether we're trying to provide a general purpose
extension available for users, or an internal helper for the std::lib. IIRC we
explicitly decided we only cared about support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #6 from Jakub Jelinek ---
Note, having the struct somewhere else isn't that useful unless you know
exactly how its non-static data members are named and what they mean, so
ideally a class with accessor methods, which is what std::sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81344
Michael Osipov changed:
What|Removed |Added
CC||michael.osipov at siemens dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
Bug ID: 102361
Summary: Errors compiling Linux kernel 5.14.4 with
CONFIG_FORTIFY=y
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102357
--- Comment #6 from Jonathan Wakely ---
https://github.com/cplusplus/draft/commit/219538a7be4f3e71f05070d1a52aa7150505e732
is the editorial change that resolved CWG 2221, but I don't think it's relevant
here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60865
Zdenek Sojka changed:
What|Removed |Added
Known to work||5.5.0, 6.5.0, 7.5.0, 8.5.0
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #7 from Peter Dimov ---
(In reply to Jonathan Wakely from comment #5)
> Sure. It's just a question of whether we're trying to provide a general
> purpose extension available for users, or an internal helper for the
> std::lib. IIRC w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #8 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #6)
> Note, having the struct somewhere else isn't that useful unless you know
> exactly how its non-static data members are named and what they mean, so
> ideally a cla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #9 from Jakub Jelinek ---
That would be an aliasing violation.
The artificial vars created by __builtin_source_location have the
std::source_location::__impl type, so accessing those using some other dynamic
type is invalid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102362
Bug ID: 102362
Summary: 'dump_printf_loc' doesn't work from 'gate' method of a
'gimple_opt_pass'
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #10 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #9)
> That would be an aliasing violation.
> The artificial vars created by __builtin_source_location have the
> std::source_location::__impl type, so accessing those u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347
--- Comment #3 from Kewen Lin ---
This seems not a target specific issue. I noticed the target_option tree node
is created expectedly when seeing target pragma, it explains why it works well
without lto. When lto does streaming out, it does stre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #11 from Jakub Jelinek ---
That is not possible, because std::source_location::current() should be
consteval and it can't be in C++ < 20, and without consteval it will behave
significantly differently. Note, the C++ FE knows
std::so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #12 from Jonathan Wakely ---
We could have added std::__source_location_impl as the type that the built-in
returns and used that instead of making it a private member of
std::source_location. That would also have allowed it to be use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #13 from Jonathan Wakely ---
It wouldn't work correctly in all cases, as Jakub points out, because
std::source_location::current() is part of the magic.
And I'm not convinced we want/need to support those uses.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #14 from Jakub Jelinek ---
But we haven't done that that way and how would headers know if the
__builtin_source_location that is available is the old or new one?
As for std::experimental::source_location, could we change ABI of those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #15 from Peter Dimov ---
(In reply to Jonathan Wakely from comment #13)
> It wouldn't work correctly in all cases, as Jakub points out, because
> std::source_location::current() is part of the magic.
>
> And I'm not convinced we wan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #16 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #14)
> But we haven't done that that way and how would headers know if the
> __builtin_source_location that is available is the old or new one?
The header could do
na
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102362
--- Comment #1 from Richard Biener ---
Why would you call such method from the gate()?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #17 from Jakub Jelinek ---
You'd need a different builtin (so that you know the presence of the builtin
means the new behavior), ideally tell the builtin some way the type it should
construct objects in (as opposed to std::source_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102363
Bug ID: 102363
Summary: source_location in await_transform has function_name
referring to internal coroutine funclet rather than
source-level function
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102360
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:8d6b12b2233dabf3573383a15ccc67fdb925e5b3
commit r12-3578-g8d6b12b2233dabf3573383a15ccc67fdb925e5b3
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102360
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102362
--- Comment #2 from Thomas Schwinge ---
Here, to emit 'note: [...]' ('-fopt-info-note') if because of certain input
source code characteristics (derived from
'DECL_ATTRIBUTES(current_function_decl)'), certain code transformations
do/don't need t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #18 from Peter Dimov ---
I would use it like this: https://godbolt.org/z/1eqEx6678
#include
struct error_category
{
};
error_category const& system_category();
struct error_code
{
error_code( int v, error_category const& cat
gcc version 12.0.0 20210916 (experimental) [master r12-3577-g275a076f762] (GCC)
[582] %
[582] % gcctk -O0 small.c; a.out
[583] %
[583] % gcctk -O1 small.c
[584] % ./a.out
Aborted
[585] %
[585] % cat small.c
int a, b, *c = &b;
short d;
int main() {
unsigned e = 1;
for (d = 9; d > 8;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102364
Martin Liška changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102364
Martin Liška changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102364
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #19 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #14)
> As for std::experimental::source_location, could we change ABI of those?
Yes, we don't promise stability between major releases for the experimental
stuff (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102365
Bug ID: 102365
Summary: Function attribute docs should have an anchor or id on
each attribute.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102365
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-09-16
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102365
--- Comment #2 from Jonathan Wakely ---
See e.g. https://gcc.gnu.org/pipermail/gcc/2021-August/237078.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
--- Comment #2 from DAC324 ---
Please let me kindly ask you for instructions on how to do that.
As described in the introduction, I was trying to compile the Linux kernel from
the usual source tarball available on kernel.org.
What I did after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
--- Comment #6 from Bill Schmidt ---
Thanks, Tobias! I'm sorry for getting this exactly backwards...
Your patch looks good. I am doing a quick host=target=build bootstrap and will
respond on-list when it'sdone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
--- Comment #4 from DAC324 ---
Please let me kindly ask you for instructions on how to do that.
As described in the introduction, I was trying to compile the Linux kernel from
the usual source tarball available on kernel.org.
What I did after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
--- Comment #5 from DAC324 ---
OK, here we go:
make -f ./scripts/Makefile.build obj=mm/kfence \
\
need-builtin=1 \
need-modorder=1
gcc -Wp,-MMD,mm/.memcontrol.o.d -nostdinc -isystem
/usr/lib/gcc/x86_64-pc-linux-gnu/12.0.0/include -I./arch/x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102283
--- Comment #3 from Patrick Palka ---
(In reply to Giuseppe D'Angelo from comment #2)
> Hi,
>
> Do you think that in my original testcase the call should be rejected as
> ambiguous as well? (It seems "reasonable" to me, but maybe I'm missing so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
--- Comment #6 from DAC324 ---
Created attachment 51469
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51469&action=edit
File mm/memcontrol.c saved with -save-temps option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
--- Comment #7 from DAC324 ---
Created attachment 51470
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51470&action=edit
File mm/memcontrol.c saved with -save-temps option (2/2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102361
--- Comment #8 from DAC324 ---
This is the first error; if make is used with -j greater than 1, several of
those errors occur (see introduction).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366
Bug ID: 102366
Summary: [10/11/12 Regression] Illegal instruction with large
arrays
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366
Iain Sandoe changed:
What|Removed |Added
Target||x86_64-darwin,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102367
Bug ID: 102367
Summary: Types may be defined in `decltype` or `sizeof`
expressions in C++20
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
Bug ID: 102368
Summary: Failure to compile program using the C_SIZEOF function
in ISO_C_BINDING
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102369
Bug ID: 102369
Summary: VALUE attribute for arrays not allowed
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102369
--- Comment #1 from Bill Long ---
I assume the cascade of error messages all originate with the first one. The
combination of VALUE for an array is allowed in F08 and later versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102370
Bug ID: 102370
Summary: Runtime failure with allocatable component of
allocatable parent and MOVE_ALLOC
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102371
Bug ID: 102371
Summary: Error for type spec in FORALL statement
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102372
Bug ID: 102372
Summary: [12 regression] ICE in
gfortran.dg/ISO_Fortran_binding_1.f90 after r12-3482
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102371
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178
--- Comment #4 from Martin Jambor ---
(In reply to Martin Jambor from comment #3)
> ...I'll have a very brief look at what is actually happening just so that I
> have more reasons to believe this is not a code placement issue again.
The hot fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39270
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39270
Patrick Palka changed:
What|Removed |Added
Blocks||102184
--- Comment #4 from Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
--- Comment #7 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:acd7e7b33fd576b336ca0bf5ec51f77b32ba51cc
commit r12-3581-gacd7e7b33fd576b336ca0bf5ec51f77b32ba51cc
Author: Tobias Burnus
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102238
Martin Sebor changed:
What|Removed |Added
Blocks|102216 |84774
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102238
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102373
Bug ID: 102373
Summary: Segmentation fault in dwarf2out.c, line 32744
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102373
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102238
Andrew Pinski changed:
What|Removed |Added
Blocks||102216
--- Comment #7 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92435
--- Comment #4 from Eric Gallager ---
(In reply to Martin Sebor from comment #3)
> See also the following question:
> https://gcc.gnu.org/pipermail/gcc/2021-September/237281.html
> It would be helpful to document the GCC specific directives som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102283
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089
Eric Gallager changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67102
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:db1a65d9364fe72c2fff65fb2dec051728b6f3fa
commit r12-3583-gdb1a65d9364fe72c2fff65fb2dec051728b6f3fa
Author: Andrew Pinski
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67102
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102373
--- Comment #2 from dave.anglin at bell dot net ---
On 2021-09-16 1:38 p.m., jakub at gcc dot gnu.org wrote:
> This looks wrong, comp_unit_die () should have DW_AT_producer at this point.
> gen_compile_unit_die should have added it...
I did chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:cfea7b86f2430b9cb8018379b071f4004233119c
commit r12-3584-gcfea7b86f2430b9cb8018379b071f4004233119c
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59697
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|Function attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314
--- Comment #11 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:58c76fb477b51adeb9241de0b175a817e9c73b8a
commit r11-9008-g58c76fb477b51adeb9241de0b175a817e9c73b8a
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85130
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:3bc4ed085145e1cb6089841c811094633eea7431
commit r11-9009-g3bc4ed085145e1cb6089841c811094633eea7431
Author: Harald Anlauf
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102374
Bug ID: 102374
Summary: Should ignore spaces in target attribute
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102375
Bug ID: 102375
Summary: (aarch64) Should allow space in target attribute
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102376
Bug ID: 102376
Summary: [aarch64] using target("sve") attribute without a + is
not very helpful on what is wrong
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490
--- Comment #14 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:c38626f7a66dea400e54f671bfe32dc46e11ad44
commit r10-10131-gc38626f7a66dea400e54f671bfe32dc46e11ad44
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:5595cc9eb709c4aef1c7bbbfc6b106cf6d5bee91
commit r10-10132-g5595cc9eb709c4aef1c7bbbfc6b106cf6d5bee91
Author: Harald Anlauf
1 - 100 of 196 matches
Mail list logo
