https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102450
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102494
--- Comment #5 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #4)
> >
> > But for the case in PR, it's v8qi -> 2 v4hi, and no vector reduction for
> > v4hi.
>
> We need add (define_expand "reduc_plus_scal_v4hi" just like (define_ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102495
Bug ID: 102495
Summary: optimize some consecutive byte load pattern to word
load
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102494
--- Comment #4 from Hongtao.liu ---
>
> But for the case in PR, it's v8qi -> 2 v4hi, and no vector reduction for
> v4hi.
We need add (define_expand "reduc_plus_scal_v4hi" just like (define_expand
"reduc_plus_scal_v8qi" in mmx.md.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102494
--- Comment #3 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #2)
> It seems x86 doesn't supports optab reduc_plus_scal_v8hi yet.
vectorizer does the work for backend.
typedef short v8hi __attribute__((vector_size(16)));
short
foo1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80570
--- Comment #3 from Peter Cordes ---
(In reply to Andrew Pinski from comment #2)
> Even on aarch64:
>
> .L2:
> ldr q0, [x1], 16
> sxtlv1.2d, v0.2s
> sxtl2 v0.2d, v0.4s
> scvtf v1.2d, v1.2d
> sc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102494
--- Comment #2 from Hongtao.liu ---
It seems x86 doesn't supports optab reduc_plus_scal_v8hi yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80570
Andrew Pinski changed:
What|Removed |Added
Component|target |tree-optimization
--- Comment #2 from An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100583
--- Comment #1 from Johel Ernesto Guerrero Peña ---
Please, add Bug 99227 to **Blocks:** for visibility.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473
--- Comment #7 from Hongtao.liu ---
> retired and clocksticks after my commit. And the regression comes from
> libc-2.31.so which shoud be the same.
difference in libc-2.31.so comes from frond-end bandwidth MITE, very low DSB
coverage.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473
--- Comment #6 from Hongtao.liu ---
>
> | Symbol | sys lib | Before | After |
> diff | % |
> |-+-++---+---
> +---|
> | __logf_fma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64960
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Summary|Inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60996
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102494
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-*-*
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102494
Bug ID: 102494
Summary: Failure to optimize out vector reduction properly
especially when using OpenMP
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60889
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40680
--- Comment #3 from Andrew Pinski ---
Looks like this was fixed in GCC 5+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44883
--- Comment #5 from Andrew Pinski ---
In GCC 9+ (due to 2->2 combine) we get:
.L2:
cmp r4, r5
blt .L3
pop {r4, r5, r6, r7, r8, pc}
.L3:
ldr r3, [r6]
lslsr2, r4, #5
add r8, r3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62166
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60778
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2014-04-08 00:00:00 |2021-9-26
--- Comment #2 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101334
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:fe2771b291c2c7c0ac37b75ec5b160937524b60c
commit r12-3890-gfe2771b291c2c7c0ac37b75ec5b160937524b60c
Author: Tobias Burnus
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102493
Bug ID: 102493
Summary: non-type template specialization for member pointer to
field and function reports leads to unexpected
conflict
Product: gcc
Version: 11.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102079
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102491
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102491
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102492
Bug ID: 102492
Summary: [12 Regression] ICE in scan_sharing_clauses, at
omp-low.c:1205
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102491
Bug ID: 102491
Summary: [12 Regression] Assembler messages: Error: no such
instruction: `vmovw %xmm0,%eax'
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102079
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102490
Bug ID: 102490
Summary: Erroneous optimization of default constexpr operator==
of struct with bitfields
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102486
--- Comment #2 from Andrew Pinski ---
(In reply to Luc Van Oostenryck from comment #1)
> when y != 0
Right. So it should be optimize to y!=0 then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102079
--- Comment #3 from Jan Hubicka ---
I think the problem here is that fortran uses "long int" while size_t
interoperate with "unsigned long int".
Does fortran standard promise that the value should inter-operate with size_t
as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102486
Luc Van Oostenryck changed:
What|Removed |Added
CC||luc.vanoostenryck at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102482
--- Comment #3 from Jonathan Wakely ---
And the fabulous manual:
> warn about uses of "std::initializer_list" that are likely to result in
> dangling pointers
This is behaving exactly as documented:
> * When a list constructor stores the "b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102482
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> > so I assume the warning is std::initializer_list specific.
>
> Yes. std::initializer_list is a magic language type that the compiler knows
> all about. st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102482
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Jonath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102489
Bug ID: 102489
Summary: [12 Regression] ICE in is_this_parameter, at
cp/semantics.c:11273
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102488
Bug ID: 102488
Summary: ICE with default constexpr operator== on class with
bitfield
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94726
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713
--- Comment #10 from Andrew Pinski ---
(In reply to Martin Liška from comment #1)
> I think it's fixed since r11-2588-gc072fd236dc08f99.
Oh this changed from the shift/xor/sub to using cmov ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713
Andrew Pinski changed:
What|Removed |Added
Target||x86_64
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98484
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98406
Andrew Pinski changed:
What|Removed |Added
Depends on||23384
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491
--- Comment #7 from Gerald Pfeifer ---
(In reply to David Malcolm from comment #2)
> I'm using $(includedir). What should I be using? Thanks
(In reply to Richard Biener from comment #5)
> I think a more appropriate place would be where we als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81315
Gerald Pfeifer changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69183
Andrew Pinski changed:
What|Removed |Added
CC||gerhard.steinmetz.fortran@t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78368
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69183
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.5
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102487
Bug ID: 102487
Summary: __builtin_popcount(y&3) is not optimized to
(y&1)+((y&2)>>1) if don't have popcount optab (or
expensive one)
Product: gcc
Version: 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102486
Bug ID: 102486
Summary: __builtin_popcount(y&-y) is not optimized to 1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738
--- Comment #7 from Andrew Pinski ---
Note we don't need to do y&-y only if we keep track of popcount of the
SSA_NAME. But we don't have that yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97425
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97393
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97374
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473
--- Comment #5 from Hongtao.liu ---
Regression also exists for -march=x86-64 -msse3 -mtune=generic -Ofast.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
Chinoune changed:
What|Removed |Added
CC||mehdi.chinoune at hotmail dot
com
--- Commen
56 matches
Mail list logo
