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

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

[Mumit Khan]

hjl@lucon.org (H.J. Lu) writes:
> > 
> >   In message <9708171708.AA03535@modi.xraylith.wisc.edu>you write:
> >   > btw, static template data members are not being instantiated breaking S
> GI
> >   > 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)
> > 

Yup. I instantiated these by hand just to test things, but then tmap
core dumped on me with '-g -O2'. The only time tmap works is when I
don't specify '-O*'. 

btw, the instantiations *are* there for i386-linux-gnulibc1, but not
for hppa1.1-hp-hpux10.20. "tmap" dies on either platform with -O*.

Mumit

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

[H.J. Lu]

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

I could build libg++ 2.8.0b6 with my glibc patch on Linux/x86. But
make check failed due to segmentation fault of tmap in libstdc++/tests.


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

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

[Klaus Kaempf]

> 
> 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 shouldn't pollute the list with testresults but how about 'polluting'
a web site (WWW-Gnat comes in mind) with such results and open bugs. Adding a
'responsible' or 'working on' list will help getting the right people to work
on the bugs.

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: Test result for 970814 on native sparc-sun-solaris2.5.1

[Mumit Khan]

mrs@wrs.com (Mike Stump) writes:
> 
> The testsuite is the one from 970707.  What do people think about
> including either libstdc++, and/or testsuite in the egcs
> snapshots/releases?  I've not thought about it too much, but it seems
> like a reasonable thing to do.

Might be very useful, but then there's always download time issue for
those with slower net connection. I personally will welcome it.

btw, static template data members are not being instantiated breaking SGI
STL in libg++-2.8.0b6 (the allocator in particular). Also, I'm getting a 
core dump when compiling libstdc++ tests when compiling with '-g -O2', but 
with -g. Anybody else seen this? This is on a hppa1.1-hp-hpux10.20 using 
GAS from binutils 2.8.1. I'll investigate this further on other platforms.

Mumit

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

[Mike Stump]

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:

                === g++ Summary ===

# of expected passes            3214
# of unexpected successes       5
# of expected failures          109
# of untested testcases         6
/folk/mrs/bin/g++ version egcs-2.90.00 970814 (gcc2-970802 experimental)

The testsuite is the one from 970707.  What do people think about
including either libstdc++, and/or testsuite in the egcs
snapshots/releases?  I've not thought about it too much, but it seems
like a reasonable thing to do.