https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #39 from CVS Commits ---
The master branch has been updated by Andreas Krebbel :
https://gcc.gnu.org/g:bc79f0d9048375e402497d5f2ef457c9500310e4
commit r12-8277-gbc79f0d9048375e402497d5f2ef457c9500310e4
Author: Andreas Krebbel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #38 from Segher Boessenkool ---
+ cat test.c
struct foo
{
int : 0;
double a;
int : 0;
double b;
int : 0;
};
extern void func(struct foo);
void
pass_foo(void)
{
struct foo test;
test.a = 114;
test.b = 514;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #37 from CVS Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:413187b0b3c87253838e4afbf8463b288b59
commit r12-7962-g413187b0b3c87253838e4afbf8463b288b59
Author: Xi Ruoyao
Date: Thu Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #36 from CVS Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:0d4b97f1ee5213dffce107bc9f260a22fb23b4b1
commit r12-7961-g0d4b97f1ee5213dffce107bc9f260a22fb23b4b1
Author: Xi Ruoyao
Date: Wed Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #35 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e0ce885851dfd926c0cfe6f23a2debc87ea2bb9d
commit r12-7951-ge0ce885851dfd926c0cfe6f23a2debc87ea2bb9d
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #34 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #33)
> > So in struct B { int : 0; double a, b; }; it will go into GPR and FPR
>
> GCC trunk puts "a" into FPR, not GPR! So the "leading" zero-width
> bit-fields are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #33 from Xi Ruoyao ---
(In reply to Segher Boessenkool from comment #31)
> Well, what do other compilers do? It's not such a good idea to break ABI
> compatibility with the 1990's compilers ;-)
Does someone have access to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #32 from Jakub Jelinek ---
One of the reasons we changed the ABI on various arches one way or another is
that we had this ABI incompatibility between C and C++, that just can't be
right.
At that time we can and should decide if we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #31 from Segher Boessenkool ---
Well, what do other compilers do? It's not such a good idea to break ABI
compatibility with the 1990's compilers ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #30 from Xi Ruoyao ---
(In reply to Jakub Jelinek from comment #28)
> Also, what does LLVM do?
clang-14 agree with gcc-12 on the return values, as we expected (the ABI
documentation is clear enough).
But clang-14 treats arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #29 from Xi Ruoyao ---
> Is there somebody who can clarify the MIPS ABI intent?
> Also, what does LLVM do?
I've CC'ed Yunqiang and Fangrui. And I'll build clang for MIPS to see...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #28 from Jakub Jelinek ---
(In reply to Xi Ruoyao from comment #27)
> (In reply to Jakub Jelinek from comment #23)
>
> > struct A { double a; int : 0; double b; };
>
> For MIPS I've done some experiment with this and the result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #27 from Xi Ruoyao ---
(In reply to Jakub Jelinek from comment #23)
> struct A { double a; int : 0; double b; };
For MIPS I've done some experiment with this and the result (with N64 ABI) is:
With GCC trunk, G++ trunk, and GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #25 from Jakub Jelinek ---
Sorry, apparently I must have misread the mmix below mips as being mips too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #24 from Hans-Peter Nilsson ---
(In reply to Jakub Jelinek from comment #23)
> CCing MIPS maintainers on this (and also LoongArch, while there is no ABI
> incompatibility for a new port, it is perhaps something to discuss and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
Jakub Jelinek changed:
What|Removed |Added
CC||hp at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #22 from Jakub Jelinek ---
So, to sum up:
aarch64, arm, x86-64 and riscv (last one since GCC 10 already) do ignore zero
width bit-fields in argument/return value passing decisions and so have a
C ABI incompatibility from earlier GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #21 from CVS Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:b243ad1afb7f06ef4ab7649600d900b09b9c6b52
commit r12-7896-gb243ad1afb7f06ef4ab7649600d900b09b9c6b52
Author: Richard Earnshaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #20 from CVS Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:3032df28f2a1cc6514571558b76d9b80373b19c6
commit r12-7895-g3032df28f2a1cc6514571558b76d9b80373b19c6
Author: Richard Earnshaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #19 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:568377743e22c1377d0aaa1ac9113da3ff1b6bd4
commit r12-7798-g568377743e22c1377d0aaa1ac9113da3ff1b6bd4
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #17 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3159da6c46568a7c600f78fb3a3b76e2ea4bf4cc
commit r12-6418-g3159da6c46568a7c600f78fb3a3b76e2ea4bf4cc
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #16 from CVS Commits ---
The master branch has been updated by William Schmidt :
https://gcc.gnu.org/g:16e3d6b8b2b5168ebc773833f0e7ccf2191932c1
commit r12-3843-g16e3d6b8b2b5168ebc773833f0e7ccf2191932c1
Author: Bill Schmidt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #15 from Bill Schmidt ---
Jakub, could you add a note with a section ID in
https://gcc.gnu.org/gcc-12/changes.html as was done for the similar case in GCC
10? This allowed us to specify a URL in the informational diagnostic, like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #14 from Jakub Jelinek ---
The generic support is now committed, each backend can decide on what to do
using those flags. That decision should be guided by psABI if it is clear on
those matters, or otherwise ideally the psABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #13 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e902136b310ee17d4b49eb42d9d5e487d5dcf4a1
commit r12-3324-ge902136b310ee17d4b49eb42d9d5e487d5dcf4a1
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #12 from Bill Schmidt ---
Never mind my last comment. Segher pointed out that structure layout is done
early enough that this isn't a problem. I verified this using g++ from GCC 11
and GCC 12 to show that we get correct offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #11 from Bill Schmidt ---
Actually, on further review, I guess we have additional concerns. Unnamed
bitfields also have the effect of updating alignment of the subsequent field of
a structure.
"The types of unnamed bit fields have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #10 from Bill Schmidt ---
Sorry to be late jumping in.
Previously zero bitfields were spuriously removed, now they're being left in
place and matching C. That's very good.
As Jakub shows, the biggest problem is with homogeneous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #9 from Segher Boessenkool ---
(In reply to Michael Matz from comment #8)
> So, I think, not removing those members from the FE makes sense, they contain
> crucial information. Unfortunately that means that they need to be dealt
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #8 from Michael Matz ---
The only thing the x86-64 psABI says about this case is "'Unnamed bit-fields'
types do not affect the alignment of a structure or union." .
(zero-width bit-fields are _always_ unnamed)
But the x86-64 psABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #6 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #5)
> "structure layout happens before the zero width bitfields are removed by the
> FE".
>
> So, what can break still, then?
Homogeneous aggregates can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #5 from Segher Boessenkool ---
"structure layout happens before the zero width bitfields are removed by the
FE".
So, what can break still, then?
- li 9,0
- sldi 9,9,32
- mtvsrd 1,9
+ li 3,0
std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
Jakub Jelinek changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #1 from Jakub Jelinek ---
clang and clang++ on x86_64 ignore the zero width bitfields, so work similarly
to C++ in GCC < 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
40 matches
Mail list logo
