On Thu, Aug 19, 2021 at 08:59:16AM +0200, Christophe Lyon wrote:
> This patch ( r12-2975) is causing regressions on arm and aarch64:
>
> g++:g++.target/aarch64/aarch64.exp=g++.target/aarch64/no_unique_address_1.C
> check-function-bodies _Z8caller_pR1P
>
> g++:g++.target/aarch64/aarch64.exp=g++.target/aarch64/no_unique_address_2.C
> (test for warnings, line 169)
>
> g++:g++.target/aarch64/aarch64.exp=g++.target/aarch64/no_unique_address_2.C
> check-function-bodies _Z8caller_pR1P
>
> g++:g++.target/arm/arm.exp=g++.target/arm/no_unique_address_1.C
> check-function-bodies _Z8caller_pR1P
> g++:g++.target/arm/arm.exp=g++.target/arm/no_unique_address_2.C (test
> for warnings, line 163)
> g++:g++.target/arm/arm.exp=g++.target/arm/no_unique_address_2.C
> check-function-bodies _Z8caller_pR1P
The only change in the patch that affects this is the removal of the
remove_zero_width_bit_fields function and call to it in layout_class_type.
As I've tried to explain, that has been done as some kind of optimization
by the C++ FE only (e.g. the C FE doesn't do that), but because it is
significant for layout compatibility and its traits, it is no longer
something that can be done (at least not by the FE).
The optimized dump from the test is identical, it is just the aarch64
(and arm?) backend handling of those, and results e.g. on the first test in:
_Z8caller_pR1P:
.LFB15:
- ldp s0, s1, [x0]
- ldp s2, s3, [x0, 8]
+ ldp x0, x1, [x0]
b _Z8callee_p1P
difference, where P does have int : 0; bitfield in it.
Though, if the r10-8042-g56fe3ca30e1343e4f232ca539726506440e23dd3
and r10-8044-g127abeb2e8448b2932bd52245f055d0c5c4b44a0 patches were about
the handling of zero width bitfields, I don't see how that could have
worked properly when the FE would just throw them away, so the
backend wouldn't know if they were there or not.
Richard, can you please have a look?
Jakub
