Re: Configuration issues on Itanium VMS

Re: Configuration issues on Itanium VMS

[Richard Kenner]

    > Wouldn't it be *much* easier just to force GCC to include the
    > system-supplied file that has all the proper definitions with prototypes?

    No.

Why?  Writing a program to get all the names of the functions to handle
specially isn't at all trivial and you don't get the prototypes.

Re: Configuration issues on Itanium VMS

[Zack Weinberg]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     > Wouldn't it be *much* easier just to force GCC to include the
>     > system-supplied file that has all the proper definitions with
>     > prototypes?
>
>     No.
>
> Why?  Writing a program to get all the names of the functions to
> handle specially isn't at all trivial and you don't get the
> prototypes.

It makes the entire C library visible even if you don't include the
headers.  This breaks real code.  It's even worse in C++ where the
library isn't supposed to be in the global namespace normally.

I suppose it would be _easier_, but it would still be _wrong_.

zw

Re: Configuration issues on Itanium VMS

[Geert Bosch]

On Nov 10, 2004, at 13:44, Zack Weinberg wrote:
> It makes the entire C library visible even if you don't include the
> headers.  This breaks real code.  It's even worse in C++ where the
> library isn't supposed to be in the global namespace normally.
>
> I suppose it would be _easier_, but it would still be _wrong_.

Thanks for the explanation.

   -Geert

Re: Configuration issues on Itanium VMS

[Zack Weinberg]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     It would be better to provide accurate prototypes for them whenever
>     possible, but I recognize that this is intractable in some cases
>     (e.g. those involving FILE*).
>
> Wouldn't it be *much* easier just to force GCC to include the
> system-supplied file that has all the proper definitions with prototypes?

No.

zw

Re: Configuration issues on Itanium VMS

[Richard Kenner]

    It would be better to provide accurate prototypes for them whenever
    possible, but I recognize that this is intractable in some cases
    (e.g. those involving FILE*).

Wouldn't it be *much* easier just to force GCC to include the
system-supplied file that has all the proper definitions with prototypes?

Re: Configuration issues on Itanium VMS

[Zack Weinberg]

"Douglas B Rupp" <rupp@gnat.com> writes:

>> The TARGET_INIT_BUILTINS hook could, perhaps, be used to construct
>> invisible declarations for every function that requires a prefix (or
>> augment the invisible declarations for the functions that already have
>> them), setting DECL_ASSEMBLER_NAME appropriately.
>
> Something like this?  It seems to work OK for functions that are not
> listed in builtins.def For those functions, e.g. memmove, my new
> libname gets overwritten/ignored when the builtin is "built" Not
> sure how to fix that...

Something like that, yes.  You should be using
lang_hooks.builtin_function instead of calling build_decl and pushdecl
directly.  For functions not already in builtins.def, a call similar
to

  lang_hooks.builtin_function (name, type, *, BUILT_IN_NORMAL, libname, 0);

should suffice.  [I am not sure what ought to go in the slot marked
with an *.]

It would be better to provide accurate prototypes for them whenever
possible, but I recognize that this is intractable in some cases
(e.g. those involving FILE*).

To deal properly with builtins with a target-independent meaning, I
think you should be able to call identifier_global_value at this
point, and if it returns something, just set its DECL_ASSEMBLER_NAME
rather than creating a new decl.  Note that this may cause link errors
in front ends other than C/C++/ObjC - the appropriate thing would be
to turn i_g_v into a langhook.

zw

Re: Configuration issues on Itanium VMS

[Douglas B Rupp]

> The TARGET_INIT_BUILTINS hook could, perhaps, be used to construct
> invisible declarations for every function that requires a prefix (or
> augment the invisible declarations for the functions that already have
> them), setting DECL_ASSEMBLER_NAME appropriately.

Something like this?
It seems to work OK for functions that are not listed in builtins.def
For those functions, e.g. memmove, my new libname gets overwritten/ignored 
when the builtin is "built"
Not sure how to fix that...

