https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115781
--- Comment #8 from Thomas Koenig ---
... or rather, the calculation needs to be done with the
contents of x->_data and not with x directly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47253
--- Comment #18 from H.J. Lu ---
My current patches are at
https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/condjmp/v7?ref_type=heads
They passed GCC bootstrap and tests on x86-64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118993
Bug ID: 118993
Summary: Typo "undfined"
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|needs-stdcheck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
Bug ID: 118994
Summary: GCC fails to optimize (a >> 1) + (b >> 1) + ((a | b) &
1) to PAVGB/PAVGW (or equivalent instruction)
Product: gcc
Version: 14.2.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
Andrew Pinski changed:
What|Removed |Added
Summary|Redundant argument set up |Redundant argument set up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45410
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> I think the real issue is we don't know that printf does not change the
> value of ss.j
Yes and that be shown by:
```
struct s {int i;int j;};
struct s static ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
--- Comment #8 from Thomas Koenig ---
(In reply to anlauf from comment #7)
> (In reply to Thomas Koenig from comment #6)
> > I think the code is valid.
> >
> > A named scalar Fortran variable is interoperable if and only if its type and
> > typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51506
--- Comment #4 from Andrew Pinski ---
Created attachment 60570
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60570&action=edit
C23 testcase
This testcase is similar to what is done for AVR (minus an extra copy which I
have a patch for but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #8)
> (In reply to anlauf from comment #7)
> > (In reply to Thomas Koenig from comment #6)
> > > The length of
> > >
> > > character(kind=c_char, len=*), p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
--- Comment #1 from A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118993
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #6)
> I think the code is valid.
>
> A named scalar Fortran variable is interoperable if and only if its type and
> type parameters are interoperable,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118932
--- Comment #6 from anlauf at gcc dot gnu.org ---
For reference: the thread on the J3 ML starts here:
https://mailman.j3-fortran.org/pipermail/j3/2025-February/015180.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Jerry DeLisle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118993
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
--- Comment #6 from Jerry DeLisle ---
The check is being done in interface.cc. The kind is being checked against
default_integer_kind.
case(2):/* UNIT */
type = BT_INTEGER;
kind = gfc_default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
Bug ID: 118996
Summary: Should TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P return
false for APX?
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89967
Andrew Pinski changed:
What|Removed |Added
Depends on||23782
--- Comment #5 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106
Andrew Pinski changed:
What|Removed |Added
Depends on||14295
--- Comment #7 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89606
Andrew Pinski changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> This is a dup of bug 89606.
>
> *** This bug has been marked as a duplicate of bug 89606 ***
f2 of bug 89606 comment #0 is exactly f2 of this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89606
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #1 from Hongtao Liu ---
Looking at the hook description, it looks like x86 still need nozero return
values under apx (due to AREG, DREG, CREG, BREG, SIREG, DIREG)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #3 from Hongtao Liu ---
Original commit is added to avoid reload failure ~24 years ago, maybe we can
try to remove the check in cse.cc.
commit 8bf4dfc24f1957b8f645e362e354655fb851fc89
Author: Geoffrey Keating
Date: Mon Jul 2 23:2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
--- Comment #4 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #1)
> Looking at the hook description, it looks like x86 still need nozero return
> values under apx (due to AREG, DREG, CREG, BREG, SIREG, DIREG)
Please note that we also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118932
--- Comment #5 from Thomas Koenig ---
The discussion on the J3 mailing list seems to indicate that
this is actually invalid, but nobody else catches it
(and the restriction is also silly).
Maybe we should just downgrade the error to a warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #13 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115781
--- Comment #7 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #6)
After looking at the tree dump and some debugging, it is clear that
the error happens on the callee side.
If the callee has a type as dummy argument, it has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
--- Comment #4 from Eric Botcazou ---
I cannot reproduce. Are there relevant Debian-specific patches applied? How
has the compiler been configured exactly?
I presume that -g does not change anything? If so, can you post the diff of
the ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
Bug ID: 118992
Summary: Redundant argument set up for tail call
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2025-02-23
Version|14.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
--- Comment #12 from anlauf at gcc dot gnu.org ---
So what now?
Ask J3 for an opinion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #3)
> I just circled back on this one. If I modify the test case to explicitly
> define the interface to use integer(8) like this:
[...]
> SUBROUTINE my_wri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116873
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82142
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102672
Bug 102672 depends on bug 82142, which changed state.
Bug 82142 Summary: struct zeroing should use wide stores instead of avoiding
overwriting padding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82142
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630
Bug 32630 depends on bug 102368, which changed state.
Bug 102368 Summary: Failure to compile program using the C_SIZEOF function in
ISO_C_BINDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89967
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |INVALID
Status|N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368
--- Comment #13 from Thomas Koenig ---
(In reply to anlauf from comment #12)
> So what now?
>
> Ask J3 for an opinion?
Why not?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118995
--- Comment #1 from Andrew Pinski ---
Created attachment 60571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60571&action=edit
testcase
next time please attach or place the testcase in-line. Note the attach a file
option has a way to pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118995
Bug ID: 118995
Summary: Missed optimization: [[assume]] works not as good as
std::unreachable()
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102672
--- Comment #4 from Andrew Pinski ---
-fno-tree-sra Fixes it.
There is a dup of this one that I just saw recently too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118995
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82142
--- Comment #4 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:bf0aa9dc8826b1d2a71e52754c117228134825b5
commit r15-7679-gbf0aa9dc8826b1d2a71e52754c117228134825b5
Author: H.J. Lu
Date: Mon Feb 24 05:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34416
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90424
--- Comment #9 from Andrew Pinski ---
Hmm, we get:
BIT_INSERT_EXPR ;
Since r_5 is unintialized, can't we just do:
{_1, 0}
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #3 from H.J. Lu ---
The cse1 pass works on aarch64, but not on x86-64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
--- Comment #18 from Andrew Pinski ---
> Not as easy when the initialized struct contains padding ...
I suspect setting CONSTRUCTOR_ZERO_PADDING_BITS on the constructor will fix the
issue there.
I think we might need it also for optimize_memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
Andrew Pinski changed:
What|Removed |Added
Target||mips*
--- Comment #35 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #5 from H.J. Lu ---
(In reply to H.J. Lu from comment #4)
> (In reply to H.J. Lu from comment #3)
> > The cse1 pass works on aarch64, but not on x86-64.
>
> It is the fwprop1 pass, not the cse1 pass.
It is due to hash_rtx in cse.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #4 from H.J. Lu ---
(In reply to H.J. Lu from comment #3)
> The cse1 pass works on aarch64, but not on x86-64.
It is the fwprop1 pass, not the cse1 pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #6 from H.J. Lu ---
This works for x86-64:
diff --git a/gcc/cse.cc b/gcc/cse.cc
index 70d5caac4ca..786624cd890 100644
--- a/gcc/cse.cc
+++ b/gcc/cse.cc
@@ -2287,6 +2287,10 @@ hash_rtx (const_rtx x, machine_mode mode,
record
61 matches
Mail list logo
