bug with asm statment in egcs-1.0.2

bug with asm statment in egcs-1.0.2

[Peter Barada]

I found a bug in reg-stack.c:constrain_asm_operands when compiling the
following asm statment for i386:

  asm volatile  (".data;\t.align 4;.LP" "DLbuildtrap"
    ";\t.long 0;.text;\tmovel $.LP" "DLbuildtrap" ",%%edx;\tcall mcount"
    : /* No outputs */
    : /* No inputs */
    : "eax", "edx", "ecx", "st",
      "st(1)","st(2)","st(3)","st(4)","st(5)","st(6)","st(7)" );

with the flags '-O -fstrength-reduce -fsigned-char'

reg-stack.c:constrain_asm_operands() contains the following:

  for (j = 0; j < n_operands; j++)
    constraints[j] = operand_constraints[j];

  /* Compute the number of alternatives in the operands.  reload has
     already guaranteed that all operands have the same number of
     alternatives.  */

  n_alternatives = 1;
  for (q = constraints[0]; *q; q++)
    n_alternatives += (*q == ',');


But when n_operands is zero, then constraints[0] is bogus and it
SIGSEGVs.

If you add a test for n-operands before the for (q = contraints[0]; *q; q++)
then everything is fine...

  n_alternatives = 1;
  if (n_operands)
    for (q = constraints[0]; *q; q++)
      n_alternatives += (*q == ',');

-- 
Peter Barada                            pbarada@wavemark.com
Wizard                                  781-270-7098 x226
WaveMark Technologies, Inc.             781-270-0193 (fax)

"Real men know that you should never attempt to accomplish with words
what you can do with a flame thrower" --Bruce Ferstein

Re: bug with asm statment in egcs-1.0.2

[Jeffrey A Law]

  In message < 199804212116.RAA20017@miacomet.wavemark.com >you write:
  > 
  > I found a bug in reg-stack.c:constrain_asm_operands when compiling the
  > following asm statment for i386:
  > 
  >   asm volatile  (".data;\t.align 4;.LP" "DLbuildtrap"
  >     ";\t.long 0;.text;\tmovel $.LP" "DLbuildtrap" ",%%edx;\tcall mcount"
  >     : /* No outputs */
  >     : /* No inputs */
  >     : "eax", "edx", "ecx", "st",
  >       "st(1)","st(2)","st(3)","st(4)","st(5)","st(6)","st(7)" );
  > 
  > with the flags '-O -fstrength-reduce -fsigned-char'
  > 
  > reg-stack.c:constrain_asm_operands() contains the following:
  > 
  >   for (j = 0; j < n_operands; j++)
  >     constraints[j] = operand_constraints[j];
  > 
  >   /* Compute the number of alternatives in the operands.  reload has
  >      already guaranteed that all operands have the same number of
  >      alternatives.  */
  > 
  >   n_alternatives = 1;
  >   for (q = constraints[0]; *q; q++)
  >     n_alternatives += (*q == ',');
  > 
  > 
  > But when n_operands is zero, then constraints[0] is bogus and it
  > SIGSEGVs.
I believe this is fixed in the development sources.

jeff

Re: bug with asm statment in egcs-1.0.2

[H.J. Lu]

>   > 
>   > But when n_operands is zero, then constraints[0] is bogus and it
>   > SIGSEGVs.
> I believe this is fixed in the development sources.
> 

Can we fix it in 1.0.3?

-- 
H.J. Lu (hjl@gnu.org)

Re: bug with asm statment in egcs-1.0.2

[Jeffrey A Law]

  In message < m0yS1U5-00058vC@ocean.lucon.org >you write:
  > >   > 
  > >   > But when n_operands is zero, then constraints[0] is bogus and it
  > >   > SIGSEGVs.
  > > I believe this is fixed in the development sources.
  > > 
  > 
  > Can we fix it in 1.0.3?
No.  As I mentioned before.  1.0.3 is to fix problems for RedHat
and that's it.  1.0.3 is already frozen unless RedHat runs into
some kind problem in their final builds.

jeff

Re: bug with asm statment in egcs-1.0.2

