Gnat 3.15p pragma issues

Gnat 3.15p pragma issues

[Erik Woulfe]

I am attempting to move a large amount of code from an Apex compiler
system to the Gnat 3.15p compiler in order to gain more flexibility in
mutli-language code interaction (namely between C++ and Ada). One of
the problems that I encounter when making this move is that the Gnat
compiler does not recognize many of the pragma statements that Apex had
no problems with. However, I do not think that any/all of these are
Apex specific, such as pragma "Inline" and pragma "Not_Elaborated". Has
anyone had any experience with having common pragmas not being
recognized? Am I perhaps not referencing the correct libraries in my
gnatmake call?

Thanks for any help.

Re: Gnat 3.15p pragma issues

[Colin Paul Gloster]

A compiler is not obliged to implement a pragma.

Re: Gnat 3.15p pragma issues

[Gautier Write-only]

Erik Woulfe wrote:

> I am attempting to move a large amount of code from an Apex compiler
> system to the Gnat 3.15p compiler in order to gain more flexibility in
> mutli-language code interaction (namely between C++ and Ada). One of
> the problems that I encounter when making this move is that the Gnat
> compiler does not recognize many of the pragma statements that Apex had
> no problems with. However, I do not think that any/all of these are
> Apex specific, such as pragma "Inline" and pragma "Not_Elaborated". Has
> anyone had any experience with having common pragmas not being
> recognized? Am I perhaps not referencing the correct libraries in my
> gnatmake call?
> 
> Thanks for any help.

The standard pragma Inline is recognized by GNAT (since 3.07p or 3.10p at latest), but in order to make it active cross-unit, you need to compile with the -gnatn switch.

HTH
______________________________________________________________ 
Gautier     --     http://www.mysunrise.ch/users/gdm/index.htm 
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm 

NB: For a direct answer, e-mail address on the Web site!

Re: Gnat 3.15p pragma issues

[Robert A Duff]

Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> writes:

> A compiler is not obliged to implement a pragma.

Compilers are obliged to implement the language defined pragmas as
specified in the RM.   What this means in practise depends on the
pragma.  Pragma Inline can legally be ignored, and in fact all
implementations ignore pragma Inline in some cases.  Pragma
Elaborate_Body, on the other hand, has a very specific meaning,
and compilers must implement it.

Then there are implementation-defined pragmas.  Compilers are not
obliged to implement each other's implementation-defined pragmas (of
course!).

- Bob

Re: Gnat 3.15p pragma issues

[Robert A Duff]

"Erik Woulfe" <DMBTonic@AOL.com> writes:

> I am attempting to move a large amount of code from an Apex compiler
> system to the Gnat 3.15p compiler in order to gain more flexibility in
> mutli-language code interaction (namely between C++ and Ada). One of
> the problems that I encounter when making this move is that the Gnat
> compiler does not recognize many of the pragma statements that Apex had
> no problems with. However, I do not think that any/all of these are
> Apex specific, such as pragma "Inline" and pragma "Not_Elaborated". Has
> anyone had any experience with having common pragmas not being
> recognized?

Pragma Inline is defined by the language.  Not_Elaborated is
implementation defined.  There is a list of language-defined pragmas in
the back of the RM.  To know whether it's safe to simply delete
implementation-defined pragmas, you'll have to look at the Apex
documentation.  Some pragmas are "merely" optimization hints,
for example.

>... Am I perhaps not referencing the correct libraries in my
> gnatmake call?

No, that probably has nothing to do with it.

- Bob

pragma Convention ignored (sometimes)

[Anonymous Coward]

In article <wccbr11gx1l.fsf@shell01.TheWorld.com>, Robert A Duff wrote:
> Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> writes:
> 
>> A compiler is not obliged to implement a pragma.
> 
> Compilers are obliged to implement the language defined pragmas as
> specified in the RM.   What this means in practise depends on the
> pragma.  

What about Pragma Convention?

I've noticed that gnat will sometimes honor a pragma convention on an
enumerated type (which means extending the size to 32 bits on an x86
platform), but in other cases it seems to ignore the pragma
convention.  ie, the following code:

  type Some_Enum_Type is (one, two, three);

  pragma Convention (Convention => C, Entity => Some_Enum_Type);

