This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ada in gcc-3.4.3 on x86_64


At 06:34 PM 1/3/2005, Robert Dewar wrote:
Dean Kolosiek wrote:

Ada could always set %al for all calls to C. It can be set either to the actual
number of registers or always to 8.

That would be unnecessary overhead to achieve something that is not supported in any case.

Speed does not have precedence over correctness.


An extension should not be necessary. From an Ada perspective it is supposed to work with pragma Import (C, certainly if Ada and C are from the same vendor.
The Ada 95 LRM Annex B.3 Interfacing with C has a specific reminder on handling variadic calls:
(12) A C function that takes a variable number of arguments can correspond to several Ada subprograms, taking various specific numbers and types of parameters.

The above is a note, which has no normative force whatsoever. Furthermore. it says "can" which in standardeese means that this is an allowable implementation. In some architectures, the calling sequences are radically different, so it would be impsosible to "follow" the suggestion of this note.
So, the LRM is saying that the proper approach is to use overloaded Ada subprograms to call variadic C routines.

It is not saying that at all!

No. Get a dictionary. "Can" denotes ability. The word you defined is "may". Notes have no normative
force whatsoever. A statement to allow an implementation would be normative. An allowance
expresses something that is not otherwise permitted. The use of overloading to call variadic
functions is fully correct without an allowance. The note is not a suggestion, it is a statement of fact.


If you want to make a new pragma in order to handle the impossible situations you should get it into
Ada 2005 to make it portable.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]