https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95638
--- Comment #7 from CVS Commits ---
The master branch has been updated by Bin Cheng :
https://gcc.gnu.org/g:2c0069fafb53ccb7a45a6815025dfcbd2882a36e
commit r11-1565-g2c0069fafb53ccb7a45a6815025dfcbd2882a36e
Author: Bin Cheng
Date: Sat Jun 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95110
--- Comment #5 from CVS Commits ---
The releases/gcc-8 branch has been updated by Bin Cheng :
https://gcc.gnu.org/g:0a7a2b7c64a77218e504e8390af29cfa5f79a242
commit r8-10320-g0a7a2b7c64a77218e504e8390af29cfa5f79a242
Author: Bin Cheng
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
--- Comment #18 from CVS Commits ---
The releases/gcc-8 branch has been updated by Bin Cheng :
https://gcc.gnu.org/g:0a7a2b7c64a77218e504e8390af29cfa5f79a242
commit r8-10320-g0a7a2b7c64a77218e504e8390af29cfa5f79a242
Author: Bin Cheng
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95784
Bug ID: 95784
Summary: Failure to optimize usage of __builtin_add_overflow
with return statement properly
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712
--- Comment #24 from Alexander Egorenkov ---
I finally figured it out and fixed buildroot.
This info is for posterity, in case somebody will have the same issue.
If i understood it correctly, then the problem was that buildroot
wrongly tried to b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95784
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95783
--- Comment #1 from Andrew Pinski ---
Note the stack is required to be 16 byte aligned so you need one more push.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95785
Bug ID: 95785
Summary: Compiler rejects instantiation of a class using
constexpr new/delete in its constructor/destructor
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95783
--- Comment #2 from Andreas Schwab ---
That is already handled through the return address push.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95411
Andreas Schwab changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95784
--- Comment #2 from Gabriel Ravier ---
cmov is so slow that :
- 1 movzx
- 1 setcc
- 1 sal
- 1 sar
- 1 and
- 1 test
is worth avoiding it ? From what I can see, the dependencies for the LLVM
version for the first cmov are :
- The left operand, whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95784
--- Comment #3 from Gabriel Ravier ---
The most important problem here is really that all the computations for r8d are
dependant on each other, too, the sal+sar+and chain all depend on the previous
operation, the LLVM version seems much better fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95587
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:5eb947601bdce59f2ff26694327ad173c51c2724
commit r11-1566-g5eb947601bdce59f2ff26694327ad173c51c2724
Author: Harald Anlauf
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95689
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:62c0c0ea7bfb6f8f6b8d767b05120cafb6823da6
commit r11-1567-g62c0c0ea7bfb6f8f6b8d767b05120cafb6823da6
Author: Harald Anlauf
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95687
--- Comment #5 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:ac932bfcd21e9523fa2b880ae8138aef79da7f54
commit r11-1568-gac932bfcd21e9523fa2b880ae8138aef79da7f54
Author: Harald Anlauf
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95688
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:cd6546ac0e8fb2f4ff2a4bb2db2363ca02bdb7ba
commit r11-1569-gcd6546ac0e8fb2f4ff2a4bb2db2363ca02bdb7ba
Author: Harald Anlauf
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95707
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:3345e74299687de6144b87c0632018cafd4ccf3b
commit r11-1570-g3345e74299687de6144b87c0632018cafd4ccf3b
Author: Harald Anlauf
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95784
--- Comment #4 from Gabriel Ravier ---
I've tried to benchmark this on my "Intel(R) Core(TM) i5-4310U CPU @ 2.00GHz"
(this is from /proc/cpuinfo) and I'm getting some really weird results, so if
you want to try to assist me in benchmarking (which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95784
--- Comment #5 from Gabriel Ravier ---
Created attachment 48760
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48760&action=edit
File for benchmarking this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95772
--- Comment #3 from Jonathan Wakely ---
No, =default means "do the right thing" which sometimes means deleting it.
In class templates that is especially true, where you don't know the properties
of the types used as data members or base classes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95784
--- Comment #6 from Gabriel Ravier ---
Created attachment 48761
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48761&action=edit
File for benchmarking this function but everything is aligned properly.
I've changed the source file slightly,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505
--- Comment #2 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:445d8da5fbd10e32f8ea470bd9ac02faba8fd718
commit r11-1572-g445d8da5fbd10e32f8ea470bd9ac02faba8fd718
Author: Iain Sandoe
Date: Sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505
--- Comment #3 from Iain Sandoe ---
we're also discussing whether there's a good way to make this available
automatically.
clang's current implementation includes unconditionally, which is a
possible solution - I'm not thrilled about blanket in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778
--- Comment #1 from Yichao Yu ---
Ah, I think this might be the fix for both this issue and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95780 . I'll test more and will
try to submit it later.
```
diff --git a/gcc/multiple_target.c b/gcc/multipl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778
--- Comment #2 from Yichao Yu ---
Also, the original code example had an error, the code that works properly was
```
static __attribute__((noinline,target_clones("default,avx2"))) int f2(int *p)
{
asm volatile ("" :: "r"(p) : "memory");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95784
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95786
Bug ID: 95786
Summary: Too aggressive target indirection elimination
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95787
Bug ID: 95787
Summary: Complete lack of optimization on assignment to some
types when followed by
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95787
--- Comment #1 from Andrew Pinski ---
This is an issue with just zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95788
Bug ID: 95788
Summary: std::ranges::construct_at's placement new not
intercepted
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95772
Marc Pawlowsky changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #10)
> The non-standard SLEEP intrinsic subroutine is documented as taking a
> default integer argument. This patch enforces this restriction.
>
> Index: gcc/fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95568
--- Comment #5 from Johel Ernesto Guerrero Peña ---
(In reply to Marek Polacek from comment #2)
> The problem seems to be not that we're in a require-clause but that we're in
> a template, the following is also rejected:
>
> template struct X {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95789
Bug ID: 95789
Summary: Const method is allowed to return non-const reference
on template class
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
--- Comment #12 from kargl at gcc dot gnu.org ---
This makes the UMASK intrinsic function generic by converting the input
argument to default integer kind and calling the relevant libgfortran function.
Index: gcc/fortran/iresolve.c
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95784
Gabriel Ravier changed:
What|Removed |Added
Attachment #48760|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778
--- Comment #3 from H.J. Lu ---
*** Bug 95780 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95780
H.J. Lu changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
Bug ID: 95790
Summary: Incorrect static target dispatch
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95067
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778
--- Comment #4 from Yichao Yu ---
Yeah, after digging further the two issue are indeed the same. I initially
didn't think they are since I didn't realize PR95786 (that the visibility
attribute is simply ignored completely...) and thought static w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
--- Comment #2 from Yichao Yu ---
The C++ code attached above produces the following incorrect code with `g++ -O2
-S`
.file "a.c"
.text
.p2align 4
.globl _Z3barv
.type _Z3barv, @function
_Z3barv:
.LFB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
--- Comment #3 from Yichao Yu ---
And the assembly showing the correct dispatch is
.file "a.c"
.text
.p2align 4
.type _ZL3fooPKcj, @function
_ZL3fooPKcj:
.LFB0:
.cfi_startproc
movl$1, %eax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94463
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95791
Bug ID: 95791
Summary: Unnecessary vzeroupper when only using zmm16 through
zmm31
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94463
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> If both files are combined into one, only the proper symbol is generated.
>
> Module read/write related?
Setting a breakpoint on mangled_identifier and gfc_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
--- Comment #4 from H.J. Lu ---
(In reply to Yichao Yu from comment #2)
> The C++ code attached above produces the following incorrect code with `g++
> -O2 -S`
>
> .file "a.c"
> .text
> .p2align 4
> .globl _Z3b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
--- Comment #5 from Yichao Yu ---
It’s wrong when running on a target that has avx512f. The unoptimuzed version
will call the correct foo but the unoptimized case won’t.
As I said, this is an issue when the total targets are different between th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95792
Bug ID: 95792
Summary: Failure to optimize assignment of struct members to
memset
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95793
Bug ID: 95793
Summary: Nested function multi-versioning doesn't work
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: midd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
--- Comment #6 from H.J. Lu ---
(In reply to Yichao Yu from comment #5)
> It’s wrong when running on a target that has avx512f. The unoptimuzed
> version will call the correct foo but the unoptimized case won’t.
>
> As I said, this is an issue w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95792
Gabriel Ravier changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
--- Comment #13 from kargl at gcc dot gnu.org ---
This patch makes the UMASK subroutine a generic subprogram. This is
accomplished by converting its arguments to INTEGER(4), call
_gfortran_umask_i4_sub, and converting the OLD argument back to an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95791
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95794
Bug ID: 95794
Summary: strnlen of a constant string plus variable offset not
folded when bound exceeds size
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95795
Bug ID: 95795
Summary: missing warning on strnlen with a nonstring and
excessive bound
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
--- Comment #7 from Yichao Yu ---
> Your testcase has nested function multi-versioning. I don't think it works
at all. I opened PR 95793.
I'm sorry but what is nested function multi-versioning? and what's the
difference between the test case h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
--- Comment #14 from Steve Kargl ---
This patch brings UNLINK subroutine into agreement with
its documentation.
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 2801
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
--- Comment #8 from Yichao Yu ---
And the reason I reported this as a mis-optimization rather than something
completely unsupported is that the following code.
```
#include
// #define disable_opt __attribute__((flatten))
#define disable_opt
d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95796
Bug ID: 95796
Summary: Inlining works between functions with the same target
attribute but not target_clones
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95797
Bug ID: 95797
Summary: Can std::allocator.deallocate newed pointer during
constant evaluation
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95760
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95746
--- Comment #3 from David Binderman ---
Fixed by date 20200619. Thanks for checking.
66 matches
Mail list logo