should create a 32 bit enum, but in fact doing a 'size reveals that
it's 2 bits!

Re: Gnat 3.15p pragma issues

[Steve]

"Erik Woulfe" <DMBTonic@AOL.com> wrote in message 
news:1131029395.700984.154230@f14g2000cwb.googlegroups.com...
>I am attempting to move a large amount of code from an Apex compiler
> system to the Gnat 3.15p compiler in order to gain more flexibility in
> mutli-language code interaction (namely between C++ and Ada). One of
> the problems that I encounter when making this move is that the Gnat
> compiler does not recognize many of the pragma statements that Apex had
> no problems with. However, I do not think that any/all of these are
> Apex specific, such as pragma "Inline" and pragma "Not_Elaborated". Has
> anyone had any experience with having common pragmas not being
> recognized? Am I perhaps not referencing the correct libraries in my
> gnatmake call?
>
> Thanks for any help.
>

Since it isn't any longer than a long winded post, here's the list of 
language defined pragmas from the LRM:

Annex L (informative): Language-Defined Pragmas

1 This Annex summarizes the definitions given elsewhere of the 
language-defined pragmas.

2 pragma All_Calls_Remote[(library_unit_name)]; - See E.2.3.
3 pragma Asynchronous(local_name); - See E.4.1.
4 pragma Atomic(local_name); - See C.6.
5 pragma Atomic_Components(array_local_name); - See C.6.
6 pragma Attach_Handler(handler_name, expression); - See C.3.1.

7 pragma Controlled(first_subtype_local_name); - See 13.11.3.
8 pragma Convention([Convention =>] convention_identifier,[Entity =>] 
local_name); - See B.1.
9 pragma Discard_Names[([On => ] local_name)]; - See C.5.
10 pragma Elaborate(library_unit_name{, library_unit_name}); - See 10.2.1.

11 pragma Elaborate_All(library_unit_name{, library_unit_name}); - See 
10.2.1.
12 pragma Elaborate_Body[(library_unit_name)]; - See 10.2.1.
13 pragma Export( [Convention =>] convention_identifier, [Entity =>] 
local_name [, [External_Name =>] string_expression] [, [Link_Name =>] 
string_expression]
); - See B.1.

14 pragma Import( [Convention =>] convention_identifier, [Entity =>] 
local_name [, [External_Name =>] string_expression] [, [Link_Name =>] 
string_expression]
); - See B.1.
15 pragma Inline(name {, name}); - See 6.3.2.
16 pragma Inspection_Point[(object_name {, object_name})]; - See H.3.2.

17 pragma Interrupt_Handler(handler_name); - See C.3.1.
18 pragma Interrupt_Priority[(expression)]; - See D.1.
19 pragma Linker_Options(string_expression); - See B.1.
20 pragma List(identifier); - See 2.8.
21 pragma Locking_Policy(policy_identifier); - See D.3.

22 pragma Normalize_Scalars; - See H.1.
23 pragma Optimize(identifier); - See 2.8.
24 pragma Pack(first_subtype_local_name); - See 13.2.
25 pragma Page; - See 2.8.
26 pragma Preelaborate[(library_unit_name)]; - See 10.2.1.
27 pragma Priority(expression); - See D.1.

28 pragma Pure[(library_unit_name)]; - See 10.2.1.
29 pragma Queuing_Policy(policy_identifier); - See D.4.
30 pragma Remote_Call_Interface[(library_unit_name)]; - See E.2.3.
31 pragma Remote_Types[(library_unit_name)]; - See E.2.2.
32 pragma Restrictions(restriction{, restriction}); - See 13.12.

33 pragma Reviewable; - See H.3.1.
34 pragma Shared_Passive[(library_unit_name)]; - See E.2.1.
35 pragma Storage_Size(expression); - See 13.3.
36 pragma Suppress(identifier [, [On =>] name]); - See 11.5.
37 pragma Task_Dispatching_Policy(policy_identifier ); - See D.2.2.

