front end interface

front end interface

[John Carr]

The changes I am making to my alias code would be better and easier if
it were possible to change the front-end/back-end interface.  Are we
trying to be 100% compatible with the gcc2 interface?  I don't think
we should.

Re: front end interface

[Jeffrey A Law]

  In message <199708161411.KAA02125@jfc.>you write:
  > 
  > The changes I am making to my alias code would be better and easier if
  > it were possible to change the front-end/back-end interface.  Are we
  > trying to be 100% compatible with the gcc2 interface?  I don't think
  > we should.
No, 100% compatability with the gcc2 interface is not a goal.

We'll break the interface if doing so opens up new optimization opportunities
or opportunities to clean up the compiler as a whole.

What kind of changes are you suggesting?

jeff

Re: front end interface

[Dave Love]

>>>>> "John" == John Carr <jfc@mit.edu> writes:

 John> I've mentioned this in private email but I should let the list
 John> know as well: my alias code in the back end recognizes certain
 John> C function names.  I believe this is correct because all
 John> languages will be linking with the C library and must mangle or
 John> prohibit any names which conflict.  For example, Fortran
 John> symbols traditionally have a "_" added to the end.

I suspect it's not relevant for the likely routines which are probably
used by the runtime anyhow, but just in case: G77 has an option to
suppress mangling.  It typically ends in tears when ths is used, of
course.

Re: front end interface

[Nigel Stephens]

John Carr (jfc@MIT.EDU) writes:
 > > If I understand this correctly, you're depending on memcpy() being
 > > named 'memcpy' ?!
 > > 
 > > This leads into trouble with the current openVMS ports (vax and
 > > alpha), where most library functions are '#define'd with a DECC$ in
 > > front (and others have a __asm() appended to their declaration). So
 > > the compiler doesn't see memcpy but DECC$MEMCPY.
 > 
 > memcpy is recognized by the C front end, as are some of the other
 > string and math functions.

Perhaps a better way to do this in general would be to extend the
__attribute__ mechanism to allow a header file to tell the compiler
more about the behaviour of functions.  For example, since the
"malloc" test is used to tell the "alias" pass that pointers returned
by these functions won't alias to other pointers, we could perhaps
have:

	void * malloc (size_t) __attribute__ ((noalias));

This might then be useful for other functions with similar properties
to malloc(), realloc(), etc.

A similar trick would work for setjmp:

	int setjmp (jmp_buf) __attribute__ ((returns-twice));

As for the builtin use of memcpy() for structure copies etc,
presumably the name of the byte-copy function should be configurable
in the target's header file rather than hardwired into optabs.c.


-- 
________________________________________________________________________
Nigel Stephens, Algorithmics Ltd, 3 Drayton Park, London N5 1NU. England
mailto:nigel@algor.co.uk                          http://www.algor.co.uk
phone:+44 171 700 3301	   mobile:+44 976 686470    fax:+44 171 700 3400

Re: front end interface

[Klaus Kaempf]

> 
> memcpy is recognized by the C front end, as are some of the other
> string and math functions.

This already leads to all sorts of unwanted behaviour, see below
> 
> The new calls.c recognizes malloc, calloc, and realloc by name.

Is a list of these names documented anywhere ? A possible solution
would be to include these in a (vms specific) gcclib which calls the
proper dec c functions.

> 
> Standard functions which are defined as macros must also be defined
> with their real names.  gcc depends on this; for example it may call
> "memcpy" for large structure assignments.
> 

The dependancy on 'real names' hit me once before. I haven't found an easy solution
for this yet. Maybe the front end should be changed to have function
declarations override internal prototypes for the same function.

The openVMS/Alpha math.h uses DEC C math functions with different
assembler symbol names:

math.h: extern double sin (double _x) __asm ("MATH$SIN_T");

libstdc++/fcomplex.cc calls sin() with a float argument which
doesn't match the math.h prototype (double argument), so the
built-in sin prototype is matched (why ?).

Since there is no built-in sin function, the resulting object
code lists 'sin' as an undefined symbol which isn't matched
by any library.

Compiling with "-fno-builtin" or changing the prototype declaration
in math.h to have a 'float' argument is a (temporary) solution.



-- 
proGIS Software                 E-Mail: kkaempf@progis.de
Dipl.-Inform. Klaus K"ampf      Fax:    0241-47067-29
Jakobstr. 117                   Voice:  0241-47067-11
D-52064 Aachen                  WWW:	http://www.progis.de

Re: front end interface

