Discussion:
Can FPC at least give a hint/warning?
(too old to reply)
Gennady Agranov
2016-11-07 02:42:34 UTC
Permalink
Raw Message
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





_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Dennis
2016-11-08 05:57:59 UTC
Permalink
Raw Message
Post by Gennady Agranov
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
a compiler warning or hint would be nice.

Dennis

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Marco van de Voort
2016-11-08 10:22:20 UTC
Permalink
Raw Message
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.
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.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Florian Klämpfl
2016-11-08 19:21:21 UTC
Permalink
Raw Message
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
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?
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?
You can reopen it to add the note.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Gennady Agranov
2016-11-08 21:10:36 UTC
Permalink
Raw Message
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
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Jonas Maebe
2016-11-10 07:32:19 UTC
Permalink
Raw Message
Post by Gennady Agranov
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
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.
Post by Gennady Agranov
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.
Post by Gennady Agranov
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
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Loading...