38 pragma Volatile(local_name); - See C.6.
39 pragma Volatile_Components(array_local_name); - See C.6.


Steve
(The Duck) 

Re: pragma Convention ignored (sometimes)

[Jeffrey R. Carter]

Anonymous Coward wrote:

>   type Some_Enum_Type is (one, two, three);
> 
>   pragma Convention (Convention => C, Entity => Some_Enum_Type);
> 
> should create a 32 bit enum, but in fact doing a 'size reveals that
> it's 2 bits!

By default, 'Size on a subtype gives the minimum # of bits to represent the 
values of the type. In this case, that would be 2. 'Size of an object is 
something else, and in this case is probably more like what you expect. Without 
the pragma Convention, I'd expect it to be 8 on x86 targets.

As an example, with GNAT, Integer'Size is 32 and Natural'Size is 31. An object 
of subtype Natural, however, is usually 32 bits.

If you explicitly define the size of a subtype (for X'Size use 23;), then 'Size 
on the subtype should give the defined value.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: Gnat 3.15p pragma issues

[Stephen Leake]

"Erik Woulfe" <DMBTonic@AOL.com> writes:

> One of the problems that I encounter when making this move is that
> the Gnat compiler does not recognize many of the pragma statements
> that Apex had no problems with. However, I do not think that any/all
> of these are Apex specific, such as pragma "Inline" and pragma
> "Not_Elaborated".

Can you give an example of such code, together with the error message
GNAT 3.15p produces?

I've used GNAT 3.15p with lots of 'pragma Inline'.

On the other hand, 'pragma Not_Elaborated' is _not_ standard Ada;
search for it in the Ada Reference Manual - you won't find it.

-- 
-- Stephe

Re: pragma Convention ignored (sometimes)

[Justin Gombos]

In article <lbCaf.5450$Rl1.1293@newsread1.news.pas.earthlink.net>, Jeffrey R. Carter wrote:
> 
> By default, 'Size on a subtype gives the minimum # of bits to
> represent the values of the type. In this case, that would be
> 2. 'Size of an object is something else, and in this case is
> probably more like what you expect. Without the pragma Convention,
> I'd expect it to be 8 on x86 targets.

Why would 'size on a four element enum return a different number than
a 'size on a three element enum?  Regardless of whether 'size reports
object size or value size, it should not give me inconsistent
answers.  

At the moment I'm having trouble reconstructing this problem in an
isolated example, but I know I witnessed a case (when I was at work)
where 'size reported 8 bits for one enum, and 32 bits for another
comparably sized enum (like around five elements), both of which had a
pragma Convention clause.  

You're not suggesting that 'size reports object size in some cases,
and value size in other cases, are you?  (btw- I intend to stop
printing 'size with the ADA_IO package now that I know about -gnatR).

I'll see if I can isolate a case where pragma Convention fails later.
In the meantime, here's a working working example:

When this code:

   procedure Enum is

      type My_Enum is (One, Two, Three);
      
   begin
      null;
   end Enum;

is compiled with -gnatR3, gcc produces:

   $ gcc -c -gnatR3 enum.adb
    
   Representation information for unit Enum (body)
   -----------------------------------------------
    
   for My_Enum'Object_Size use 8;
   for My_Enum'Value_Size use 2;
   for My_Enum'Alignment use 1;

while this code:

   procedure Enum is

      type My_Enum is (One, Two, Three);
      
      --The following line *sometimes* does what's expected.
      --
      pragma Convention (Convention => C, Entity => My_Enum);
      
   begin
      null;
   end Enum;

produces:

   $ gcc -c -gnatR3 enum.adb
    
   Representation information for unit Enum (body)
   -----------------------------------------------
    
   for My_Enum'Object_Size use 32;
   for My_Enum'Value_Size use 2;
   for My_Enum'Alignment use 4;
    
So that's a case where pragma Convention works as I expect.  There are
a couple cases where I had to brute forcefully specify:

   for My_Enum'Size use 32;

despite the pragma Convention, which suggests that pragma convention
is unpredicable.