[Andreas Schwab]

John Carr <jfc@MIT.EDU> writes:

|>> If I understand this correctly, you're depending on memcpy() being
|>> named 'memcpy' ?!
|>> 
|>> This leads into trouble with the current openVMS ports (vax and
|>> alpha), where most library functions are '#define'd with a DECC$ in
|>> front (and others have a __asm() appended to their declaration). So
|>> the compiler doesn't see memcpy but DECC$MEMCPY.

|> memcpy is recognized by the C front end, as are some of the other
|> string and math functions.

|> The new calls.c recognizes malloc, calloc, and realloc by name.

I think there should be a way to mark a function "malloc-like", similar as
it is done with the printf family.

Re: front end interface

[John Carr]

> If I understand this correctly, you're depending on memcpy() being
> named 'memcpy' ?!
> 
> This leads into trouble with the current openVMS ports (vax and
> alpha), where most library functions are '#define'd with a DECC$ in
> front (and others have a __asm() appended to their declaration). So
> the compiler doesn't see memcpy but DECC$MEMCPY.

memcpy is recognized by the C front end, as are some of the other
string and math functions.

The new calls.c recognizes malloc, calloc, and realloc by name.  If
these are defined with different names in VMS the alias code will
generate worse, but correct, code.  calls.c also recognizes setjmp,
longjmp, and related functions; if VMS changes these names the
compiler may generate incorrect code.

Standard functions which are defined as macros must also be defined
with their real names.  gcc depends on this; for example it may call
"memcpy" for large structure assignments.

Re: front end interface

[Clive Nicolson]

>> I've mentioned this in private email but I should let the list know as
>> well: my alias code in the back end recognizes certain C function names.
>> I believe this is correct because all languages will be linking with the C
>> library and must mangle or prohibit any names which conflict.  For example,
>> Fortran symbols traditionally have a "_" added to the end.
>> 
>If I understand this correctly, you're depending on memcpy() being named 'memcpy' ?!
>
>This leads into trouble with the current openVMS ports (vax and alpha), where most
>library functions are '#define'd with a DECC$ in front (and others have a __asm() appended
>to their declaration). So the compiler doesn't see memcpy but DECC$MEMCPY.

This is somewhat in violation of the ANSI C rules about names. I have a patched version
of gcc 2.7.1 (vax vms) that translates ANSI C names (to those found in the DEC
runtime libraries) in the assembler, this is much like that done by DEC's DECC compiler.

I still have to fix the passing of some attributes via the name prefixing hack used by
gcc vax/vms.

Clive.

Re: front end interface

[Klaus Kaempf]

> 
> I've mentioned this in private email but I should let the list know as
> well: my alias code in the back end recognizes certain C function names.
> I believe this is correct because all languages will be linking with the C
> library and must mangle or prohibit any names which conflict.  For example,
> Fortran symbols traditionally have a "_" added to the end.
> 
If I understand this correctly, you're depending on memcpy() being named 'memcpy' ?!

This leads into trouble with the current openVMS ports (vax and alpha), where most
library functions are '#define'd with a DECC$ in front (and others have a __asm() appended
to their declaration). So the compiler doesn't see memcpy but DECC$MEMCPY.

Klaus
-- 
proGIS Software                 E-Mail: kkaempf@progis.de
Dipl.-Inform. Klaus K"ampf      Fax:    0241-47067-29
Jakobstr. 117                   Voice:  0241-47067-11
D-52064 Aachen                  WWW:	http://www.progis.de

Re: front end interface

[John Carr]

> We'll break the interface if doing so opens up new optimization opportunities
> or opportunities to clean up the compiler as a whole.
> 
> What kind of changes are you suggesting?

The function call interface does not permit a front end to say that a
function only modifies certain memory locations.  For example: memset,
fprintf, and sprintf only modify the memory pointed at by their first
argument (at least in ANSI C/POSIX).  write(2) doesn't modify any of
its arguments, but may modify errno.

In rtl, I will mark such function calls with the CONST_CALL_P flag and
add clobbers to CALL_INSN_FUNCTION_USAGE to represent the effects on
memory.

I worked out a compatible interface to handle the simple cases like memset,
but not the general case with multiple arguments and possible modification
of unmentioned global variables.


I've mentioned this in private email but I should let the list know as
well: my alias code in the back end recognizes certain C function names.
I believe this is correct because all languages will be linking with the C
library and must mangle or prohibit any names which conflict.  For example,
Fortran symbols traditionally have a "_" added to the end.