egcs-1.1.1 issues

egcs-1.1.1 issues

[Jeffrey A Law]

We should be thinking about what bugs we want/need to address for
egcs-1.1.1.


As in previous minor releases, we want to concentrate on major bugs
only, not every bug that's been reported.

I haven't had a chance to walk back through the new bug reports, but
I have seen lots of problems reported with QT (particularly on Alphas)
and various PPC Linux problems.  So those problems should probably
deserve some consideration for egcs-1.1.1.

Basically I'd kind of like to hear from the various groups (C++,
Fortran, various backend/target folks) about the most serious bugs
they've seen reported against egcs-1.1 so that we can at least get
a list of things we'd like to fix, and from that list select the
ones that we actually can/should fix for egcs-1.1.1.

Note I'm unavailable next week.  I doubt anything significant
will happen on egcs-1.1.1 until early October anyway.

jeff

Re: egcs-1.1.1 issues

[Bruce Korb]

Jeffrey A Law wrote:

> We should be thinking about what [[...]] we want/need to address for
> egcs-1.1.1.

fast-fixincludes?

Bruce

Re: egcs-1.1.1 issues

[Jeffrey A Law]

  In message < 35FFE1F1.351C7966@datadesign.com >you write:
  > Jeffrey A Law wrote:
  > 
  > > We should be thinking about what [[...]] we want/need to address for
  > > egcs-1.1.1.
  > 
  > fast-fixincludes?
Do we have specific fast-fixincludes bugs we need to fix?

egcs-1.1.1 is for critical bugfixes only, if you have some in fast
fixincludes, then we should consider them.

jeff

Re: egcs-1.1.1 issues

[Theodore Papadopoulo]

	Would you consider having a fixinclude pass for X11 header 
adding the missing int return type to avoid all the warnings with 
egcs/g++ ??

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: egcs-1.1.1 issues

[Jeffrey A Law]

  In message < 199809171120.NAA03228@mururoa.inria.fr >you write:
  > 	Would you consider having a fixinclude pass for X11 header 
  > adding the missing int return type to avoid all the warnings with 
  > egcs/g++ ??
Unlikely.    And certainly not for egcs-1.1.1.

You're better off disabling the offending warning via -Wno-return-type.

jeff

Re: egcs-1.1.1 issues

[Bruce Korb]

Jeffrey A Law wrote:

> Do we have specific fast-fixincludes bugs we need to fix?

No.

> egcs-1.1.1 is for critical bugfixes only, if you have some in fast
> fixincludes, then we should consider them.

Sorry for any panic.  I was really meaning to ask when it mightbecome the
default.  So far, in the past several months there have
been about two complaints.  One was not related to fast fix, the
other required adding a couple of files to the file list for the
"avoid bool" fix.  This means either:

1.  Fast fix works flawlessly (well, as well as fixincludes does...)

or,

2.  Nobody uses it.

Since I know the following:

a.  The generated shell script produces the identical commands to fixincludes
b.  All of the variations of fix types that I can think of have produced
    identical results for both the script output and the program output
c.  A couple of people have raised questions

I am therefore inclined to think that there are no serious bugs.
I would, however, get more warm and fuzzies if I were to get a number
of emails saying, "it worked on my cpu-platform-os".

Regards,
    Bruce

Re: egcs-1.1.1 issues

[Robert Lipe]

Bruce Korb wrote:

> Since I know the following [ related to fast fixincludes ] :

> a.  The generated shell script produces the identical commands to fixincludes
> b.  All of the variations of fix types that I can think of have produced
>     identical results for both the script output and the program output
> c.  A couple of people have raised questions
> 
> I am therefore inclined to think that there are no serious bugs.
> I would, however, get more warm and fuzzies if I were to get a number
> of emails saying, "it worked on my cpu-platform-os".

Perhaps we should at least build a plan for the steps we take to enable
this as the default.  Maybe we start by asking testers of the trunk to
configure '--with-fast-fixincludes'.  Once that has had sufficient air
time without problems we make it the default.  Then we proceed to remove
(or at least mark as deprecated) the old stuff.  There may be pitstops
along the way or other steps needed, but maybe a clear "TODO" list is in
order.

Let's just figure out how to get this out of limbo so it can start
helping users and developers.

RJL

Re: egcs-1.1.1 issues

[Bruce Korb]

Robert Lipe wrote:

> > Since I know the following [ related to fast fixincludes ] :

> [...]]

