Hi,

I have submitted a bug - http://bugs.freepascal.org/view.php?id=30872 (misaligned data exception on ARMv7)

And this big was resolved as "won't fix"

1. I understand that one has to work really hard to encounter this bug - and there are easy workarounds, but it there are also different ways to resolve this bug - e.g. just giving a hint would suffice - IMHO

2. All our units use {$PACKRECORDS 1} in order to be layout compatible with Delphi and we always can add padding or change the field order - if only compiler warned us that field is not properly aligned for the target platform...

3. And a separate question - if the bug is closed - is there any way to add a note to it?

Thank you very much,

Gennady

a compiler warning or hint would be nice.

Dennis

Alignment was a major issue back when SPARC was still a realistically viable platform.

The Solaris and C communities appeared to take the line that a correct compiler "could not" generate unaligned accesses, although they held off clarifying whether "could" in that context means "if it does it's an error" or "it must rearrange data to avoid an error".

I believe that Solaris and in some cases Linux can handle unaligned accesses in the kernel, although there's obviously a significant performance penalty.

Working on the principle that the FPC community would do well to avoid antagonising people with expectations derived from experience with other compilers and languages, I'd suggest that a warning when potentially-misaligned code is generated is in order.

In our previous episode, Mark Morgan Lloyd said:

I can remember the early powerpc ports where I came into trouble with the NetBSD port because the Linux kernel used emulation to fix unaligned float loads/stores, while NetBSD didn't.

I believe the Linux ARM kernel can intercept some alignment traps, the SPARC kernel can do something similar but only for kernel code (I don't know whether that will change with the current push to get Debian onto SPARC-64, it could be an artifact of the kernel being 64-bit but the userspace 32-bit).

While this is possible, if you - as said below - use packrecords 1, you will get a hint on every use of such a cardinal as the compiler normally does not know the final address of a variable in a program but only its alignment requirements. So even if a cardinal is the first element of a such a record, the compiler cannot assume that this field is actually properly aligned because packrecords 1 relaxes also the alignment requirements of the whole record, so the record itself might be start at an unaligned address. This makes imo such a hint useless. Or what are the conditions when you want to emit the hint?

You can reopen it to add the note.

Hi,

>> Or what are the conditions when you want to emit the hint?

I thought that hint could come from some layer that actually allocates the record - on the stack or on the heap - this layer may actually know the "effective" alignment

Heap allocation should be aligned to the largest required alignment (is it 8?) - i.e. it should relatively simple to validate that offset of some "double" field is properly aligned

I actually do not know how stack allocation works - i.e. when and how compiler aligns double, extended or record values (packed or unpacked)

So if in your opinion this hint would report too many false positives - case is closed :)

>> if the bug is closed - is there any way to add a note to it?

Yes, I found this button after I have went to the URL again and inspected the available UI more thorough :(
I did not want to send another e-mail to FPC list - that I have found it :)

Sorry about it,
Gennady

The compiler does not know where a pointer comes from when it is used. It may be the result of a getmem call, of getting the address of an unaligned field, or of manual pointer arithmetic. Additionally, the memory manager may have been overridden and may return anything it wants.

I actually do not know how stack allocation works - i.e. when and how compiler aligns double, extended or record values (packed or unpacked)

The guaranteed alignment of the start of a record declared with {$packrecords X} is at most a multiple of X, regardless of the type of its fields. The reasoning is that aligning a record when you don't guarantee the same alignment in the record itself, is kind of misleading (even if it helps initially to get some field aligned, any change to the record could break this) and probably wasteful.

So if in your opinion this hint would report too many false positives - case is closed :)

It's not only about false positives, but also about the fact that it would be impossible to get rid of this hint/warning when you have determined that the caller can deal with the unaligned data.

Jonas