--------------

/* Initialize the assembler name of function NAME to LIBNAME */

static void
vms_init_library_name (name, libname, type)
     const char *name, *libname;
     tree type;
{
  rtx symbol;
  tree decl
    = build_decl (FUNCTION_DECL, get_identifier (name),
    build_function_type (type, NULL_TREE));

  SET_DECL_ASSEMBLER_NAME (decl, get_identifier (libname));
  DECL_ARTIFICIAL (decl) = 1;
  DECL_EXTERNAL (decl) = 1;
  TREE_PUBLIC (decl) = 1;
  pushdecl (decl);
  make_decl_rtl (decl, NULL);
  symbol = XEXP (DECL_RTL (decl), 0);
  SYMBOL_REF_DECL (symbol) = 0;
}

void
ia64_init_builtins (void)
{
...
  vms_init_library_name ("memmove", "decc$memmove", ptr_type_node);
}

Re: Configuration issues on Itanium VMS

[Zack Weinberg]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Mon, 8 Nov 2004, Douglas B Rupp wrote:
>
>> Configure, e.g. libiberty/configure,  generates conftest programs to decide if
>> particular CRTL functions exist in the host. If the compile or link is
>> unsucessful, e.g. undefined symbols in the link, then the function is
>> assumed not to exist.  *Configure doesn't bother to include the necessary
>> header files in the programs it generates, so all CRTL functions show up as
>> undefined with Gcc*.
>
> Standard C and POSIX say that you don't need to include the headers to use 
> standard functions which can be used without using any type defined in a 
> header, so requiring headers to be included is a bug in the GCC 
> configuration.  That doesn't mean it's easy to fix in GCC.

The TARGET_INIT_BUILTINS hook could, perhaps, be used to construct
invisible declarations for every function that requires a prefix (or
augment the invisible declarations for the functions that already have
them), setting DECL_ASSEMBLER_NAME appropriately.

zw

Re: Configuration issues on Itanium VMS

[Joseph S. Myers]

On Mon, 8 Nov 2004, Douglas B Rupp wrote:

> Configure, e.g. libiberty/configure,  generates conftest programs to decide if
> particular CRTL functions exist in the host. If the compile or link is
> unsucessful, e.g. undefined symbols in the link, then the function is
> assumed not to exist.  *Configure doesn't bother to include the necessary
> header files in the programs it generates, so all CRTL functions show up as
> undefined with Gcc*.

Standard C and POSIX say that you don't need to include the headers to use 
standard functions which can be used without using any type defined in a 
header, so requiring headers to be included is a bug in the GCC 
configuration.  That doesn't mean it's easy to fix in GCC.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Configuration issues on Itanium VMS

[Douglas B Rupp]

My current problem is with a cross native build, aka
build=alpha-dec-openvms7_1
host=ia64-hp-openvms8_0
target=ia64-hp-openvms8_0
but the same issue will occur regardless of build machine for this host.
Gcc version 3.4.2 (patched)

On VMS, all CRTL function symbols are prefixed, usually by "decc$".  The
HP VMS C  compiler handles this via an internal mechanism. However Gcc
has to have the  proper header file included to add the prefix via an asm 
state-
ment.  On  Alpha/VMS there is a VAX compatibility library that resolves the
function if  the header file is not included. This compatibility library is 
some-
thing of  a kludge and doesn't exist on Itanium VMS.

Configure, e.g. libiberty/configure,  generates conftest programs to decide 
if
particular CRTL functions exist in the host. If the compile or link is
unsucessful, e.g. undefined symbols in the link, then the function is
assumed not to exist.  *Configure doesn't bother to include the necessary
header files in the programs it generates, so all CRTL functions show up as
undefined with Gcc*.

The alternatives are to teach Gcc to add the proper prefix to all CRTL
functions or to teach configure to include the proper header files when
testing for CRTL functions.

Any thoughts on which alternative would be best, or other alternatives?

--Douglas Rupp
Ada Core Technologies, Inc