GNAT "alignment value must be positive"

GNAT "alignment value must be positive"

[marciant]

So, what is the reason that GNAT does not accept "s'alignment use 0;" on intel x86 systems? I recently read that Alignment_Check is now "no" by default for such systems - but making that configuration setting on GNAT GPL 2014 does not seem to make any difference on the code in question. Is there a different setting to allow items not necessarily aligned to byte boundaries other than setting GNAT to ignore the representation clause?

Re: GNAT "alignment value must be positive"

[Shark8]

It's because "alignment 0" corresponds to an internal divide-by-zero error.
The LRM (13.4) gives the definition of the alignment portion of record-specification as:

      alignment_clause ::= at mod static_simple_expression;

So, "mod 0" is obviously erroneous in that case... however, that is the special case of records; in-general what we want is found in 13.3 which says, in part:

22/2  For a prefix X that denotes an object: 
23/2  X'Alignment
      The value of this attribute is of type universal_integer, and nonnegative; zero means that the object is not necessarily aligned on a storage element boundary. If X'Alignment is not zero, then X is aligned on a storage unit boundary and X'Address is an integral multiple of X'Alignment (that is, the Address modulo the Alignment is zero).

So, here the 0-alignment means that there is no imposed alignment WRT storage-element boundaries.

-----------

All that said, it could be a bug where GNAT treats an aspect differently than the corresponding representation-clause/pragma.

Re: GNAT "alignment value must be positive"

[marciant]

Additional information:
(1) The alignment clause is for a record type,
(2) Ada95 mode is being used,

Additional analysis:
GNAT's sem_ch13.adb code unconditionally rejects zero for the alignment and thus seems to unconditionally not support items not necessarily aligned to byte boundaries.  If that is the case then it would help if such a decision was documented in GNAT's implementation specific documentation: section 14 of the GNAT reference manual. (Maybe it is elsewhere I missed it. Did I?)

Re: GNAT "alignment value must be positive"

[marciant]

On Monday, April 6, 2015 at 4:48:18 PM UTC-4, Shark8 wrote:
> It's because "alignment 0" corresponds to an internal divide-by-zero error.
> The LRM (13.4) gives the definition of the alignment portion of record-specification as:
> 
>       alignment_clause ::= at mod static_simple_expression;
> 
> So, "mod 0" is obviously erroneous in that case...

I'm not sure that it is obvious in that case: "at mod" is just the
syntax. I do not think that it means that the compiler is required
to evaluate "mod 0".  By the way, Object Ada 7.2.x (Ada 95) has
accepted alignment 0 for all of the record types that have it.

Also, having read your reply (thanks) I realize that I should have
included more information in my original post: Ada95 mode is being
used and the alignment clause is for a record type.

> however, that is the special case of records; in-general what we want is found in 13.3 which says, in part:
> 
> 22/2  For a prefix X that denotes an object: 
> 23/2  X'Alignment
>       The value of this attribute is of type universal_integer, and nonnegative; zero means that the object is not necessarily aligned on a storage element boundary. If X'Alignment is not zero, then X is aligned on a storage unit boundary and X'Address is an integral multiple of X'Alignment (that is, the Address modulo the Alignment is zero).
> 
> So, here the 0-alignment means that there is no imposed alignment WRT storage-element boundaries.

That is what was desired/expected for all objects or record components of the types in question.

> 
> -----------
> 
> All that said, it could be a bug where GNAT treats an aspect differently than the corresponding representation-clause/pragma.

Re: GNAT "alignment value must be positive"

[Jeffrey Carter]

On 04/07/2015 08:27 AM, marciant@earthlink.net wrote:
> Additional information:
> (1) The alignment clause is for a record type,
> (2) Ada95 mode is being used,
> 
> Additional analysis:
> GNAT's sem_ch13.adb code unconditionally rejects zero for the alignment and thus seems to unconditionally not support items not necessarily aligned to byte boundaries.  If that is the case then it would help if such a decision was documented in GNAT's implementation specific documentation: section 14 of the GNAT reference manual. (Maybe it is elsewhere I missed it. Did I?)

The Ada-95 ARM 13.3 includes the statement given earlier for the Alignment
attribute: "The value of this attribute is of type universal_integer, and
nonnegative; zero means that the object is not necessarily aligned on a storage
element boundary."

