https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859
Martin Liška changed:
What|Removed |Added
Summary|ICE in tsubst_omp_clauses, |[12 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100870
Bug ID: 100870
Summary: Constant expression for bind(C) name in interface body
not importable
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100857
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-06-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100850
--- Comment #4 from Iain Sandoe ---
(In reply to Vlad from comment #3)
> My bad. It's actually a UB. The lambda lifetime is just over by the moment
> of resumption of the co-routine.
(oddly enough) we were discussing thia in a BSI meeting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032
--- Comment #11 from Jonathan Wakely ---
I don't think the policy change affects this at all. There is no change to the
licenses of any GCC code or docs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859
--- Comment #4 from Jakub Jelinek ---
That last ICE seems to be specific to cdtors only, so iterator handling during
cdtor cloning...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
--- Comment #3 from Jonathan Wakely ---
Do we ever want the _Hashtable_ebo_helper to *not* value-init its T
subobject? I think we should do the value-init in _Hashtable_ebo_helper
instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100867
Bug ID: 100867
Summary: z13: Inefficient code for vec_revb(vector unsigned
short)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-06-02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100850
--- Comment #5 from Vlad ---
> Can this be closed then?
Sure. Thanks you very much!
For the history, before it's closed I'd like to leave this reference:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97712
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859
Tobias Burnus changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100852
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.2
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100874
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100874
Bug ID: 100874
Summary: [12 Regression] slight missed optimization with
min-CST on aarch64
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100862
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855
--- Comment #5 from Nadav Halahmi ---
(In reply to Richard Biener from comment #3)
> Might be interesting to see whether ifort does any expression simplification
> here. Can you share the produced assembly?
ifort pow.f90 -O3 -no-vec -S -o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855
--- Comment #4 from Nadav Halahmi ---
(In reply to Richard Biener from comment #3)
> Might be interesting to see whether ifort does any expression simplification
> here. Can you share the produced assembly?
gfortran pow.f90 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100850
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84476
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2021-04-21 00:00:00 |2021-6-2
--- Comment #5 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100868
Bug ID: 100868
Summary: PPC: Inefficient code for vec_reve(vector double)
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84476
--- Comment #3 from Jonathan Wakely ---
(In reply to Martin Ankerl from comment #1)
> I just "discovered" this bug as well. The warning works correctly in g++
> 6.4, but starting from 7.1 upwards it does not work any more.
No, I don't think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 90120, which changed state.
Bug 90120 Summary: inconsistent punctuation in translation messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120
Claudiu Zissulescu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100871
Bug ID: 100871
Summary: z14: vec_doublee maps to wrong builtin in vecintrin.h
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855
--- Comment #3 from Richard Biener ---
Might be interesting to see whether ifort does any expression simplification
here. Can you share the produced assembly?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100858
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864
--- Comment #3 from Richard Biener ---
You can possibly merge it with the
(for bitop (bit_and bit_ior)
rbitop (bit_ior bit_and)
/* (x | y) & x -> x */
/* (x & y) | x -> x */
(simplify
(bitop:c (rbitop:c @0 @1) @0)
@0)
/* (~x |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100873
Bug ID: 100873
Summary: [12 Regression] gcc.target/aarch64/subs_compare_2.c
fails since r12-1152-g9f55df63
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100874
Andrew Pinski changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100873
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928
--- Comment #17 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:9ca24bd34b6ac44c17f949d89ff60d0fd4665133
commit r12-1158-g9ca24bd34b6ac44c17f949d89ff60d0fd4665133
Author: Tobias Burnus
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84476
Jonathan Wakely changed:
What|Removed |Added
CC||pacoarjonilla at yahoo dot es
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
Bug ID: 100866
Summary: PPC: Inefficient code for vec_revb(vector unsigned
short) < P9
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100869
Bug ID: 100869
Summary: z13: Inefficient code for vec_reve(vector double)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100872
Bug ID: 100872
Summary: [OpenMP] internal compiler error: tree check: expected
integer_cst, have mult_expr in
simd_clone_clauses_extract, at omp-simd-clone.c:253
Product:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #9 from luoxhu at gcc dot gnu.org ---
Patch sent, it could fix the __float128 to vector __int128 issue,
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571689.html
But for __float128 to __int128 mentioned in #c4, need hack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100874
--- Comment #3 from Andrew Pinski ---
Note here is a 4th variant of the function:
int f1a(int a) { int x = a - 4; return (a < 4) ? x : 0; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859
--- Comment #3 from Jakub Jelinek ---
WIP testcase:
struct S {
S () {}
};
struct W {
S c[10];
W () {
#pragma omp task affinity (iterator (i = 0 : 10 : 1): c[i])
;
#pragma omp task depend (iterator (i = 0 : 10 : 1), inout: c[i])
;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100875
Bug ID: 100875
Summary: Spurious behavior for non-advancing user defined
derived type IO
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |12.0
Version|11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860
--- Comment #3 from Tom Robinson ---
I tried with the main (12.0.0) and this code ran. I will try it in with our
main codebase to confirm it works there too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453
--- Comment #17 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:ad4c21f0f59b52357019148ec94d767aa2acd8f2
commit r11-8500-gad4c21f0f59b52357019148ec94d767aa2acd8f2
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808
--- Comment #2 from Segher Boessenkool ---
(In reply to Jens Seifert from comment #0)
> - Avoid additional "int" unsigned long long int => unsigned long long
Why? Those are exactly the same types!
> - add missing line breaks between builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100878
Bug ID: 100878
Summary: enabling UBSAN leads to false positive `'this' pointer
is null` when casting lambda to function pointer
Product: gcc
Version: 11.1.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-*-* |powerpc*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-06-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100877
Bug ID: 100877
Summary: g++ freezes system by consuming infinite amount of
memory
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100868
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #7 from TC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855
--- Comment #6 from Dominique d'Humieres ---
On a MacOS, Corei9, 2.4Ghz, the program runs in ~1s, almost indpendtly of the
option level.
This PR remind me an old problem in which the transcendental functions were
almost slower for REAL(4) then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808
--- Comment #3 from Jens Seifert ---
- Avoid additional "int" unsigned long long int => unsigned long long
Why? Those are exactly the same types!
Yes, but the rest of the documentation uses unsigned long long.
This is just for consistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100592
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #32 from Richard Biener ---
+ /* We cannot inline a function with a VLA typed argument or result since
+ we have no implementation materializing a variable of such type in
+ the caller. */
+ if (COMPLETE_TYPE_P (TREE_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859
--- Comment #5 from Jakub Jelinek ---
Created attachment 50908
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50908=edit
gcc12-pr100859.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860
Tom Robinson changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:10c58754a862470484eca81623b71e6851470bb6
commit r11-8503-g10c58754a862470484eca81623b71e6851470bb6
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876
Bug ID: 100876
Summary: -Wmismatched-new-delete should either look through or
ignore placement new
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100872
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #34 from Richard Biener ---
interestingly I see
a.9_70 = .builtin_alloca_with_align (iftmp.8_1, 8);
(*a.9_70) = inline22.get_zero (); [static-chain: ] [return slot
optimization]
so there's no WITH_SIZE_EXPR, but the return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #35 from Eric Botcazou ---
> interestingly I see
>
> a.9_70 = .builtin_alloca_with_align (iftmp.8_1, 8);
> (*a.9_70) = inline22.get_zero (); [static-chain: ] [return slot
> optimization]
>
> so there's no WITH_SIZE_EXPR, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #33 from Eric Botcazou ---
> so that would mean adding
>
>&& !DECL_BY_REFERENCE (DECL_RESULT (fndecl))
>
> I suppose or looking at DECL_RESULT in the first place (which is a pointer
> in that case).
Not in the array case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100862
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100833
--- Comment #2 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:88ed4abb351117f3b7ef9174b3f538c73e6012c7
commit r11-8502-g88ed4abb351117f3b7ef9174b3f538c73e6012c7
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100768
--- Comment #2 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:f2b76257e9a487fd2c7265094f7b4d1bd46f5f03
commit r11-8501-gf2b76257e9a487fd2c7265094f7b4d1bd46f5f03
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100872
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100872
--- Comment #1 from Tobias Burnus ---
The problem is that
aligned(a : X * 2)
In pt.c's apply_late_template_attributes, we have:
>
value > value >
chain >
value
op-1:
The comment in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:f8f0193b5b83f6e85d65015e79c803295baf5166
commit r12-1163-gf8f0193b5b83f6e85d65015e79c803295baf5166
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:f8f0193b5b83f6e85d65015e79c803295baf5166
commit r12-1163-gf8f0193b5b83f6e85d65015e79c803295baf5166
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:81eab204a56dcd8acb1ca5d7df277437ca07b51a
commit r12-1162-g81eab204a56dcd8acb1ca5d7df277437ca07b51a
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100838
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:63d182b29306e582bfb151cf762820211ea1cc7e
commit r12-1165-g63d182b29306e582bfb151cf762820211ea1cc7e
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100880
Bug ID: 100880
Summary: The build should error out for define_insn without
insn template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100882
Bug ID: 100882
Summary: ICE in gimplify_var_or_parm_decl, at gimplify.c:2755
Product: gcc
Version: 9.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100883
Bug ID: 100883
Summary: ifcombine should use (gimple) match and simplify
instead of fold
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100879
Bug ID: 100879
Summary: gcc is complaining of a signed compare when comparing
enums of different types (same underlying type)
Product: gcc
Version: 10.1.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96674, which changed state.
Bug 96674 Summary: Failure to optimize combination of comparisons to dec+compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96674
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35646
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100865
--- Comment #5 from H.J. Lu ---
A small benchmark:
https://gitlab.com/x86-benchmarks/microbenchmark/-/tree/memset/broadcast
shows that broadcast is a little bit faster on Intel Core i7-8559U:
[hjl@gnu-cfl-2 microbenchmark]$ make
gcc -g -I.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36384
--- Comment #2 from Andrew Pinski ---
during VRP1 removes the casts now.
So I don't know if this bug should be closed as fixed or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27504
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2012-01-04 00:00:00 |2021-6-2
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100877
Steven Sun changed:
What|Removed |Added
CC||StevenSun2021 at hotmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68000
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407
--- Comment #4 from seurer at gcc dot gnu.org ---
It does not fail on LE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45861
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2012-02-03 00:00:00 |2021-6-2
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2007-07-01 00:53:44 |2021-6-2
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22199
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.0
--- Comment #5 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98777
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Przemyslaw Wirkus
:
https://gcc.gnu.org/g:05f6971ac40912ef062915f88b3ea0bf27278285
commit r10-9882-g05f6971ac40912ef062915f88b3ea0bf27278285
Author: Vladimir N.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Przemyslaw Wirkus
:
https://gcc.gnu.org/g:1791b11d9cae388ae18a768eeb96c998439c986a
commit r10-9881-g1791b11d9cae388ae18a768eeb96c998439c986a
Author: Vladimir N.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52254
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407
--- Comment #6 from H.J. Lu ---
Created attachment 50914
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50914=edit
attr-retain-1.s
Here is my attr-retain-1.s. Please upload your attr-retain-1.s.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100865
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100885
--- Comment #1 from Hongtao.liu ---
152(define_register_constraint "Yw"
153 "TARGET_AVX512BW && TARGET_AVX512VL ? ALL_SSE_REGS : TARGET_SSE ? SSE_REGS
: NO_REGS"
154 "@internal Any EVEX encodable SSE register (@code{%xmm0-%xmm31}) for
AVX512BW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100885
--- Comment #2 from Hongtao.liu ---
> With avx512vl Yw should be matched, and w/o avx512bw, only SSE_REGS should
> be matched, why xmm16 is allocated?
It didn't come from RA, but post_reload splitter.
18103(define_insn_and_split
1 - 100 of 150 matches
Mail list logo