> Perhaps we should at least build a plan for the steps we take to enable
> this as the default.  Maybe we start by asking testers of the trunk to
> configure '--with-fast-fixincludes'.  Once that has had sufficient air
> time without problems we make it the default.  Then we proceed to remove
> (or at least mark as deprecated) the old stuff.  There may be pitstops
> along the way or other steps needed, but maybe a clear "TODO" list is in
> order.
>
> Let's just figure out how to get this out of limbo so it can start
> helping users and developers.

I have already wired it so that by moving the fixinc.* files fromegcs/gcc to
egcs/contrib/fixinc and deleting egcs/gcc/fixincludes
you will have exactly the same result you have today.  From that point,
you can start removing the egcs/contrib/fixinc.??* files that got
moved in and removing the special entries in the egcs/contrib/mkfixinc.sh
file.  This would be done only as it is verified that either the
fixincl program or the inclhack.sh script produced correct results.
(The mkfixinc.sh script tries to build a working program and, if it fails,
then copies the massive inclhack.sh script into place.)


By the way, I *would* like to distribute autogen via anonymous
CVS off of egcs.cygnus.com.  That way, developers would be able
to do a "make" in the egcs/contrib/fixinc directory (assuming they
install the autogen binary).  Would it be best as egcs/contrib/autogen/...
or as straight up autogen/...*, a la guile?

Re: egcs-1.1.1 issues

[Jeffrey A Law]

  In message < 19980921132907.J27681@dgii.com >you write:
  > Perhaps we should at least build a plan for the steps we take to enable
  > this as the default.  Maybe we start by asking testers of the trunk to
  > configure '--with-fast-fixincludes'.  Once that has had sufficient air
  > time without problems we make it the default.  Then we proceed to remove
  > (or at least mark as deprecated) the old stuff.  There may be pitstops
  > along the way or other steps needed, but maybe a clear "TODO" list is in
  > order.
  > 
  > Let's just figure out how to get this out of limbo so it can start
  > helping users and developers.
I think we should pick a small number of platforms which folks actively
use and maintain, flip them first.  If the results are generally positive,
we can flip the rest en-masse.

jeff

Re: egcs-1.1.1 issues

[Jason Merrill]

>>>>> Robert Lipe <robertl@dgii.com> writes:

 > Perhaps we should at least build a plan for the steps we take to enable
 > this as the default.  Maybe we start by asking testers of the trunk to
 > configure '--with-fast-fixincludes'.  Once that has had sufficient air
 > time without problems we make it the default.  Then we proceed to remove
 > (or at least mark as deprecated) the old stuff.

My inclination would be to just turn it on now.  There's no need to handle
this so delicately, if it's expected to work.

Jason

Re: egcs-1.1.1 issues

[Joe Buck]

[ fast fixincludes ]
Jason writes:
> My inclination would be to just turn it on now.  There's no need to handle
> this so delicately, if it's expected to work.

Yes, the only way you get bugs out is to have people bang on it.  Why
not just make it the default in the next snapshot?  Then tell people to
try it, and if it fails, mail in a report of what went wrong and then
rebuild with it turned off to find other bugs.

Re: egcs-1.1.1 issues

[Jeffrey A Law]

  In message < 199809221621.JAA06218@atrus.synopsys.com >you write:
  > [ fast fixincludes ]
  > Jason writes:
  > > My inclination would be to just turn it on now.  There's no need to handl
  > e
  > > this so delicately, if it's expected to work.
  > 
  > Yes, the only way you get bugs out is to have people bang on it.  Why
  > not just make it the default in the next snapshot?  Then tell people to
  > try it, and if it fails, mail in a report of what went wrong and then
  > rebuild with it turned off to find other bugs.
OK.  Let's let it rip.  

jeff

Re: egcs-1.1.1 issues; Fortran

[Toon Moene]

>  Basically I'd kind of like to hear from the various groups
>  (C++, Fortran, various backend/target folks) about the
>  most serious bugs they've seen reported against egcs-1.1
>  so that we can at least get a list of things we'd like
>  to fix, and from that list select the ones that we
>  actually can/should fix for egcs-1.1.1.

I think it would be a good idea to include the documentation  
updates Craig sent in just after the release of 1.1 ;-) and Dave's  
"some g77 doc'toring".

Furthermore, the "recursive I/O bug" patch (whichever was approved  
by Craig) should go into libf2c (Note that I still see test suite  
output coming in with a failure in io0.f, which tests this - did the  
patch really go into the mainline ?).

Other open bug reports _against the release_:

On the 7th of September Marc Dejardin <Marc.Dejardin@cern.ch>  
posted a report on an "internal error--insn does not satisfy its  
constraints" when compiling a routine from CERNLIB on a powerpc  
based machine.

Looks like a powerpc backend problem.