However, note also the additional requirements for a composite type: "If an
Alignment is specified for a composite subtype or object, this Alignment shall
be equal to the least common multiple of any specified Alignments of the
subcomponent subtypes, or an integer multiple thereof." If your record has
components with specified non-zero alignment, then the alignment of the record
must be non-zero.

Finally, J.8 says that

for R use record at mod a
   ...
end record;

is equivalent to

for R'Alignment use a;
For R use record
   ...
end record;

So zero should be allowed in this obsolescent form as well.

If GNAT is rejecting zero when allowed by these rules then it would seem to be a
compiler error.

-- 
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72

Re: GNAT "alignment value must be positive"

[marciant]

On Tuesday, April 7, 2015 at 2:47:01 PM UTC-4, Jeffrey Carter wrote:

<snip> 

> So zero should be allowed in this obsolescent form as well.
> 
> If GNAT is rejecting zero when allowed by these rules
> then it would seem to be a compiler error.

I'm linking that also.  If I do not see any better explanation here then I will write a note to AdaCore.  Also here is a "made up" package that exhibits the issue and the compilation messages that GNAT puts out
(I also did some editing after I pasted to this message and hopefully
did not mess up the code-message correspondence):

package Nonaligned_Type_Definitions is

   type Nonaligned_Record_Component_0 is range -4 .. 4;
   for  Nonaligned_Record_Component_0'size      use 4;
   for  Nonaligned_Record_Component_0'alignment use 0;

   type Nonaligned_Record_Component_2 is range -32768 .. 32767;
   for  Nonaligned_Record_Component_2'size      use 16;
   for  Nonaligned_Record_Component_2'alignment use  0;

   type Nonaligned_Record is
      record
         Component_0a : Nonaligned_Record_Component_0;
         Component_0b : Nonaligned_Record_Component_0;
         Component_2  : Nonaligned_Record_Component_2 range 0..9999;
      end record;
   for Nonaligned_Record use
      record
         at mod 0;
         --  ignoring at 0 range  0 ..  0
         Component_0a at 0 range  1 ..  4;
         --  ignoring at 0 range  5 ..  7
         Component_0b at 0 range  8 .. 11;
         --  ignoring at 0 range 12 .. 15
         Component_2  at 2 range  0 .. 15;
      end record;
   for Nonaligned_Record'size use 32;

end Nonaligned_Type_Definitions;

GNAT output:
Nonaligned_Type_Definitions.ads:5:53: alignment value must be positive
Nonaligned_Type_Definitions.ads:9:54: alignment value must be positive
Nonaligned_Type_Definitions.ads:20:17: alignment value must be positive
gnatmake: "Nonaligned_Type_Definitions.ads" compilation error

Re: GNAT "alignment value must be positive"

[Randy Brukardt]

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:mg18lb$r36$1@dont-email.me...
...
> However, note also the additional requirements for a composite type: "If 
> an
> Alignment is specified for a composite subtype or object, this Alignment 
> shall
> be equal to the least common multiple of any specified Alignments of the
> subcomponent subtypes, or an integer multiple thereof." If your record has
> components with specified non-zero alignment, then the alignment of the 
> record
> must be non-zero.

This requirement is nonsense and was deleted from the language for Ada 2005. 
And few compilers ever enforced it (Janus/Ada did, but GNAT did not, so far 
as I know). It probably would have been deleted sooner had I asked about it 
rather than just implementing it as the rule. The intent is that any 
"inherited" properties can always be overridden by a explicitly specified 
property.

...
> So zero should be allowed in this obsolescent form as well.
>
> If GNAT is rejecting zero when allowed by these rules then it would seem 
> to be a
> compiler error.

I don't think Janus/Ada allows specifying zero, but that makes some sense as 
no stand-alone object could ever be allocated at a non-byte-aligned address. 
Nor would that ever happen for a component in the absence of some other 
representation item. So there is nothing that could actually be aligned as 
"zero". Perhaps GNAT is making the same assumption.

0 is defined as a possible alignment so that the alignment of a bit-mapped 
component is meaningful (we can't have 'Alignment not meaning anything). But 
I don't know of any reason to specify the alignment as zero, everything is 
always byte allocated by default. There might be some machine on which it 
makes sense to not byte align by default, but I haven't encountered it to 
date.

                                          Randy.

Re: GNAT "alignment value must be positive"

[Randy Brukardt]

