https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740
--- Comment #12 from Bernd Buschinski ---
Hi, according to godbolt (gcc trunk) this is still present.
is there anything I can do to help here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #10 from rguenther at suse dot de ---
On Fri, 23 Jun 2023, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
>
> --- Comment #8 from Jan Hubicka ---
> > > I was playing with the idea of warning whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110223
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #25 from Andrew Pinski ---
(In reply to Richard Biener from comment #23)
>
> So somewhat of a pass ordering issue. The next CSE is DOM and then PRE.
I was going to say this is related to PR 110405 but pointers don't record
ranges (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110407
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110407
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> Which itself is GCC 12+ regression too ...
I filed that as PR 110407, let's see what the x86 backend folks say ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110407
Bug ID: 110407
Summary: [12/13/14 Regression] Overaligned struct return
depending on different versions of GCC
Product: gcc
Version: 14.0
Status: UNCONFIRMED
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
Andrew Pinski changed:
What|Removed |Added
Keywords||ABI
--- Comment #6 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #5 from Andrew Pinski ---
(In reply to ibuclaw from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > >structs have been set the wrong mode
> >
> > No, they don't have wrong mode, just the x86_64 backend is broken, see b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #4 from ibuclaw at gcc dot gnu.org ---
It would be good if TYPE_MODE no longer had such a strong influence though. In
the meantime, I ought to restore behaviour to how it was in 12.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #3 from ibuclaw at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #2)
> >structs have been set the wrong mode
>
> No, they don't have wrong mode, just the x86_64 backend is broken, see bug
> 102027 comment #7 specificall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #2 from Andrew Pinski ---
>structs have been set the wrong mode
No, they don't have wrong mode, just the x86_64 backend is broken, see bug
102027 comment #7 specifically.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #1 from Andrew Pinski ---
Techincally the type mode should not be used by the backend to decide how a
struct is returned or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
Bug ID: 110406
Summary: d: Wrong code-gen returning POD structs by value
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359
--- Comment #5 from CVS Commits ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:ab134ecb05c6cf1d7a0aee58e7649a93a87c9874
commit r10-11475-gab134ecb05c6cf1d7a0aee58e7649a93a87c9874
Author: Iain Buclaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:a0c4bd656e0fce16d62877e0eb53ac11b1924d0c
commit r11-10875-ga0c4bd656e0fce16d62877e0eb53ac11b1924d0c
Author: Iain Buclaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359
--- Comment #3 from CVS Commits ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:0f54a73b998b72f7c8452a63730ec3b16fc47854
commit r12-9730-g0f54a73b998b72f7c8452a63730ec3b16fc47854
Author: Iain Buclaw
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359
--- Comment #2 from CVS Commits ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:9599da719abe4e990fb9cb7ad9d1abc19a5f0429
commit r13-7479-g9599da719abe4e990fb9cb7ad9d1abc19a5f0429
Author: Iain Buclaw
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359
--- Comment #1 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:ab98db1e8c1b997414539f41b7fb814019497d8d
commit r14-2082-gab98db1e8c1b997414539f41b7fb814019497d8d
Author: Iain Buclaw
Date: Mon J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113
--- Comment #12 from CVS Commits ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:016047f54713dc601c661ab57c78a26da3759608
commit r12-9729-g016047f54713dc601c661ab57c78a26da3759608
Author: Iain Buclaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113
--- Comment #11 from CVS Commits ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:ae3a4cefd855512b10b833a56f275b701bacdb34
commit r13-7478-gae3a4cefd855512b10b833a56f275b701bacdb34
Author: Iain Buclaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110403
--- Comment #1 from Janez Zemva ---
Here is a possible workaround:
#define S__(x) ((x) | (x) >> 1 | (x) >> 2 | (x) >> 3 | (x) >> 4)
#define BITCEIL(x) ((x) & (x) - 1 ? (S__(x) & ~(S__(x) >> 1)) << 1 : (x))
template
using array_t __attribute__ (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94617
--- Comment #11 from Andrew Pinski ---
Note funky_bandpass in GCC 13+ no longer produces an imull but rather does
neg/and instead:
movl%edx, %eax
cmpl%edx, %edi
setle %dl
cmpl%esi, %eax
setl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94617
--- Comment #10 from Andrew Pinski ---
For the first function (vanilla_bandpass), GCC 12+ produces now:
movq%rcx, %rax
cmpl%edx, %edi
jg .L2
cmpl%esi, %edx
cmovl %r8, %rax
.L2:
re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89921
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2019-04-03 00:00:00 |2023-6-25
--- Comment #4 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84470
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21474
Andrew Pinski changed:
What|Removed |Added
Known to work||10.1.0, 9.1.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110148
--- Comment #4 from Jan Hubicka ---
zen3 fma requires all inputs to be ready to start execution, separate
multiply+add can start multiplication earlier. Not sure if that explains the
difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87104
--- Comment #15 from Andrew Pinski ---
Note in the original testcase, I noticed we don't do some "VRP/nonzero bits"
optimization so I filed PR 110405 for that. It does not change the other
transformation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110405
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110405
Bug ID: 110405
Summary: missing nonzerobits on branch
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #14 from anlauf at gcc dot gnu.org ---
After r14-2064, gcc-testresults shows the following for big-endian Power
platforms:
Running target unix/-m32
FAIL: gfortran.dg/value_9.f90 -O0 execution test
FAIL: gfortran.dg/value_9.f90 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Summary|Feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375
--- Comment #5 from Giuseppe D'Angelo ---
Done in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404
Bug ID: 110404
Summary: Feature request: make -ftrivial-auto-var-init=zero
zero-initialize, not zero-fill
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #13 from Alexander Monakov ---
Note to self: check how control_flow_insn_p relates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #12 from matoro ---
Just tested applying this patch on top of 13 and it worked! Thanks so much for
the help!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110396
--- Comment #3 from luydorarko at vusra dot com
---
(In reply to Andrew Pinski from comment #2)
> This is basically a dup of bug 102253. The problem is there is a known
> scalability issues with large loop depth.
>
> How did you generate this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402
--- Comment #4 from lsof at mailbox dot org ---
I retract my previous comment about `&v[key] != 0` being possibly false, since
in C it is undefined behavior to perform pointer arithmetic on the null pointer
even with an addend of zero. But I stil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402
--- Comment #3 from lsof at mailbox dot org ---
(In reply to Andrew Pinski from comment #2)
> We warn about:
> ```
> struct m { float *v; int t; };
>
> _Bool chk1(struct m *m, int key) {
> return &m->v[key];
> }
> ```
> ```
> : In function '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110314
--- Comment #5 from Franck Behaghel
---
Marc,
Could you consider and review this patch ?
Regards,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110314
--- Comment #4 from Franck Behaghel
---
Created attachment 55399
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55399&action=edit
patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110400
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98453
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110401
Andrew Pinski changed:
What|Removed |Added
Summary|Unhelpful "goto is not a|[10/11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110403
Bug ID: 110403
Summary: constant expression inside vector_size __attribute__
does not compile
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83172
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402
--- Comment #1 from Andreas Schwab ---
The error message does not match anything from the test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402
Bug ID: 110402
Summary: Bogus -Waddress warning that pointer comparison is
always true
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110401
Bug ID: 110401
Summary: Unhelpful "goto is not a constant expression" in
ill-formed constexpr function template
Product: gcc
Version: 14.0
Status: UNCONFIRMED
54 matches
Mail list logo