[Wolfram Gloger]

> No.  As I mentioned before.  1.0.3 is to fix problems for RedHat
> and that's it.  1.0.3 is already frozen unless RedHat runs into
> some kind problem in their final builds.

Sorry, but this sounds a bit worrysome.  There's _much_ more to egcs
usage than RedHat system builds.  If someone were to report a critical
bug (possibly with a 3-line patch) in 1.0.x now (with 1.1 unreleased,
and its release date understandably uncertain) causing, say, the Linux
kernel or glibc to be miscompiled, would you even consider be make an
egcs-1.0.x+1 release to fix it ?

If the answer is no, I would certainly not be in a position to
criticise that decision, however you should then clearly state that
bug reports for 1.0.x are useless (to me, this seems to be especially
true for C++ bugs).

Your valuable time is scarce and building new 1.0 releases takes time.
However, creating meaningful bug reports also takes lots of time.  It
would be a shame if all that time would be wasted; it also starts to
remind me of the long time when the point in gcc-2.7 bug reports was
rather questionable.

Regards,
Wolfram.
-- 
`Surf the sea, not double-u three...'
wmglo@dent.med.uni-muenchen.de

Re: bug with asm statment in egcs-1.0.2

[Joe Buck]

> > No.  As I mentioned before.  1.0.3 is to fix problems for RedHat
> > and that's it.  1.0.3 is already frozen unless RedHat runs into
> > some kind problem in their final builds.

> Sorry, but this sounds a bit worrysome.  There's _much_ more to egcs
> usage than RedHat system builds.  If someone were to report a critical
> bug (possibly with a 3-line patch) in 1.0.x now (with 1.1 unreleased,
> and its release date understandably uncertain) causing, say, the Linux
> kernel or glibc to be miscompiled, would you even consider be make an
> egcs-1.0.x+1 release to fix it ?

If there is a bug that affects the compilation of the Linux kernel or
of glibc, it would affect Red Hat and would therefore be high priority.
But the reason for 1.0.3 is to *quickly* get out a release that is
good enough to build Linux/Alpha.  We can't fix every bug in the universe.

> If the answer is no, I would certainly not be in a position to
> criticise that decision, however you should then clearly state that
> bug reports for 1.0.x are useless (to me, this seems to be especially
> true for C++ bugs).

The bug reports are still useful, of course; it's just that some fixes
will have to wait until 1.1.  This is not gcc-2.8.0 we're building here;
you won't have to wait two years for 1.1.

> Your valuable time is scarce and building new 1.0 releases takes time.
> However, creating meaningful bug reports also takes lots of time.  It
> would be a shame if all that time would be wasted; it also starts to
> remind me of the long time when the point in gcc-2.7 bug reports was
> rather questionable.

Sigh.  You're acting like 1.0.x is all you'll have in your lifetime.
The egcs team isn't going to make you wait 2.5 years for the next major
release.

Re: bug with asm statment in egcs-1.0.2

[Michael Alan Dorman]

Joe Buck <jbuck@synopsys.com> writes:

> But the reason for 1.0.3 is to *quickly* get out a release that is
> good enough to build Linux/Alpha.  We can't fix every bug in the
> universe.

Well, the porters for the AXP version of Debian GNU/Linux has been
using egcs as our primary compiler since 1.0 came out, and I'm
currently running an egcs-compiled kernel and glibc---no problems in
recent memory.

Heck, I was able to debug a C++ program with the latest GDB snapshot
with no problems.  Quite stable.

That leaves me curious as to what problems the RedHat people are
having that are considered sufficiently showstopping to warrant
forcing a new compiler release.  Any ideas?

Mike

Re: bug with asm statment in egcs-1.0.2

[Toon Moene]

Joe Buck <jbuck@synopsys.com> writes:

>> But the reason for 1.0.3 is to *quickly* get out a release that is
>> good enough to build Linux/Alpha.  We can't fix every bug in the
>> universe.

Michael Dorman:

>  Well, the porters for the AXP version of Debian GNU/Linux
>  has been using egcs as our primary compiler since 1.0
>  came out

[ ... ]

>  That leaves me curious as to what problems the RedHat
>  people are having that are considered sufficiently
>  showstopping to warrant forcing a new compiler release.

Although the 1.0.3 release will contain a bugfix for the Alpha, it  
is in the Fortran Frontend, and not Linux specific at all.

No, I suspect that the problems that have to be solved by 1.0.3 are  
entirely due to the i666, the architecture of the Beast (1/2 :-)

Toon.

Re: bug with asm statment in egcs-1.0.2

[Jeffrey A Law]

  In message < 9804241207.AA26253@moene.indiv.nluug.nl >you write:
  > >  That leaves me curious as to what problems the RedHat
  > >  people are having that are considered sufficiently
  > >  showstopping to warrant forcing a new compiler release.
  > 
  > Although the 1.0.3 release will contain a bugfix for the Alpha, it  
  > is in the Fortran Frontend, and not Linux specific at all.
Right.  It's the "negative index patch".   It's a generic fix to the
Fortran front end.  It's something we'd tried to fix in 1.0.2, but
got it wrong :(  And apparently it is something that RedHat gets
lots of complaints about.

  > No, I suspect that the problems that have to be solved by 1.0.3 are  
  > entirely due to the i666, the architecture of the Beast (1/2 :-)
Basically true.

jeff

Re: bug with asm statment in egcs-1.0.2

[Jeffrey A Law]

  In message < 19980423094919.26728.qmail@md.dent.med.uni-muenchen.de >you write:
  > > No.  As I mentioned before.  1.0.3 is to fix problems for RedHat
  > > and that's it.  1.0.3 is already frozen unless RedHat runs into
  > > some kind problem in their final builds.
  > 
  > Sorry, but this sounds a bit worrysome.  There's _much_ more to egcs
  > usage than RedHat system builds.
Absolutely.  However, we have to make tough decisions about how
much time/effort to put into minor releases because each minor
release we do takes time away from getting egcs-1.1 ready.  Both
in terms of actually applying patches, testing, making releases
*and* explaining to folks why a particular bug isn't going to be
fixed in a minor release.

Furthermore, everyone has pet patches they want to get into the
minor releases.  How do you go about selecting one group of patches
over another?  Given time, I probably could have come up with
several dozen code generation/compiler abort issues.

The way this problem is solved is a minor release has a set of very
specific goals.  For 1.0.3 those goals were to be able to build
the RedHat 5.1 distribution.  Anything which does not directly tie
into those goals is rejected.

It's probably worth noting we really didn't want to make a 1.0.3
release in the first place -- we wanted to end-of-life the
egcs-1.0.x tree at 1.0.2.

However, strategically, the time spent getting egcs-1.0.x in good
enough shape to be included in the RedHat 5.1 release was time well
spent for the project.


  > bug (possibly with a 3-line patch) in 1.0.x now (with 1.1 unreleased,
  > and its release date understandably uncertain) causing, say, the Linux
  > kernel or glibc to be miscompiled, would you even consider be make an
  > egcs-1.0.x+1 release to fix it ?
We would *consider* it; however, the default action at this time will
be to fix it for 1.1 without making a minor release of 1.0.x.


  > If the answer is no, I would certainly not be in a position to
  > criticise that decision, however you should then clearly state that
  > bug reports for 1.0.x are useless (to me, this seems to be especially
  > true for C++ bugs).
I disagree totally about the usefullness of bug reports from 1.0.x --
just because we don't make a minor release to fix the bug doesn't
mean the bug report isn't useful.  It allows us to fix the bug for
egcs-1.1.

In the case of C++, quite a few of the bug reports are for things we've
fixed for egcs-1.1.  This tells me that we need to wrap up some of
the ongoing work, stabilize the tree and get egcs-1.1 out the door.
And (of course) spending time on egcs-1.0.x minor releases delays
getting egcs-1.1 out the door...

It should also be noted that nothing stops individual folks from
making their own minor releases.  If HJ (or anyone else) wants to
make egcs-1.0.3.1 and maintain it, we're not going to stop them.



jeff