2 (small?) problems

2 (small?) problems

[Thomas Hiller]

Hello,

I encountered 2 problems with the current snapshot (beside some others already 
mentioned on the list).

1)	c++filt is not installed.

2)	Shared libg++ problem.
	I have a problem (also with the normal gcc), when I install the compiler
	in a non-standard place (e.g. /work/egcs). The shared libg++ is not
	found. I had to set the LD_LIBRARY_PATH to include $prefix/lib. Is there
	a portable way to set the shared library path from the compiler ? The
	compiler already issues -L$prefix/lib.
	
Greetings
	Thomas

Thomas Hiller				email: hiller@tu-harburg.d400.de
TU Hamburg-Harburg
Zentrallabor Informations- und Kommunikationstechnik
Harburger Schloss-Str. 20		Tel.: +49-40-7718-3448
D - 21071 Hamburg			Fax : +49-40-7718-2579

Re: GCC Projects?

[Bernd Schmidt]

> 
> I wouldn't lose sleep if it just disappeared one day.

I'd be happy to provide a patch to make it disappear. Do you want one?

Bernd

Re: prototyping

[Andi Kleen]

Per Bothner <bothner@cygnus.com> writes:

> > One of the things we should be doing -- switching to cpplib across
> > the board instead of for just the fixing of header files.
> > 
> > Per, are there any technical reasons why we can't start this soon?
> 
> There is no particular reason why we cannot switch from cpp compiled
> from cccp.c to one compiled from cpplib.c+cpplib.c.  Just change
> CCCP=ccccp to CCCP=cppmain in the Makefile.  However, there are
> years of changes to cccp made after cpplib was forked off that have
> not been merged into cpplib.  It would great if we could have a volunteer
> go through the RCS files for cccp.c and cexp.y, evaluate the changes,
> and integrate them into cpplib.c and cppexp.c.  In the case of changes
> where it is non-obvious how to make them in cpplib, I'd be happy to
> advice or even write the changes.  What I do not have time for is
> the tedious task of sifting through the changes, making the easy
> patches, and flagging the difficult ones.

I would be happy to do at least some of this work of sifting through
the RCS files. Are they available somewhere?


-Andi

Will egcs support MachTen?

[N8TM]

I have been following g77 alpha successfully on MachTen 4.03.  In view of the
interest in merging g77 alpha and egcs work, I'd like to know if egcs can be
made to work on MachTen.  I spent a few hours at it yesterday without
success.
Tim

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: [EGCS] Re: double alignment patch for x86

[Dave Love]

>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:

 >> It takes 2 additional cycles per double access.. this can sum up
 >> to 30% runtime penalty on important algorithms like matrix
 >> multiply...

 Toon> This is on a Pentium ?  

It's about right for daxpy on my pentium.

-- Dave (recycled physicist)

Re: bootstrapping problems with native compiler

[Dave Love]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

 Jim> The problem here is that LANGUAGES is not passed on recursive
 Jim> invocations of make.  This causes a problem for any target (like
 Jim> irix6) with a multilib libgcc, because this is implemented via a
 Jim> recursive make.  

I passed LANGUAGES="$(LANGUAGES)" to all the $(MAKE)s in the top-level
Makefile.in and on an irix6.4 system with the native make (and having
forgotten to stop it picking up gcc as CC) it did a set of recursive
makes until running out of processes.

 Jim> Manfred Hollstein mailed a patch to the gcc2 developers that
 Jim> would fix this.

I checked the FSF version before complaining and couldn't see any
relevant changes there.  (Sorry I haven't been reading gcc2.)  If
someone can mail it to me I can see if it solves the problem on a
mighty, fairly-idle SGI.

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

[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.

Monday morning

[Philippe Laliberte]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

Hello,

        I have been reading the list and looking at the snapshot over the
weekend, and it seem's clear that I'm a bit lost. Can some one point to me some
reading to do in the hope that I can contribute one day something usefull?

        Utill that day I'll keep reading and trying to play with the snapshot.
Thank's for being their.


---

Bonne journée,
Have a nice day,

  _____________________________________________________________________
|Philippe Laliberte             |        http://www.mlink.net/~arsphl/  |
| ___ Arsphl ___                |        http://oeil.qc.ca/             |
| arsphl@mlink.net              |                                       |
| arsphl@oeil.qc.ca             |        NO SPAM PLEASE                 |
  _____________________________________________________________________

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

[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

[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

[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.

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