HTH,
Toon.

Re: egcs-1.1.1 issues; Fortran

[Craig Burley]

>I think it would be a good idea to include the documentation  
>updates Craig sent in just after the release of 1.1 ;-) and Dave's  
>"some g77 doc'toring".

I'm pretty sure my (earlier) updates already are in; Dave's might
not be, but, as doc changes, I'm not sure whether they should go in.
(I lean towards putting them in, since they can't destabilize
anything, and add/fix plenty of stuff.)

>Furthermore, the "recursive I/O bug" patch (whichever was approved  
>by Craig) should go into libf2c (Note that I still see test suite  
>output coming in with a failure in io0.f, which tests this - did the  
>patch really go into the mainline ?).

I believe Jeff already committed my one-line version of your patch
to the branch.  Perhaps the mainline committal got lost due to my
asking for the larger patch to not go in wholesale; the one-line
patch definitely should.  If it doesn't "just happen", I'll look
into it, later.

        tq vm, (burley)

Re: egcs-1.1.1 issues; Fortran

[Dave Love]

>>>>> "Craig" == Craig Burley <burley@gnu.org> writes:

 Craig> I believe Jeff already committed my one-line version of your patch
 Craig> to the branch.  

Yes.

 Craig> Perhaps the mainline committal got lost due to my asking for
 Craig> the larger patch to not go in wholesale; the one-line patch
 Craig> definitely should.

I think you explicitly asked for the one-liner not to go on the trunk.
(This area is presumably affected by dmg's recent libI77 change which
is already in the CVS libf2c Netlib branch for ease of merging.)

Re: egcs-1.1.1 issues; Fortran

[Jeffrey A Law]

  In message <9809161858.AA12914@moene.indiv.nluug.nl>you write:
  > >  Basically I'd kind of like to hear from the various groups
  > >  (C++, Fortran, various backend/target folks) about the
  > >  most serious bugs they've seen reported against egcs-1.1
  > >  so that we can at least get a list of things we'd like
  > >  to fix, and from that list select the ones that we
  > >  actually can/should fix for egcs-1.1.1.
  > 
  > I think it would be a good idea to include the documentation  
  > updates Craig sent in just after the release of 1.1 ;-)
Already installed.

  > and Dave's  "some g77 doc'toring".
This would be fine too if someone sends me the patch :-)  Or Dave can just
install the doc changes on the branch.

  > Furthermore, the "recursive I/O bug" patch (whichever was approved  
  > by Craig) should go into libf2c (Note that I still see test suite  
  > output coming in with a failure in io0.f, which tests this - did the  
  > patch really go into the mainline ?).
I've given Dave the OK to install this fix on the branch too.


  > Other open bug reports _against the release_:
  > 
  > On the 7th of September Marc Dejardin <Marc.Dejardin@cern.ch>  
  > posted a report on an "internal error--insn does not satisfy its  
  > constraints" when compiling a routine from CERNLIB on a powerpc  
  > based machine.
  > 
  > Looks like a powerpc backend problem.
No clue where we stand on this one.

jeff

Re: egcs-1.1.1 issues; Fortran

[David Edelsohn]

>>>>> Jeffrey A Law writes:

>> On the 7th of September Marc Dejardin <Marc.Dejardin@cern.ch>  
>> posted a report on an "internal error--insn does not satisfy its  
>> constraints" when compiling a routine from CERNLIB on a powerpc  
>> based machine.
>> 
>> Looks like a powerpc backend problem.

Jeff> No clue where we stand on this one.

	This looks like another PIC/GOT problem.  movdf is trying to
reference a symbol described by a LO_SUM.  I suspect that the "address"
needs to be split / legitimized somehow.  Probably movsf and movdf
define_expand patterns need some of the mechanism employed in movsi for
handling these compound addresses, but I am not sure.

David

Re: egcs-1.1.1 issues; Fortran

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes:

 >> and Dave's  "some g77 doc'toring".
 Jeff> This would be fine too if someone sends me the patch :-)  Or Dave can just
 Jeff> install the doc changes on the branch.

Sorry, I lost track of this.  I'll install if it's appropriate.  Yes
or no, Craig?

Re: egcs-1.1.1 issues; Fortran

[Craig Burley]

>>>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes:
>
> >> and Dave's  "some g77 doc'toring".
> Jeff> This would be fine too if someone sends me the patch :-)  Or Dave can just
> Jeff> install the doc changes on the branch.
>
>Sorry, I lost track of this.  I'll install if it's appropriate.  Yes
>or no, Craig?

Sounds okay, but I've lost track of what the patch *does*.  However,
if it's any of your improvements to the docs, go ahead!

        tq vm, (burley)

