https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
--- Comment #14 from Richard Biener ---
Btw, previous work is at refs/users/rguenth/heads/load-perm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111732
Bug ID: 111732
Summary: genmatch missed optimization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
--- Comment #22 from Richard Biener ---
extern void abort (void);
int __attribute__((noipa)) foo ()
{
return 1;
}
int main()
{
int res = foo ();
if (res != 0)
abort ();
}
Asks for call clobbered registers associated with user variabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111733
Bug ID: 111733
Summary: Emit inline SVE FSCALE instruction for ldexp
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111724
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-10-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956
--- Comment #13 from Richard Biener ---
While this issue seems fixed(?), there's now a new one with the same symptom,
not sure if we should dup and keep this one open?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111734
Bug ID: 111734
Summary: wrong code with '-O3 -fno-inline-functions-called-once
-fno-inline-small-functions -fno-omit-frame-pointer
-fno-toplevel-reorder -fno-tree-fre'
Prod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111734
--- Comment #1 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 56078
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56078&action=edit
The compiler output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111724
--- Comment #2 from Yi <652023330028 at smail dot nju.edu.cn> ---
(In reply to Richard Biener from comment #1)
> Yup, it's difficult. reassoc doesn't handle signed arithmetic, that's
> usually the pass that optimizes association for invariant mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
Gianfranco changed:
What|Removed |Added
Resolution|MOVED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
--- Comment #3 from Richard Biener ---
Reduced testcase:
struct B {
struct { int len; } l;
long n;
};
struct A {
struct B elts[8];
};
static void
set_len (struct B *b, int len)
{
b->l.len = len;
}
static int
get_len (struct B *b)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111735
Bug ID: 111735
Summary: incorrect BTF representation of forward-declared enums
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Bug ID: 111736
Summary: Address sanitizer is not compatible with named address
spaces
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111732
--- Comment #1 from Richard Biener ---
Created attachment 56079
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56079&action=edit
start of a patch
Start of a patch. Still has duplicate case values (dt tree insertion) and
missed for ID pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111737
Bug ID: 111737
Summary: Object holding a pointer to an uninitialized c-array
not usable in a constant expression
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111732
--- Comment #2 from Richard Biener ---
(In reply to Richard Biener from comment #1)
> Created attachment 56079 [details]
> start of a patch
>
> Start of a patch. Still has duplicate case values (dt tree insertion) and
> missed for ID passing t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111738
Bug ID: 111738
Summary: incorrect code when PGO is enabled
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111734
--- Comment #2 from CTC <19373742 at buaa dot edu.cn> ---
A reduced testcase:
#include
#include
struct a {};
struct {
uint32_t b;
int16_t c;
} d, f = {9, 1};
int32_t e;
static int32_t *g();
static uint32_t h() {
int32_t *i = &e;
struct a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111739
Bug ID: 111739
Summary: incorrect code with PGO enabled
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111738
--- Comment #1 from Richard Biener ---
I can't reproduce. Your git version is quite old, it translates to
r14-2634-g85da0b40538fb0 for me. It doesn't reproduce with r14-2282 either
though.
Current is r14-4486-g873586ebc565b6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111739
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:11b8cf1685bb40af5b86653e492e350983025957
commit r14-4510-g11b8cf1685bb40af5b86653e492e350983025957
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111739
--- Comment #2 from Anonymous ---
(In reply to Richard Biener from comment #1)
> Confirmed with r14-4302 and also with the head of the GCC 13 branch.
>
> It helps if you can produce proper ISO C without implicit int and like.
Thank you for con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111738
--- Comment #2 from Anonymous ---
(In reply to Richard Biener from comment #1)
> I can't reproduce. Your git version is quite old, it translates to
> r14-2634-g85da0b40538fb0 for me. It doesn't reproduce with r14-2282 either
> though.
>
> Cur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111740
Bug ID: 111740
Summary: Incorrect DWARF expression generated at specific live
range
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425
--- Comment #8 from Tomáš Glozar ---
It looks like somehow a value RTX with rt_cselib set to NULL gets into the
hashmap:
(gdb) f 1
#1 rtx_equal_for_cselib_1 (x=0x2674608, y=0x26747f8,
memmode=memmode@entry=E_VOIDmode, depth=depth@entry=1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #3 from Alexander Monakov ---
Sorry, the second half of my comment is confusing. To clarify, ASan works fine
for TLS data (the compiler knows that TLS base is at fs:0; libsanitizer uses
some hacks to initialize shadow for TLS anyway,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
--- Comment #5 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:b0892b1fc637fadf14d7016858983bc5776a1e69
commit r14-4520-gb0892b1fc637fadf14d7016858983bc5776a1e69
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111741
Bug ID: 111741
Summary: gcc long double precision
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111741
--- Comment #1 from bernardwidynski at gmail dot com ---
Created attachment 56082
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56082&action=edit
Output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
--- Comment #7 from Alexander Monakov ---
No backport for gcc-13 planned?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111742
Bug ID: 111742
Summary: Misaligned generated code with MI using aligned
virtual base
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111741
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111742
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83780
Andrew Pinski changed:
What|Removed |Added
CC||cuzdav at gmail dot com
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111741
--- Comment #3 from bernardwidynski at gmail dot com ---
Thanks for the quick response.
That explains it.
On Mon, Oct 9, 2023 at 10:20 AM pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
Andrew Macleod changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111742
--- Comment #2 from Chris Uzdavinis ---
No, this is not a ubsan report.
Code *crashes* and I thought showing the UBsan warning was enough to
demonstrate it.
A minimal change to make the code crash instead of just report ubsan errors:
struct X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111742
--- Comment #3 from Andrew Pinski ---
Then it is a dup of bug 71644.
*** This bug has been marked as a duplicate of bug 71644 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71644
Andrew Pinski changed:
What|Removed |Added
CC||cuzdav at gmail dot com
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
Bug ID: 111743
Summary: shifts in bit field accesses don't combine with other
shifts
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
--- Comment #1 from Andrew Pinski ---
Remember types smaller than int is prompted to int .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111744
Bug ID: 111744
Summary: Missed optimization when casting rdtsc into uint32_t
and computing difference
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
--- Comment #2 from Andi Kleen ---
Okay then it doesn't understand that SHL_signed and SHR_unsigned can be
combined when one the values came from a shorter unsigned.
hms: zlib zstd
gcc version 14.0.0 20231009 (experimental) (GCC)
ecking-yes-rtl-df-extra-powerpc64le
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231009 (experimental) (GCC)
The build breaks at:
$ make
/bin/sh ../libtool --tag CC --tag disable-shared --mode=compile
/repo/build-gcc-trunk-powerpc64le/./gcc/xgcc
-B/rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
--- Comment #9 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #8)
> (In reply to Alexander Monakov from comment #7)
> > No backport for gcc-13 planned?
>
> mmm, didn't realize were we propagating floating point equivalences ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111745
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #9)
Addendum:
> I was suspecting gfc_conv_variable as a possibly further place for a fix:
> it has a loop over ref's that looks incomplete for REF_COMPONENT.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111746
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111679
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
--- Comment #6 from Sam James ---
I started hitting the original warning Jakub hit with 13.2.1 20231007 but I've
not tried to figure out which backported change caused it to appear.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111747
Bug ID: 111747
Summary: Problem with large float list initialization
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111519
--- Comment #2 from Roger Sayle ---
Complicated. Things have gone wrong before the strlen pass which is given:
_73 = e;
_72 = *_73;
...
*_73 = prephitmp_23;
d = _72;
Here the assignment to *_73 overwrites the value of f (at *e) which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111748
Bug ID: 111748
Summary: GCC does not understand partial ordering between
non-constrained and constrained templates for
specialization
Product: gcc
Version: 13.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111749
Bug ID: 111749
Summary: Kk
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111750
Bug ID: 111750
Summary: Spurious -Warray-bounds warning when using member
function pointers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
--- Comment #5 from Andi Kleen ---
config/i386/i386.h:#define SLOW_BYTE_ACCESS 0
You mean it doesn't define it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
--- Comment #6 from Andrew Pinski ---
(In reply to Andi Kleen from comment #5)
> config/i386/i386.h:#define SLOW_BYTE_ACCESS 0
>
> You mean it doesn't define it?
The default is 1.
Anyways in this case I was wrong but defining it to 0 causes ot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111749
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111750
--- Comment #1 from Andrew Pinski ---
> That this source produces a -Warray-bounds warning is somewhat surprising
> since it contains no arrays, no array indexing, and no pointer arithmetic
Well techincally there is pointer arithmetic because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111747
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
TO compression algorithms: zlib
gcc version 14.0.0 20231009 (experimental) (GCC)
git version: dee55cf59ceea989f47e7605205c6644b27a1f78
Then, we compiled the same test program with/without PGO enabled and found that
the results are inconsistent as:
$ gcc -O3 -w -fprofile-generate=profile a.c -o a.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111745
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111734
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|wrong code with '-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
Bug ID: 111751
Summary: RISC-V: RVV unexpected vectorization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #1 from Andrew Pinski ---
AARCH64 did vectorize the code just using non-SVE which then allowed to be
optimized too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #3 from Andrew Pinski ---
If you add `-fno-vect-cost-model` to aarch64 compiling, then it uses SVE and
does not optimize to just `return 0`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #4 from Andrew Pinski ---
The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
ib = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
vect__1.7_9 = .MASK_LOA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #5 from JuzheZhong ---
(In reply to Andrew Pinski from comment #4)
> The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
>
> ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18\x1b\x1e!$\'*-";
> ib = "\x00\x03\x06\t\f\x0f\x12\
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #6 from Andrew Pinski ---
(In reply to JuzheZhong from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
> >
> > ic = "\x00\x03\x06\t\f\x0f\x12\x15\x18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111751
--- Comment #7 from JuzheZhong ---
(In reply to Andrew Pinski from comment #6)
> (In reply to JuzheZhong from comment #5)
> > (In reply to Andrew Pinski from comment #4)
> > > The issue for aarch64 with SVE is that MASK_LOAD is not optimized:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111752
Bug ID: 111752
Summary: -Wfree-nonheap-object (vec.h:347:10: warning: 'free'
called on unallocated object 'dest_bbs') during
bootstrap with LTO
Product: gcc
Vers
-4521-20231009151152-g08d0f840dc7-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231009 (experimental) (GCC)
/repo/gcc-trunk//binary-trunk-r14-4521-20231009151152-g08d0f840dc7-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231009 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755
Bug ID: 111755
Summary: The built-in memset function in GCC inadvertently
generates code like "vst1.8 {d8-d9}, [sp:64]", which
assumes an 8-byte alignment on the stack pointer $sp,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-10-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755
--- Comment #2 from Andrew Pinski ---
Also can you attach the testcase where this happens?
Please read https://gcc.gnu.org/bugs/ on what information we need.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111755
--- Comment #3 from Andrew Pinski ---
The ARM EABI says the stack is always aligned to 8 byte so unless you change
GCC to be do this, this is exacted and the incoming stack needs to be aligned
correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
--- Comment #7 from Richard Biener ---
(In reply to Sam James from comment #6)
> I started hitting the original warning Jakub hit with 13.2.1 20231007 but
> I've not tried to figure out which backported change caused it to appear.
With what con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
--- Comment #8 from Sam James ---
(In reply to Richard Biener from comment #7)
> (In reply to Sam James from comment #6)
> > I started hitting the original warning Jakub hit with 13.2.1 20231007 but
> > I've not tried to figure out which backpor
89 matches
Mail list logo
