On 17/10/2011 18:27, Gabriel Dos Reis wrote:
On Mon, Oct 17, 2011 at 11:50 AM, Ben Gamari<[email protected]> wrote:
On Mon, 17 Oct 2011 10:24:29 -0500, Gabriel Dos
Reis<[email protected]> wrote:
On Mon, Oct 17, 2011 at 9:52 AM, Ben Gamari<[email protected]> wrote:
On Mon, 17 Oct 2011 08:55:42 +0100, Simon Marlow<[email protected]> wrote:
I think if we just add those functions to the table unconditionally, it
may break the C backend on certain other platforms or perhaps other
versions of gcc. I agree it should work out of the box, but we did not
need this change in the past, so why is it necessary now?
We need to identify exactly where this change is necessary. Perhaps it
is a recent change in gcc? If so, we need to know which version.
Fair enough. A little bit of Googling confirmed that GCC does tree
malloc, et al. as builtins[1]. It seems the correct approach here might
be to instead pass the -fno-builtin option[2] to gcc.
plain -fno-builtin will instruct GCC from doing any kind of optimizations
on -any- standard C function calls -- not just malloc(). Is that what you want?
It's unclear. The problem is merely a name conflict so I agree that this
does seem like overkill. Does the C backend rely on the compiler's
builtins at all?
It depends.
If you invokve GCC in free standing mode (-ffreestanding), it does not
assume that you are using a C standard library at all. So it would refrain
from any program transformation that relies on standard function semantics.
Otherwise, the compiler does a fair amount of non-trivial
transformations, ranging
from simple things like turning printf("Hello World\n") into
puts("Hello World"), to
more involved transformation involving storage allocation, alias analysis
based on malloc() attribute etc. Furthermore, with -ffreestanding you would
have to specify the program entrypoint.
I guess the problem you are describing is not restricted to GCC. It
would surface with any modern optimizing C compiler, e.g. ICC.
The main reason is that the C standard has restrictions on
standard library function names:
-- All identifiers with external linkage in any of the
following subclauses (including the future library
directions) are always reserved for use as identifiers
with external linkage.
that allow C compilers to apply program transformations merely based on
the name and linkage; and GCC is not the only C compiler doing that.
My suggestion would be for GHC runtime to:
-- invoke GCC with -fno-builtin, and lose the benefit of many
transformations GCC does based on C standard semantics; or
This is probably the right solution, but I'd still like to understand
what has gone wrong...
-- invoke GCC with -fno-builtin-xxx for all the xxx redefined by GHC, but
that might not work with othe C compilers (Clang?); or
We really are compiling references to malloc() and free() here - it's
not just a name clash with some GHC internal stuff. Also this is in a
library, not GHC itself.
This commit looks relevant:
http://hackage.haskell.org/trac/ghc/changeset/497302c44ad08c6c27d0e15d94a787f332c0cfec
So I don't understand why we aren't generating function-typed
declarations here, from that commit it looks like we should be.
-- avoid reserved C identifiers with external linkage (my preference).
I don't think we can do that. We really do want to refer to malloc()
etc. Furthermore, third-party library code might need to foreign import
some other built-in C functions, so we have to cover all possibilities.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
