https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|AS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #15 from CVS Commits ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:f2eeda5652438fe783d4e3878139481a1b8606b6
commit r13-7496-gf2eeda5652438fe783d4e3878139481a1b8606b6
Author: Iain Buclaw
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #14 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:c201cd3be0d9ab887fafb0c33a9fc287c405c21c
commit r14-2169-gc201cd3be0d9ab887fafb0c33a9fc287c405c21c
Author: Iain Buclaw
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-06-28
Ever confirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #12 from Iain Sandoe ---
OTOH there was a second issue with zero-sized objects which was fixed thus:
diff --git a/gcc/d/types.cc b/gcc/d/types.cc
index a1f69bb02b7..020cc7de83f 100644
--- a/gcc/d/types.cc
+++ b/gcc/d/types.cc
@@ -58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #10 from ibuclaw at gcc dot gnu.org ---
Looking at an ICE in stage2 D compiler for i686-darwin17, I realized that it's
another facet of this issue.
// aggregate.d
import dsymbol;
extern (C++) class AggregateDeclaration : ScopeDsymbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #9 from ibuclaw at gcc dot gnu.org ---
(In reply to ibuclaw from comment #8)
> So long as C and D agree with each other when it comes to POD types, it
> almost doesn't matter to me weather the back-end is following the wrong ABI.
Or w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406
--- Comment #8 from ibuclaw at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #7)
> (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 bac
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=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.
15 matches
Mail list logo
