Re: prototyping

Re: prototyping

[H.J. Lu]

> 
>   In message <m0x0C8V-0004ecC@ocean.lucon.org>you write:
>   > > 
>   > >   In message <m0x07ER-0004ecC@ocean.lucon.org>you write:
>   > >   > I am thinking the other way around since I have removed those
>   > >   > incomplete external function declarations in .c files, using the
>   > >   > ones in .h files instead. I will first send in patches for .h files,
>   > >   > then .c files.
>   > > That's just as good of a place to start.
>   > > 
>   > 
>   > It dosen't work very well.
> I don't see why.
> 
> Go into a .c file, remove all the prototypes for extern things and
> put them into an appropriate .h file.  Remove all other prototypes
> for those same things from other .c files.
> 

It is not that simple. gcc is not designed with prototyping in mind.
It is kind of screwed up in that regard. A simple example, try to
prototype expand_expr () and you will see what I mean. It is just
the beginning :-).

I will see what I can do.


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

Re: prototyping

[Jeffrey A Law]

  In message <m0x0DZq-0004ecC@ocean.lucon.org>you write:
  > It is not that simple. gcc is not designed with prototyping in mind.
  > It is kind of screwed up in that regard. A simple example, try to
  > prototype expand_expr () and you will see what I mean. It is just
  > the beginning :-).
Then skip those which are "hard" during the first pass.

At this stage it doesn't have to be 100% complete -- if we get proper
prototypes in for the majority of the functions, then we've made
significant progress.

You can then go back and work on the harder ones such as expand_expr.

Doing it this way will also mean that it'll be easier to review the
harder ones like expand_expr later.



Jeff

Re: Test result for 970814 on native sparc-sun-solaris2.5.1

[Alexandre Oliva]

mrs@wrs.com (Mike Stump) writes:

> Normally, I don't think we should pollute up a list like this one with
> testresults, but since we have a first snapshot, I thought I would do
> one:

Maybe we could post them to the egcs-bugs list.  After all, errors
detected by testsuites are bugs either in egcs or in the testsuite (or
in both! :-)

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

f/zzz.o comparison failures

[Jeffrey A Law]

Some of you have experienced comparison failures for f/zzz.o when
performing a 3-stage bootstrap of egcs.

This is due to a date and time stamp in f/zzz.o and can be safely
ignored.

The next snapshot will not have comparison failures for f/zzz.o.

Jeff

Re: Test result for 970814 on native sparc-sun-solaris2.5.1

[Jeffrey A Law]

  In message <9708171708.AA03535@modi.xraylith.wisc.edu>you write:
  > btw, static template data members are not being instantiated breaking SGI
  > STL in libg++-2.8.0b6 (the allocator in particular).
I assume you're referring to the libstdc++ tests right?  Do you get an
error like:

/usr/ccs/bin/ld: Unsatisfied symbols:
   __default_alloc_template<false, 0>::end_free(data)
   __default_alloc_template<false, 0>::heap_size(data)
   __default_alloc_template<false, 0>::free_list(data)
   __default_alloc_template<false, 0>::start_free(data)



  > Also, I'm getting a 
  > core dump when compiling libstdc++ tests when compiling with '-g -O2', but 
  > with -g.
I was able to get libstdc++ in 2.8.0b6 built using egcs.

Jeff