public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tristan Gingold <gingold@adacore.com>
To: Duncan Sands <baldrick@free.fr>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [Ada] Ease interface with builtins that returns void *
Date: Mon, 16 Jul 2012 14:31:00 -0000	[thread overview]
Message-ID: <ECA866E8-5D75-41C6-985E-9C8265EAB30A@adacore.com> (raw)
In-Reply-To: <50041E04.8070009@free.fr>


On Jul 16, 2012, at 3:58 PM, Duncan Sands wrote:

> Hi Tristan,
> 
>>> indeed, for two years already.  Is there any reason not to do this for all
>>> functions, rather than just limiting it to builtins?
>> 
>> I don't understand what do you mean.  We need to do this implicit conversion for builtins because they are known by the compiler.  Which other functions (that aren't builtins) are you referring to ?
> 
> all of them!  First off, the LLVM optimizers do a better job if an argument of a
> user defined function that is really a pointer is declared as such, rather than
> declared as an integer then cast to a pointer before being used.  I don't know
> if the GCC optimizers are sensitive to this too.  Also, the LLVM optimizers
> recognize some standard library functions that the gcc optimizers do not, but
> fail to recognize them when called from Ada because they have the wrong
> prototype: an integer rather than a pointer argument.  Finally I would argue
> that as System.Address is really a pointer, playing pretty much exactly the
> same role as void* in C, it is more philosophically correct to express it as a
> void*.  That said, it should probably just be declared as a pointer in the
> System package rather than doing all this mucking around in the gcc interface.

Ah, what you want is the use of 'void *' for System.Address.
We didn't choose that because the semantic of System.Address (which includes arithmetic on the whole address space) doesn't match the void * one.

But, you can try to implement this scheme by modifying the runtime.  I don't know if this is a small work or not.

Tristan.

  reply	other threads:[~2012-07-16 14:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-16 13:11 Arnaud Charlet
2012-07-16 13:16 ` Duncan Sands
2012-07-16 13:18   ` Tristan Gingold
2012-07-16 13:24     ` Duncan Sands
2012-07-16 13:52       ` Tristan Gingold
2012-07-16 13:58         ` Duncan Sands
2012-07-16 14:31           ` Tristan Gingold [this message]
2012-07-16 14:36             ` Duncan Sands
2012-07-16 14:42               ` Tristan Gingold
2012-07-16 14:52                 ` Duncan Sands
2012-07-16 15:17                 ` Duncan Sands
2012-07-16 15:26                   ` Tristan Gingold
2012-07-16 16:22                     ` Eric Botcazou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ECA866E8-5D75-41C6-985E-9C8265EAB30A@adacore.com \
    --to=gingold@adacore.com \
    --cc=baldrick@free.fr \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).