Re: egcs-1.1.1 issues

[Laurent Bonnaud]

>>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes:
Jeff> 
Jeff> I haven't had a chance to walk back through the new bug reports, but
Jeff> I have seen lots of problems reported with QT (particularly on Alphas)
Jeff> and various PPC Linux problems.  So those problems should probably
Jeff> deserve some consideration for egcs-1.1.1.

Hi,

I have reported an ICE40 a few monthes ago and it is still in egcs-1.1
and in egcs-2.92.04 19980906 :

  http://www.cygnus.com/ml/egcs-bugs/1998-May/0472.html

The source is included below for your convenience.

Several other peoples have reported ICEs 40, but i don't know if they
are related.

Here are other (less serious) bugs :

  http://www.cygnus.com/ml/egcs-bugs/1998-May/0612.html

  http://www.cygnus.com/ml/egcs-bugs/1998-Apr/0605.html

-- 
Laurent.

template <int i>
struct Sized {
  float array[i];
};

template <class T>
struct rank_type {
  enum { value = 0 };
};

template <class T,int N>
struct rank_type<T[N]> {
  enum { value = 1 + rank_type<T>::value };
};

template <class T>
Sized<rank_type<T[1]>::value> type_deduction_helper(T x[])
{
  return Sized<rank_type<T[1]>::value>();
}

#define Rank(x) (sizeof(type_deduction_helper(x).array)/(sizeof(float)))

void f()
{
  double d[10][10][10];				  // works for double, too
  int x[Rank(d)];
}

RE: egcs-1.1.1 issues

[Gary Thomas]

On 16-Sep-98 Jeffrey A Law wrote:
> 
> I haven't had a chance to walk back through the new bug reports, but
> I have seen lots of problems reported with QT (particularly on Alphas)
> and various PPC Linux problems.  So those problems should probably
> deserve some consideration for egcs-1.1.1.
> 

I'm currently trying to understand these problems.  They stem from the
"eh" chain getting destroyed by EGCS-1.1 compiled QT code.

------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------

Re: egcs-1.1.1 issues

[Gerald Pfeifer]

On Wed, 16 Sep 1998, Jeffrey A Law wrote:
> We should be thinking about what bugs we want/need to address for
> egcs-1.1.1.

Considering many bug reports concerning ICEs recently, I'd like to
suggest adding the improved error messages for ICEs that have made it
(will make it?) into the main branch.


> Basically I'd kind of like to hear from the various groups (C++,
> Fortran, various backend/target folks) about the most serious bugs
> they've seen reported against egcs-1.1 [...]

As part of the "usability group" ;-), how about the gcc/README patch I
have submitted two weeks ago? (I Haven't received any response, though.)

http://www.cygnus.com/ml/egcs-patches/1998-Sep/0012.html


> Note I'm unavailable next week.  I doubt anything significant
> will happen on egcs-1.1.1 until early October anyway.

You once thought about egcs-1.1 + patches + new STL becoming 1.2.
Is that still under consideration?

(I didn't notice any problems with the new STL in local projects
nor on egcs-bugs, but I have no strong preference either way.)

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: egcs-1.1.1 issues; Fortran

[Jeffrey A. Law]

  In message <9809161858.AA12914@moene.indiv.nluug.nl>you write:
  > >  Basically I'd kind of like to hear from the various groups
  > >  (C++, Fortran, various backend/target folks) about the
  > >  most serious bugs they've seen reported against egcs-1.1
  > >  so that we can at least get a list of things we'd like
  > >  to fix, and from that list select the ones that we
  > >  actually can/should fix for egcs-1.1.1.
  > 
  > I think it would be a good idea to include the documentation  
  > updates Craig sent in just after the release of 1.1 ;-)
Already installed.

  > and Dave's  "some g77 doc'toring".
This would be fine too if someone sends me the patch :-)  Or Dave can just
install the doc changes on the branch.

  > Furthermore, the "recursive I/O bug" patch (whichever was approved  
  > by Craig) should go into libf2c (Note that I still see test suite  
  > output coming in with a failure in io0.f, which tests this - did the  
  > patch really go into the mainline ?).
I've given Dave the OK to install this fix on the branch too.


  > Other open bug reports _against the release_:
  > 
  > On the 7th of September Marc Dejardin <Marc.Dejardin@cern.ch>  
  > posted a report on an "internal error--insn does not satisfy its  
  > constraints" when compiling a routine from CERNLIB on a powerpc  
  > based machine.
  > 
  > Looks like a powerpc backend problem.
No clue where we stand on this one.

jeff