Re: HAVE_STDLIB_H

Re: HAVE_STDLIB_H

[Joern Rennecke]

> > Also, that will break on at least one system, StunOS, which (as I recall)
> > ends up having 'int free(char *)', and declares it in some header typically
> 
> I thought gcc fixincludes took care of it.

We are talking about gcc sources here.  To build stage1, you need to use
whatever compiler you have already installed - and use whatever header
files go with it.

Re: A config patch

[Jason Merrill]

So alpha-linux doesn't default to pic like OSF/1 does?

Jason

Re: g77 problem in egcs-ss-970828

[Mumit Khan]

Toon Moene  writes:
> I'm sending this to egcs, because I'm not entirely sure that this  
> front end bug is *not* caused by the snapshots C compiler  
> miscompiling the g77 frontend.
> 
> Given the following Fortran routine:
> 
>       SUBROUTINE AAP(NOOT)
>       DIMENSION NOOT(*)
>       END


I can verify this problem on at 2 other platforms, and it does not happen
with the previous snapshots (2.90.00-2.90.02) on either of these machines
(i686-linux-gnulibc1 and hppa1.1-hp-hpux10.20).

Mumit

Re: HAVE_STDLIB_H

[Jeffrey A Law]

  In message you write:
  > To see how this is supposed to work, see the bfd sources.  The gcc
  > implementation was copied from bfd, but is incomplete.
  > 
  > I knew that we were missing this stuff:
  > 	#ifdef NEED_DECLARATION_FREE
  > 	extern void free ();
  > 	#endif
  > 
  > But now I see that we are also missing this stuff:
  > 	#ifdef HAVE_STDLIB_H
  > 	#include 
  > 	#endif
Yup.  That's exactly the problem.

  > If you want, I am willing to take this problem off your hands.
Well, I've added the ones that were absolutely necessary to get
egcs building again.  We really need to go through and add them
to the rest of the compiler though.


Jeff

Re: HAVE_STDLIB_H

[Jim Wilson]

To see how this is supposed to work, see the bfd sources.  The gcc
implementation was copied from bfd, but is incomplete.

I knew that we were missing this stuff:
	#ifdef NEED_DECLARATION_FREE
	extern void free ();
	#endif

But now I see that we are also missing this stuff:
	#ifdef HAVE_STDLIB_H
	#include <stdlib.h>
	#endif

Both of these things need to be in every file.  Bfd puts both of these in
sysdep.h, and then includes sysdep.h in every file.  Ideally, this would happen
via config.h somehow for gcc.  Perhaps put it in a sysdeps.h file, and then
include sysdeps.h before config2.h (aka tm.h).  This also allows us to include
it places where the tm.h file would be inappropriate.

Putting all of this stuff in acconfig.h is probably wrong.

If this autoconf stuff was complete, then we would never need any declarations
of free other than the one I mentioned above.

If you want, I am willing to take this problem off your hands.

Jim

Re: HAVE_STDLIB_H

[Ian Lance Taylor]

   Date: Wed, 27 Aug 1997 22:08:06 -0600
   From: Jeffrey A Law <law@hurl.cygnus.com>

     In message <199708272108.OAA10071@cygnus.com>you write:

     > The autoconf support guarantees that config.h will always define free
     > (ignoring for the moment the known minor problems with it).  Since every
     > file must already be including config.h, we can fix this problem simply
     > by deleting every declaration of free.
   I'm not much of an autoconf person.  Are you suggesting something
   like this be added to acconfig.in after the #undef NEED_DECLARATION_FREE?

   #ifdef NEED_DECLARATION_FREE
   extern void free ();
   #endif

   Then delete the various declarations of free found throughout the
   sources?

It isn't too standard to add something to acconfig.in, although you
can.  It's slightly more normal to have a single header file, which
includes config.h, and then does things.  All programs then include
the latter header file.  For example, that's how BFD handles this same
issue: config.h defines NEED_DECLARATION_FREE, sysdep.h includes
config.h and does the above bit of code, and all files include
sysdep.h.

However, adding something to acconfig.in will work, and I don't see
anything conceptually wrong with it.

   Note you can't use PROTO here because we haven't sucked in gansidecl.h
   yet.

You should never declare arguments to system functions if you can
possibly avoid it, even if you don't think the function is declared in
any system header files.  The myriad systems are too unpredictable in
this regard.