I said:
...
> 0 is defined as a possible alignment so that the alignment of a bit-mapped 
> component is meaningful (we can't have 'Alignment not meaning anything). 
> But I don't know of any reason to specify the alignment as zero, 
> everything is always byte allocated by default. There might be some 
> machine on which it makes sense to not byte align by default, but I 
> haven't encountered it to date.

I should have added that the Recommended Level of Support does seem to 
require supporting that (probably should have read it before pushing 
"send"!), so in that sense, it's a GNAT bug to not allow it. But 
practically, 0 and 1 are the same for a specified alignment; nothing is 
going to be different about the default allocation, so it's doesn't really 
matter.

                                            Randy.

Re: GNAT "alignment value must be positive"

[marciant]

On Wednesday, April 8, 2015 at 4:35:23 PM UTC-4, Randy Brukardt wrote:
> ...
>
> I should have added that the Recommended Level of Support does seem to 
> require supporting that (probably should have read it before pushing 
> "send"!), so in that sense, it's a GNAT bug to not allow it. But 
> practically, 0 and 1 are the same for a specified alignment; nothing is 
> going to be different about the default allocation, so it's doesn't really 
> matter.
> 
>                                             Randy.

Are you saying that it is not necessary to specify alignment zero for records that end up specifying components of enclosing records whose layout is being fully "rep-spec'd" (pragma Pack is not being used?).
Is it not (no longer?) necessary to ever indicate - as per Ada 95 RM 13.3 [14] - "zero means that the object is not necessarily aligned on a storage element boundary."?  Should "object" in the above really be "subtype" or object?  Is it no necessary to indicate "not necessarily aligned on a storage element boundary" for anything?

I know that those are a lot of questions but I am trying to understand enough to gain "full command" of this aspect of the language: I have always (at this point about 25 years!) been very interested in hardware and communication interface design in Ada.

Re: GNAT "alignment value must be positive"

[Randy Brukardt]

<marciant@earthlink.net> wrote in message 
news:ac4c104c-ebcc-4132-9c53-783dfc083891@googlegroups.com...
>On Wednesday, April 8, 2015 at 4:35:23 PM UTC-4, Randy Brukardt wrote:
>> ...
>>
>> I should have added that the Recommended Level of Support does seem to
>> require supporting that (probably should have read it before pushing
>> "send"!), so in that sense, it's a GNAT bug to not allow it. But
>> practically, 0 and 1 are the same for a specified alignment; nothing is
>> going to be different about the default allocation, so it's doesn't 
>> really
>> matter.
>>
>>                                             Randy.
>
>Are you saying that it is not necessary to specify alignment zero for
> records that end up specifying components of enclosing records whose
> layout is being fully "rep-spec'd" (pragma Pack is not being used?).

It never was.

> Is it not (no longer?) necessary to ever indicate - as per Ada 95 RM 13.3 
> [14]

This paragraph is about "Address", not sure as to what you're referring.

But the Ada 95 wording for Alignment contained a lot of nonsense. It was 
mostly rewritten for Ada 2005, as Binding Interpretation (meaning it applies 
to Ada 95 compilers as well), so reading the original wording does nothing 
but confuse yourself and everyone else.

> - "zero means that the object is not necessarily aligned on a storage 
> element
> boundary."?

That's talking about the value of X'Alignment, when it is *read*, not so 
much when it is specified. (This is 13.3(23/2)).
>  Should "object" in the above really be "subtype" or object?  Is it no 
> necessary
> to indicate "not necessarily aligned on a storage element boundary" for 
> anything?

No, the subtype wording is completely separate, because (as I noted), the 
old wording was nonsense. I'm not going to try to explain old nonsense. If 
we could have explained it, we wouldn't have rewritten it!

> I know that those are a lot of questions but I am trying to understand 
> enough to
> gain "full command" of this aspect of the language: I have always (at this 
> point
> about 25 years!) been very interested in hardware and communication 
> interface
> design in Ada.

Then read the current RM, not older, buggier versions. The bleeding edge can 
be found at: http://www.ada-auth.org/standards/ada2x.html (this contains 
everything the ARG has approved to date). Ada 2012 can be found at: 
http://www.ada-auth.org/arm.html.

People discover bugs in the RM all the time, and the ARG fixes them 
periodically. It's often impossible to explain the original wording, because 
it didn't make sense for one reason or another. There's a reason that newer 
standard replace the older ones (even if that doesn't always happen 
practically).

                                         Randy.

Re: GNAT "alignment value must be positive"

