Hi Matt
> On 26 Sep 2021, at 09:10, Matt Jacobson via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>
> Thanks for reviewing. I’m happy to make the suggested changes. One comment
> inline.
>
>> On Sep 22, 2021, at 2:49 PM, Iain Sandoe <i...@sandoe.co.uk> wrote:
>>
>> However, the behaviour is changed - the existing implementation is explicit
>> about the fields and
>> clears the reserved ones (and, ISTR, that was based on what the gcc-4.2.1
>> compiler did).
>
> My original change does in fact clear the reserved bytes on LP64 platforms.
> The padding space compiles down to a `.space` assembler directive, and GNU as
> is documented to fill that space with zeros. So the reserved bits are indeed
> cleared.
Apologies for iterating here ..
So it does, indeed, seem that clang does:
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128”
<snip>
%struct._class_ro_t = type { i32, i32, i32, i8*, i8*, %struct.__method_list_t*,
%struct._objc_protocol_list*,
(for -m64 -fobjc-runtime=macosx -emit-llvm -S)
and,...
target datalayout = "e-m:o-p:32:32-f64:32:64-f80:128-n8:16:32-S128”
<snip>
%struct._class_ro_t = type { i32, i32, i32, i8*, i8*, %struct.__method_list_t*,
%struct._objc_protocol_list*,
(for -m32 -fobjc-runtime=macosx -emit-llvm -S), even if the target platform
will fail to link that (at least macOS will).
So the padding is not explicit in this and will accommodate whatever the target
uses.
Now - to change that such that the previously reserved field could be used on
platforms which don’t have implicit padding would be an ABI break, so isn’t
going to happen by accident (or at all, I imagine).
Since we produce .space for Darwin9 and Darwin10 (where the system compiler is
GCC) I am no longer concerned about dropping the reserved field.
This is a long-winded way of saying that I now think your original approach is
fine, and will put that patch into my testing queue (spot checks only so far)
and apply if all goes without regression.
thanks for the patch,
Iain