Ian

Re: HAVE_STDLIB_H

[Craig Burley]

>Well, at least short term the problem with this is only the
>c++ front end includes stdlib.h -- c, g77 and objc don't
>include it, and thus if autoconf decided that a decl wasn't
>needed because one existed in stdlib.h, then we end up losing.

FYI, my version of g77 (the one I'm about to release for 0.5.21,
which differs from egcs' versions a bit, I'm sure) *does*
include <stdlib.h> in its gcc/f/proj.h file, which is the
"central" file "every" front-end source file includes first.
(And I've changed it to #include <config.j> before anything
else -- config.j normally just does #include "config.h" from
gcc.)

I'd look into making g77 more compliant to various standards
right away, except I'm still working on a gcc-2.7.2.2 base,
where things like HAVE_STDLIB_H and such don't really exist.
Just hoping the few things I *am* doing don't make 0.5.21
worse than 0.5.20 for anyone; *that* would be embarrassing!

In another few weeks, I hope to be able to start making time
to work on egcs, especially the g77 side of it, etc. etc.

        tq vm, (burley)

results of "make check"

[Kate Hedstrom]

The freeBSD system gives:

gecko% gcc -v
Reading specs from /usr/local/lib/gcc-lib/i386-unknown-freebsd2.1.6/egcs-2.90.02/specs
gcc version egcs-2.90.02 970825 (gcc2-970802 experimental)

                === gcc Summary ===

# of expected passes            4835
# of unexpected failures        42
# of expected failures          4
# of unsupported tests          7

                === g++ Summary ===

# of expected passes            3268
# of unexpected successes       2
# of expected failures          81
# of untested testcases         6

This doesn't strike me as alarmingly bad, whereas the RS6000 results do:

pequod% config.status
creating Makefile
creating config.h
config.h is unchanged
Merged rs6000/x-rs6000.
Merged rs6000/t-newas.
Created `cp/Makefile'.
Merged rs6000/x-rs6000.
Merged rs6000/t-newas.
Created `f/Makefile'.
Merged rs6000/x-rs6000.
Merged rs6000/t-newas.
Created `objc/Makefile'.

                === gcc Summary ===

# of expected passes            2094
# of unexpected failures        1483
# of expected failures          4
# of untested testcases         1302
# of unsupported tests          7

                === g++ Summary ===

# of expected passes            2258
# of unexpected failures        559
# of unexpected successes       2
# of expected failures          532
# of untested testcases         6

This is on a system with 128 MB of RAM, in which no one else was logged
in or running any jobs.  My limits are:

pequod% limit
cputime         unlimited
filesize        1048575 kbytes
datasize        131072 kbytes
stacksize       32768 kbytes
coredumpsize    1024 kbytes
memoryuse       102400 kbytes

A typical failure message is:

Executing on host: /d0/kate/gnu/egcs-970825/gcc/xgcc -B/d0/kate/gnu/egcs-970825/gcc/
/d0/kate/gnu/egcs-970825/gcc/testsuite/gcc.c-torture/compile/920413-1.c -w
  -O0   -c  -o /tmp/920413-1.o   
compiler exited with status 1
output is:
xgcc: Internal compiler error: program cc1 got fatal signal 6

FAIL: gcc.c-torture/compile/920413-1.c,  -O0  

Kate

Re: HAVE_STDLIB_H

[Jeffrey A Law]

  In message <199708272108.OAA10071@cygnus.com>you write:
  > The autoconf support guarantees that config.h will always define free
  > (ignoring for the moment the known minor problems with it).  Since every
  > file must already be including config.h, we can fix this problem simply
  > by deleting every declaration of free.
I'm not much of an autoconf person.  Are you suggesting something
like this be added to acconfig.in after the #undef NEED_DECLARATION_FREE?

#ifdef NEED_DECLARATION_FREE
extern void free ();
#endif

Then delete the various declarations of free found throughout the
sources?

Note you can't use PROTO here because we haven't sucked in gansidecl.h
yet.

Jeff

Re: HAVE_STDLIB_H

[Jeffrey A Law]

  In message <199708271943.PAA14251@caip.rutgers.edu>you write:
  > 	Presumably, this is what the autoconf test GCC_NEED_DECLARATION
  > is used for in configure.in. 
  > 
  > 	I.e. you could do something like this:
  > 
  >  > #include <various system headers>
  >  > 
  >  > #ifdef NEED_DECLARATION_FREE
  >  > void free PROTO ((void *));
  >  > #endif
Well, at least short term the problem with this is only the
c++ front end includes stdlib.h -- c, g77 and objc don't
include it, and thus if autoconf decided that a decl wasn't
needed because one existed in stdlib.h, then we end up losing.

What you're suggesting was basicly the first thing I tried.

I think we can work around this by putting the conditional
declaration of free in config.h (via acconfig.h -> config.in).

My only problem with that is I'm not familiar enough with autoconf
to know if something like that's considered "reasonable".

jeff

Re: HAVE_STDLIB_H

[Jeffrey A Law]

  In message <m0x3nnE-0004ecC@ocean.lucon.org>you write:
  > I thought gcc fixincludes took care of it.
fixincludes fixes stuff for the target, not the build machine, thus
fixincludes is worthless for this problem.

  > Can you add
  > 
  > extern void free ();
  > 
  > to confdefs.h to see if <stdlib.h> is really ok?
Kinda gross, but an interesting alternative.  Might be worth a
try if changing acconfig.h to conditionally declare free is
considered a poor solution.

jeff

Re: HAVE_STDLIB_H

[Jeffrey A Law]

  In message <199708271912.OAA28994@monolith.solon.com>you write:
  > Also, that will break on at least one system, StunOS, which (as I recall)
  > ends up having 'int free(char *)', and declares it in some header typically
  > included... So, you can't just take all the prototypes out, because gcc2
  > takes the address of free(), so it needs a declaration, but you can't just
  > declare it correctly, because some systems are wrong, and...
Which is _precisely_ why we need to handle more and more of this
stuff with autoconf!

Jeff

ps.  sunos is the host where I first ran into the problem after
the c++ folks added the stdlib.h includes.

Re: HAVE_STDLIB_H

[Jim Wilson]

	Note, the HAVE_STDLIB_H patches are breaking builds under sunos4.

	These either need to be installed compiler-wide or not installed
	at all.

	The basic problem is our good friend "free", which conflicts 
	with the declaration in tree.h and stdlib.h

	And we can't just simply take out the decl in tree.h because some
	code doesn't include stdlib.h yet.

The autoconf support guarantees that config.h will always define free
(ignoring for the moment the known minor problems with it).  Since every
file must already be including config.h, we can fix this problem simply
by deleting every declaration of free.

If there are files that don't include config.h, then we can leave the free
declaration in them.

This should be very easy to do.

Jim

Re: A vtable thunks bug.

[Mike Stump]

This is a flaw with thunk support.  The testcase can just be marked as
expected to fail on your system.

Re: HAVE_STDLIB_H

[Jeffrey A Law]

  In message <m0x3kex-0004ecC@ocean.lucon.org>you write:
  > > 
  > >   In message <m0x3iMq-0004ecC@ocean.lucon.org>you write:
  > >   > If so, why not do
  > >   > 
  > >   > #ifdef HAVE_STDLIB_H
  > >   > #include <stdlib.h>
  > >   > #else
  > >   > void free PROTO((void *));
  > >   > #endif
  > > Because I don't have the time to go through every file and fix
  > > them.
  > > 
  > > Jeff
  > 
  > It will be in my next jumbo proto patch.
But I've already told you I will not install a "jumbo" patch.

If the c++ guys don't pipe in soon, I'm going to have to fix
it any way I can, which may involve removing the offending 
include file until someone can fix it.

Jeff

Re: HAVE_STDLIB_H

[Kaveh R. Ghazi]

 > From: Peter Seebach <seebs@monolith.solon.com>
 > Subject: Re: HAVE_STDLIB_H
 > 
 > Also, that will break on at least one system, StunOS, which (as I recall)
 > ends up having 'int free(char *)', and declares it in some header typically
 > included... So, you can't just take all the prototypes out, because gcc2
 > takes the address of free(), so it needs a declaration, but you can't just
 > declare it correctly, because some systems are wrong, and...
 > 
 > -s

	Presumably, this is what the autoconf test GCC_NEED_DECLARATION
is used for in configure.in. 

	I.e. you could do something like this:

 > #include <various system headers>
 > 
 > #ifdef NEED_DECLARATION_FREE
 > void free PROTO ((void *));
 > #endif

		--Kaveh
--
Kaveh R. Ghazi				Project Manager
ghazi@caip.rutgers.edu			ICon CMT Corp.

Re: HAVE_STDLIB_H

[H.J. Lu]

> 
> Also, that will break on at least one system, StunOS, which (as I recall)
> ends up having 'int free(char *)', and declares it in some header typically

I thought gcc fixincludes took care of it.

> included... So, you can't just take all the prototypes out, because gcc2
> takes the address of free(), so it needs a declaration, but you can't just
> declare it correctly, because some systems are wrong, and...
> 

Can you add

extern void free ();

to confdefs.h to see if <stdlib.h> is really ok?

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)
--
--- configure.in.orig	Mon Aug  4 10:15:18 1997
+++ configure.in	Wed Aug 27 12:23:43 1997
@@ -133,6 +133,8 @@
 AC_PROG_CC
 AC_PROG_MAKE_SET
 
+echo "extern void free ();" >> confdefs.h
+
 AC_CHECK_HEADERS(stddef.h string.h strings.h stdlib.h time.h unistd.h)
 
 GCC_NEED_DECLARATION(malloc)

Re: HAVE_STDLIB_H

[Peter Seebach]

Also, that will break on at least one system, StunOS, which (as I recall)
ends up having 'int free(char *)', and declares it in some header typically
included... So, you can't just take all the prototypes out, because gcc2
takes the address of free(), so it needs a declaration, but you can't just
declare it correctly, because some systems are wrong, and...

-s

Re: HAVE_STDLIB_H

[Jeffrey A Law]

  In message <m0x3iMq-0004ecC@ocean.lucon.org>you write:
  > If so, why not do
  > 
  > #ifdef HAVE_STDLIB_H
  > #include <stdlib.h>
  > #else
  > void free PROTO((void *));
  > #endif
Because I don't have the time to go through every file and fix
them.

Jeff

Re: HAVE_STDLIB_H

[H.J. Lu]

> 
>   In message <m0x3iMq-0004ecC@ocean.lucon.org>you write:
>   > If so, why not do
>   > 
>   > #ifdef HAVE_STDLIB_H
>   > #include <stdlib.h>
>   > #else
>   > void free PROTO((void *));
>   > #endif
> Because I don't have the time to go through every file and fix
> them.
> 
> Jeff

It will be in my next jumbo proto patch.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: g77 configuring, docs (was Re: 970825 Snapshot Available)

[Craig Burley]

>I'm tempted to do both a gcc2 -> egcs and f77dev -> egcs merge
>as soon as we get the first release out the door.  I don't think
>we want to introduce too much new code this close to a release.

The patches to fix up the g77 docs are *very* safe, in case
you're wondering -- aside from deleting a gratuitous (and
non-conforming-in-ANSI-C ;-) comma after the last item in
an enum, they affect only the documentation, not the compiler
or the library.  (I'm referring to patches to intdoc.c, intrin.h,
the intdoc.in->intdoc.h renaming, and so on.)

Generally, the fixes I'm making to other parts of g77 are quite
safe too, because I have a release coming up in less than a week,
but only alpha testing and the release itself will "prove" just
how safe these fixes are.

One of the reasons I did the intdoc.in->intdoc.h change *now*,
instead of putting it off, is that I wanted to reduce the size
of future .diff files that would be needed to make the effective
rename.  g77 0.5.20 already had intdoc.h, it is true, but it
was quite small compared to the one pending for 0.5.21, which is
"full" (every single intrinsic documented!), so it seemed like
now was a worthwhile time to switch.

In the larger scale of egcs, I doubt this concern would amount
to much, as I expect the part of a future release->release patch
to rename intdoc.in to intdoc.h will amount to less than 1% of
the total patch.  ;-)

        tq vm, (burley)

HAVE_STDLIB_H

[Jeffrey A Law]

Note, the HAVE_STDLIB_H patches are breaking builds under sunos4.

These either need to be installed compiler-wide or not installed
at all.

The basic problem is our good friend "free", which conflicts 
with the declaration in tree.h and stdlib.h

And we can't just simply take out the decl in tree.h because some
code doesn't include stdlib.h yet.


Jeff