[marciant]

On Thursday, April 9, 2015 at 8:21:55 PM UTC-4, Randy Brukardt wrote:
... 

> > Is it not (no longer?) necessary to ever indicate - as per Ada 95 RM 13.3 
> > [14]
> 
> This paragraph is about "Address", not sure as to what you're referring.

Sorry that should have been [24] not [14], as in Ada 95 RM 13.3 [24].

By the way, the project that is still using a compiler that was made
more that ten years ago and we all have copies of RM95;6.0 to read, not
the newer RM.

> But the Ada 95 wording for Alignment contained a lot of nonsense. It was 
> mostly rewritten for Ada 2005, as Binding Interpretation (meaning it applies 
> to Ada 95 compilers as well), so reading the original wording does nothing 
> but confuse yourself and everyone else.

Unfortunately, updating the RM does not cause the project to have access
to an updated compiler. :)

> 
> > - "zero means that the object is not necessarily aligned on a storage 
> > element
> > boundary."?
> 
> That's talking about the value of X'Alignment, when it is *read*, not so 
> much when it is specified. (This is 13.3(23/2)).

But if the "natural"/"default" alignment that an implementation would use when it places an object of some type is - lets say 2, what about the case that a user program  does unchecked conversion on a sequence of bits to a record type that ends up making the alignment of some of the records components not have the default alignment (not 2 in the example - infact not even alignment 1).
I thought that this was a case where the user should specify alignment 0 for the component's type and that without doing that, improper reading of the component by the program might be the result, due to the compiler having assumed that the component/"object" had its default alignment. 

> ...
> old wording was nonsense. I'm not going to try to explain old nonsense. If 
> we could have explained it, we wouldn't have rewritten it!

Okay, that is fair enough.
 
> ...
> 
> Then read the current RM, not older, buggier versions. The bleeding edge can 
> be found at: http://www.ada-auth.org/standards/ada2x.html (this contains 
> everything the ARG has approved to date). Ada 2012 can be found at: 
> http://www.ada-auth.org/arm.html.
> 
> People discover bugs in the RM all the time, and the ARG fixes them 
> periodically. It's often impossible to explain the original wording, because 
> it didn't make sense for one reason or another. There's a reason that newer 
> standard replace the older ones (even if that doesn't always happen 
> practically).

I know about the http://www.ada-auth.org RM archive and also read the ARG meeting minutes when each new one is posted (Thank you for your great work on that!)

Vinny

Re: GNAT "alignment value must be positive"

[Randy Brukardt]

<marciant@earthlink.net> wrote in message 
news:ae527812-cf69-4141-8cdb-7d44f0be19a3@googlegroups.com...
On Thursday, April 9, 2015 at 8:21:55 PM UTC-4, Randy Brukardt wrote:
...
...
>> > - "zero means that the object is not necessarily aligned on a storage
>> > element
>> > boundary."?
>>
>> That's talking about the value of X'Alignment, when it is *read*, not so
>> much when it is specified. (This is 13.3(23/2)).
>
>But if the "natural"/"default" alignment that an implementation would use 
>when it
>places an object of some type is - lets say 2, what about the case that a 
>user
>program  does unchecked conversion on a sequence of bits to a record type
>that ends up making the alignment of some of the records components not 
>have
>the default alignment (not 2 in the example - infact not even alignment 1).
>I thought that this was a case where the user should specify alignment 0 
>for the
>component's type and that without doing that, improper reading of the 
>component
>by the program might be the result, due to the compiler having assumed that 
>the
>component/"object" had its default alignment.

That's clearly target dependent. On the x86 where I've done most of my work, 
alignment has no impact on the code (it does have an impact on performance). 
Everything is at least byte-aligned (objects are copied to make that so for 
parameter passing, and of course, unaligned by-reference objects aren't 
allowed), and the machine has no problem with unaligned accesses. (Well, 
there are some of the rarely-used vector operations that only work on 
aligned data; that's one reason why we don't use them. :-)

There certainly are targets that differ; at least in theory. That's not 
surprising, ultimately Chapter 13 is all about target-dependent stuff 
anyway. But even then, I'd expect (in your example) the Unchecked_Conversion 
to make a copy so the proper alignment is maintained. It's a function after 
all, the semantics are that of a copy (there's a permission to make it 
by-reference, but an implementor would be silly to use such a permission if 
it caused later code problems).

                                  Randy.