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

[Jeffrey A Law]

  In message <E0x0rGY-0000Z1-00.1997-08-19-18-36-22_pgcc_forever_@cerebro>you write:
  > One thing that bugs me for months now (need advice):
  > 
  > gcc currently ignores the alignment set by FUNCTION_ARG_BOUNDARY
  > on machines that use push instructions to store arguments. This
  > results in incorrect code (caller forgets the necessary padding)
  > with the proposed -marg-align-double.
Right.

  > I'd like to fix this... so... where would be the place to do that?
  > Should store_one_arg add padding, or should this be done in expand_call?
Have the caller push dummy word(s) before any of the normal args iff the
sum total of the stack area to be pushed is not a multiple of
FUNCTION_ARG_BOUNDARY.

The callee then moves any unaligned args out of the stack into either a
register (if that't the final "home" for the arg) or into an aligned
stack slot.

However, this only works if nobody ever mis-aligns the stack -- which
is hard to guarantee on the x86 because of the existance of old compilers
which do not maintain proper stack alignment.


  > We could make the switch dependent on the OS (Linux -> do, solaris ->
  > ignore).  That's somewhat ugly, but it doesn't break any programs.
You can't even do it on linux by default because of existing libraries
which may perform callbacks (qsort) or the need to be able to mix and
match .o files from different versions of gcc.


jeff

Re: [EGCS] Re: double alignment patch for x86

[Marc Lehmann]

>  > IMHO, the stack should always be aligned to an 8 byte boundary unless you
>  > specifically ask for it otherwise (-fspace for instance).  Otherwise, your
>  > caller may not have aligned the stack properly.
>That's one way to approach the problem, but it results in an extra insn to
>mask off the low bits of the stack in the prologue.

One thing that bugs me for months now (need advice):

gcc currently ignores the alignment set by FUNCTION_ARG_BOUNDARY
on machines that use push instructions to store arguments. This
results in incorrect code (caller forgets the necessary padding)
with the proposed -marg-align-double.

I'd like to fix this... so... where would be the place to do that?
Should store_one_arg add padding, or should this be done in expand_call?

>Options which increase the minimum alignment requirements for stack objects
>implicitly depend on the OS, crt0 and friends to maintain proper alignment.

We could make the switch dependent on the OS (Linux -> do, solaris -> ignore).
That's somewhat ugly, but it doesn't break any programs.

In worst case we could simply default this switch to off.

>[ Which is why I would generally discourage options which work in this
>  manner. ]

I'd say we shouldn't discourage options that can easily double
code speed, with only minimal changes. And on many machines,
you have more alignment than the standard says anyway.

      -----==-
      ----==-- _
      ---==---(_)__  __ ____  __       Marc Lehmann
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com
      -=====/_/_//_/\_,_/ /_/\_\
    The choice of a GNU generation

Re: [EGCS] Re: double alignment patch for x86

[Marc Lehmann]

John Carr wrote:
>
>byte alignment.  8 byte alignment is desirable (and has always been --
>Sun made a bad choice 10 years ago).  gcc copies misaligned double
>arguments to aligned locations on the stack.  Doing this on x86 might

I thinkt the patch already does this with -mstack-align-double
the (broken) -marg-align-double is just to squeeze out
the last bit of performance ;)

>help performance without breaking compatibility (or it might not: on x86
>there is only a cost if the dynamic value of the pointer is not aligned
>but SPARC requires two instructions instead of one to support possibly
>misaligned pointers).

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

It was a actually physicist that actually pointed this out to me
(and H.J.Lu for the libc, I believe).

      -----==-
      ----==-- _
      ---==---(_)__  __ ____  __       Marc Lehmann
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com
      -=====/_/_//_/\_,_/ /_/\_\
    The choice of a GNU generation

Re: [EGCS] Re: double alignment patch for x86

[Toon Moene]

Marc,

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

This is on a Pentium ?  My brother did some experiments on his PPro  
180 for me with a code that had almost all DOUBLE PRECISION data in  
COMMON BLOCKS.

Without -malign-double, the code took 18 seconds, with  
-malign-double 10 seconds, i.e. a factor of almost 2.

>  It was a actually physicist that actually pointed this
>  out to me (and H.J.Lu for the libc, I believe).

We're both actual physicists :-)

Cheers,
Toon.