GCC 3.0.3

GCC 3.0.3

[Mark Mitchell]

Please remember that Dec 1. is the freeze date for changes going into
GCC 3.0.3.  Non-documentation changes will require my approval after
that point.

I have received some important bug reports from people.  I will be
posting a list of those shortly.  We will try to fix these before the
release if possible.

Thank you,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC 3.0.3

[Joe Buck]

> Please remember that Dec 1. is the freeze date for changes going into
> GCC 3.0.3.  Non-documentation changes will require my approval after
> that point.
> 
> I have received some important bug reports from people.  I will be
> posting a list of those shortly.  We will try to fix these before the
> release if possible.

I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3.
Actually I don't think any porting is needed, as it's a fix to mangle.c,
which hasn't had many changes; no, it doesn't change the ABI because
hitting the relevant code caused a core dump before.

This PR is an ICE and a regression from 2.95.x.

I believe that the relevant patch is

2001-11-17  Kriang Lerdsuwanakij  <lerdsuwa@users.sourceforge.net>

	* mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR,
	CONST_CAST_EXPR.
	* operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR.

Re: GCC 3.0.3

[Mark Mitchell]

> I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3.
> Actually I don't think any porting is needed, as it's a fix to mangle.c,
> which hasn't had many changes; no, it doesn't change the ABI because
> hitting the relevant code caused a core dump before.
>
> This PR is an ICE and a regression from 2.95.x.
>
> I believe that the relevant patch is
>
> 2001-11-17  Kriang Lerdsuwanakij  <lerdsuwa@users.sourceforge.net>
>
> 	* mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR,
> 	CONST_CAST_EXPR.
> 	* operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR.

Yes, this is OK.  Please apply the patch.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0.3

[Joe Buck]

I wrote:
> > I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3.
> > Actually I don't think any porting is needed, as it's a fix to mangle.c,
> > which hasn't had many changes; no, it doesn't change the ABI because
> > hitting the relevant code caused a core dump before.
> >
> > This PR is an ICE and a regression from 2.95.x.
> >
> > I believe that the relevant patch is
> >
> > 2001-11-17  Kriang Lerdsuwanakij  <lerdsuwa@users.sourceforge.net>
> >
> > 	* mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR,
> > 	CONST_CAST_EXPR.
> > 	* operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR.

Mark writes:
> Yes, this is OK.  Please apply the patch.

I don't have write access, so we'll need a volunteer to apply the patch.

Joe

Re: GCC 3.0.3

[Mark Mitchell]

> I don't have write access

You should.

> so we'll need a volunteer to apply the patch.

If you produce the patch and ChangeLog, and test it,
I will apply it for you.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0.3

[Joe Buck]

I wrote
> > I don't have write access

Mark writes:
> You should.

I currently only have GNATS write access, not CVS write.

> > so we'll need a volunteer to apply the patch.
> 
> If you produce the patch and ChangeLog, and test it,
> I will apply it for you.

It appears that Kriang's change to the trunk applies cleanly to
the 3.0 version.

I'll bootstrap and run tests, and if all goes well you'll get
it tomorrow.  Assuming no problems, the changelog entry should
just be the one from Kriang, which I will re-send.

Joe

Re: GCC 3.0.3

[Mark Mitchell]

--On Thursday, November 29, 2001 04:14:59 PM -0800 Joe Buck 
<jbuck@synopsys.COM> wrote:

> I wrote
>> > I don't have write access
>
> Mark writes:
>> You should.
>
> I currently only have GNATS write access, not CVS write.

Sorry, I was too terse; I meant "you should arrange to have CVS
write access". :-)

>
> I'll bootstrap and run tests, and if all goes well you'll get
> it tomorrow.  Assuming no problems, the changelog entry should
> just be the one from Kriang, which I will re-send.

Thanks.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0.3

[Mark Mitchell]

--On Thursday, November 29, 2001 04:14:59 PM -0800 Joe Buck 
<jbuck@synopsys.COM> wrote:

> I wrote
>> > I don't have write access
>
> Mark writes:
>> You should.
>
> I currently only have GNATS write access, not CVS write.

Sorry, I was too terse; I meant "you should arrange to have CVS
write access". :-)

>
> I'll bootstrap and run tests, and if all goes well you'll get
> it tomorrow.  Assuming no problems, the changelog entry should
> just be the one from Kriang, which I will re-send.

Thanks.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0.3

[Joe Buck]

I wrote
> > I don't have write access

Mark writes:
> You should.

I currently only have GNATS write access, not CVS write.

> > so we'll need a volunteer to apply the patch.
> 
> If you produce the patch and ChangeLog, and test it,
> I will apply it for you.

It appears that Kriang's change to the trunk applies cleanly to
the 3.0 version.

I'll bootstrap and run tests, and if all goes well you'll get
it tomorrow.  Assuming no problems, the changelog entry should
just be the one from Kriang, which I will re-send.

Joe

Re: GCC 3.0.3

[Mark Mitchell]

> I don't have write access

You should.

> so we'll need a volunteer to apply the patch.

If you produce the patch and ChangeLog, and test it,
I will apply it for you.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0.3

[Joe Buck]

I wrote:
> > I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3.
> > Actually I don't think any porting is needed, as it's a fix to mangle.c,
> > which hasn't had many changes; no, it doesn't change the ABI because
> > hitting the relevant code caused a core dump before.
> >
> > This PR is an ICE and a regression from 2.95.x.
> >
> > I believe that the relevant patch is
> >
> > 2001-11-17  Kriang Lerdsuwanakij  <lerdsuwa@users.sourceforge.net>
> >
> > 	* mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR,
> > 	CONST_CAST_EXPR.
> > 	* operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR.

Mark writes:
> Yes, this is OK.  Please apply the patch.

I don't have write access, so we'll need a volunteer to apply the patch.

Joe

Re: GCC 3.0.3

[Mark Mitchell]

> I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3.
> Actually I don't think any porting is needed, as it's a fix to mangle.c,
> which hasn't had many changes; no, it doesn't change the ABI because
> hitting the relevant code caused a core dump before.
>
> This PR is an ICE and a regression from 2.95.x.
>
> I believe that the relevant patch is
>
> 2001-11-17  Kriang Lerdsuwanakij  <lerdsuwa@users.sourceforge.net>
>
> 	* mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR,
> 	CONST_CAST_EXPR.
> 	* operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR.

Yes, this is OK.  Please apply the patch.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

fix for PR 4447: is this really correct?

[Joe Buck]

I wrote:

> I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3.
> Actually I don't think any porting is needed, as it's a fix to mangle.c,
> which hasn't had many changes; no, it doesn't change the ABI because
> hitting the relevant code caused a core dump before.
>
> This PR is an ICE and a regression from 2.95.x.

> I believe that the relevant patch is
> 
> 2001-11-17  Kriang Lerdsuwanakij  <lerdsuwa@users.sourceforge.net>
> 
> 	* mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR,
> 	CONST_CAST_EXPR.
> 	* operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR.

Mark approved, assuming the usual testing requirements are met.

I've now verified that this fix doesn't break any C++ or libstdc++ tests
(other tests aren't relevant since this only affects cc1plus).

But I am now not sure that this fix is quite correct, though it does
improve things.

Here's the testcase:
----------------------------------------------
template<bool B,int I>
class T {
public:
    T(int);
};

template<bool B1,bool B2,int I1,int I2>
T<(B1&&B2),I1+I2-int(B1&&B2)> 
func(T<B1,I1> a, T<B2,I2> b) {
    return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2);
}

void foo(T<true,3> a, T<true,4>b) {
    func(a, b);
}
----------------------------------------------

gcc 3.0 through 3.0.2 get an ICE in the name mangler.  With Kriang's
patch, the code compiles, but doing

nm -p crash.o | c++filt

on Solaris gives


0000000000 T foo(T<true, 3>, T<true, 4>)
0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> func<true, true, 3, 4>(T<true, 3>, T<true, 4>)

rather than

0000000000 T foo(T<true, 3>, T<true, 4>)
0000000000 T T<true, 6> func<true, true, 3, 4>(T<true, 3>, T<true, 4>)

as I would expect.  It may be that the oddball expression for the return
type will not affect correctness and will just contribute to bloat instead
(for the purpose of "linkonce" directives, instantiations that are really
the same will look different).  But it looks wrong.

Comments?  I may still want this for 3.0.3, because it does make some
cases that ICE'd before work correctly (in my fixed-point computation
examples the relevant functions are inline so these oddball symbols
probably won't even appear).

Re: fix for PR 4447: is this really correct?

[Kriang Lerdsuwanakij]

Hi
I have checked the ABI specifications 
(http://www.codesourcery.com/cxx-abi/abi.html)
before starting on this patch.  And this bloat mangling behavior is what 
the ABI intended.
Following is from the specification with relevant clause capitalized:

   An expression, e.g., "B<(J+1)/2>", is encoded with a prefix traversal of 
the operators
   involved, delimited by "X...E". The operators are encoded using their 
two letter mangled
   names. For example, "B<(J+1)/2>", if J is the third template parameter, 
becomes
   "1BI Xdv pl T1_ Li1E Li2E E E" (the blanks are present only to visualize 
the decomposition).
   Note that the expression is mangled WITHOUT CONSTANT FOLDING OR OTHER
   SIMPLIFICATION, and without parentheses, which are implicit in the 
prefix representation.
   Except for the parentheses, therefore, it represents the source token 
stream. (C++ Standard
   reference 14.5.5.1 p. 5.)

In fact, expressions (involving any operator except type casts) are already 
mangled that way
without my patch.  I can't think of an example that causes ambiguity if 
constant folding is
performed but it looks possible :)

--Kriang

At 11:20 30/11/01 -0800, Joe Buck wrote:
>But I am now not sure that this fix is quite correct, though it does
>improve things.
>
>Here's the testcase:
>----------------------------------------------
>template<bool B,int I>
>class T {
>public:
>     T(int);
>};
>
>template<bool B1,bool B2,int I1,int I2>
>T<(B1&&B2),I1+I2-int(B1&&B2)>
>func(T<B1,I1> a, T<B2,I2> b) {
>     return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2);
>}
>
>void foo(T<true,3> a, T<true,4>b) {
>     func(a, b);
>}
>----------------------------------------------
>
>gcc 3.0 through 3.0.2 get an ICE in the name mangler.  With Kriang's
>patch, the code compiles, but doing
>
>nm -p crash.o | c++filt
>
>on Solaris gives
>
>
>0000000000 T foo(T<true, 3>, T<true, 4>)
>0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> 
>func<true, true, 3, 4>(T<true, 3>, T<true, 4>)
>
>rather than
>
>0000000000 T foo(T<true, 3>, T<true, 4>)
>0000000000 T T<true, 6> func<true, true, 3, 4>(T<true, 3>, T<true, 4>)
>
>as I would expect.  It may be that the oddball expression for the return
>type will not affect correctness and will just contribute to bloat instead
>(for the purpose of "linkonce" directives, instantiations that are really
>the same will look different).  But it looks wrong.
>
>Comments?  I may still want this for 3.0.3, because it does make some
>cases that ICE'd before work correctly (in my fixed-point computation
>examples the relevant functions are inline so these oddball symbols
>probably won't even appear).

Re: fix for PR 4447: is this really correct?

[Kriang Lerdsuwanakij]

Hi
I have checked the ABI specifications 
( http://www.codesourcery.com/cxx-abi/abi.html )
before starting on this patch.  And this bloat mangling behavior is what 
the ABI intended.
Following is from the specification with relevant clause capitalized:

   An expression, e.g., "B<(J+1)/2>", is encoded with a prefix traversal of 
the operators
   involved, delimited by "X...E". The operators are encoded using their 
two letter mangled
   names. For example, "B<(J+1)/2>", if J is the third template parameter, 
becomes
   "1BI Xdv pl T1_ Li1E Li2E E E" (the blanks are present only to visualize 
the decomposition).
   Note that the expression is mangled WITHOUT CONSTANT FOLDING OR OTHER
   SIMPLIFICATION, and without parentheses, which are implicit in the 
prefix representation.
   Except for the parentheses, therefore, it represents the source token 
stream. (C++ Standard
   reference 14.5.5.1 p. 5.)

In fact, expressions (involving any operator except type casts) are already 
mangled that way
without my patch.  I can't think of an example that causes ambiguity if 
constant folding is
performed but it looks possible :)

--Kriang

At 11:20 30/11/01 -0800, Joe Buck wrote:
>But I am now not sure that this fix is quite correct, though it does
>improve things.
>
>Here's the testcase:
>----------------------------------------------
>template<bool B,int I>
>class T {
>public:
>     T(int);
>};
>
>template<bool B1,bool B2,int I1,int I2>
>T<(B1&&B2),I1+I2-int(B1&&B2)>
>func(T<B1,I1> a, T<B2,I2> b) {
>     return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2);
>}
>
>void foo(T<true,3> a, T<true,4>b) {
>     func(a, b);
>}
>----------------------------------------------
>
>gcc 3.0 through 3.0.2 get an ICE in the name mangler.  With Kriang's
>patch, the code compiles, but doing
>
>nm -p crash.o | c++filt
>
>on Solaris gives
>
>
>0000000000 T foo(T<true, 3>, T<true, 4>)
>0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> 
>func<true, true, 3, 4>(T<true, 3>, T<true, 4>)
>
>rather than
>
>0000000000 T foo(T<true, 3>, T<true, 4>)
>0000000000 T T<true, 6> func<true, true, 3, 4>(T<true, 3>, T<true, 4>)
>
>as I would expect.  It may be that the oddball expression for the return
>type will not affect correctness and will just contribute to bloat instead
>(for the purpose of "linkonce" directives, instantiations that are really
>the same will look different).  But it looks wrong.
>
>Comments?  I may still want this for 3.0.3, because it does make some
>cases that ICE'd before work correctly (in my fixed-point computation
>examples the relevant functions are inline so these oddball symbols
>probably won't even appear).

Re: fix for PR 4447: is this really correct?

[Joe Buck]

Kriang writes:
> I have checked the ABI specifications 
> (http://www.codesourcery.com/cxx-abi/abi.html)
> before starting on this patch.  And this bloat mangling behavior is what 
> the ABI intended.

OK.  Mark had approved applying this patch to the 3_0_release branch,
so I guess it is the thing to do.  I don't understand why the ABI is
written this way, though.  It seems odd, and since the expression must
be constant, I don't see why it was thought better to leave it unevaluated.

But, are you confident that all operators are now covered, or is it
possible that there's another ICE lurking out there if a user tries a
complicated expression?

Joe

Re: fix for PR 4447: is this really correct?

[Kriang Lerdsuwanakij]

Joe Buck wrote:
> 
> OK.  Mark had approved applying this patch to the 3_0_release branch,
> so I guess it is the thing to do.  I don't understand why the ABI is
> written this way, though.  It seems odd, and since the expression must
> be constant, I don't see why it was thought better to leave it unevaluated.
> 
> But, are you confident that all operators are now covered, or is it
> possible that there's another ICE lurking out there if a user tries a
> complicated expression?
> 
> Joe

The only operator missing is the reinterpret_cast operator.  Handling it
is somewhat messy especially when converting pointers and references - 
like mangling reinterpret_cast'ing pointer should be encoded as casting 
to void *  followed by casting to the desired type (in conformance with 
functional equivalent rule in 14.5.5.1 para 5-8).  

I think it's not so important for 3.0.3.  However, I plan to submit an 
implementation for 3.1.

--Kriang

Re: fix for PR 4447: is this really correct?

[Mark Mitchell]

> I think it's not so important for 3.0.3.  However, I plan to submit an
> implementation for 3.1.

I didn't think reinterpret_cast was legal in a template parameter.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: fix for PR 4447: is this really correct?

[Alexandre Oliva]

On Dec  1, 2001, Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net> wrote:

> I have checked the ABI specifications
> (http://www.codesourcery.com/cxx-abi/abi.html)
> before starting on this patch.  And this bloat mangling behavior is
> what the ABI intended.

Right.  The C++ Standard paragraph referenced in that paragraph of the
ABI requires this behavior in the mangling of overloads of function
templates.  Constant folding is still applied to template arguments
*referenced* within the definition of the template function, before
overload resolution (in case of references to template functions) or
specialization resolution (in case of template classes), and encodings
of such referenced symbols may be constant-folded.  But the template
function names must enable one to tell the sequence of tokens used in
the template function definition, except for template argument names.

> (C++ Standard reference 14.5.5.1 p. 5.)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

fix for PR 4447: is this really correct?

[Joe Buck]

I wrote:

> I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3.
> Actually I don't think any porting is needed, as it's a fix to mangle.c,
> which hasn't had many changes; no, it doesn't change the ABI because
> hitting the relevant code caused a core dump before.
>
> This PR is an ICE and a regression from 2.95.x.

> I believe that the relevant patch is
> 
> 2001-11-17  Kriang Lerdsuwanakij  <lerdsuwa@users.sourceforge.net>
> 
> 	* mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR,
> 	CONST_CAST_EXPR.
> 	* operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR.

Mark approved, assuming the usual testing requirements are met.

I've now verified that this fix doesn't break any C++ or libstdc++ tests
(other tests aren't relevant since this only affects cc1plus).

But I am now not sure that this fix is quite correct, though it does
improve things.

Here's the testcase:
----------------------------------------------
template<bool B,int I>
class T {
public:
    T(int);
};

template<bool B1,bool B2,int I1,int I2>
T<(B1&&B2),I1+I2-int(B1&&B2)> 
func(T<B1,I1> a, T<B2,I2> b) {
    return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2);
}

void foo(T<true,3> a, T<true,4>b) {
    func(a, b);
}
----------------------------------------------

gcc 3.0 through 3.0.2 get an ICE in the name mangler.  With Kriang's
patch, the code compiles, but doing

nm -p crash.o | c++filt

on Solaris gives


0000000000 T foo(T<true, 3>, T<true, 4>)
0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> func<true, true, 3, 4>(T<true, 3>, T<true, 4>)

rather than

0000000000 T foo(T<true, 3>, T<true, 4>)
0000000000 T T<true, 6> func<true, true, 3, 4>(T<true, 3>, T<true, 4>)

as I would expect.  It may be that the oddball expression for the return
type will not affect correctness and will just contribute to bloat instead
(for the purpose of "linkonce" directives, instantiations that are really
the same will look different).  But it looks wrong.

Comments?  I may still want this for 3.0.3, because it does make some
cases that ICE'd before work correctly (in my fixed-point computation
examples the relevant functions are inline so these oddball symbols
probably won't even appear).

Re: GCC 3.0.3

[Joe Buck]

> Please remember that Dec 1. is the freeze date for changes going into
> GCC 3.0.3.  Non-documentation changes will require my approval after
> that point.
> 
> I have received some important bug reports from people.  I will be
> posting a list of those shortly.  We will try to fix these before the
> release if possible.

I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3.
Actually I don't think any porting is needed, as it's a fix to mangle.c,
which hasn't had many changes; no, it doesn't change the ABI because
hitting the relevant code caused a core dump before.

This PR is an ICE and a regression from 2.95.x.

I believe that the relevant patch is

2001-11-17  Kriang Lerdsuwanakij  <lerdsuwa@users.sourceforge.net>

	* mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR,
	CONST_CAST_EXPR.
	* operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR.

Re: GCC 3.0.3

[Stephane Carrez]

Hi Mark and Jakub,

Can we backport the following patch on 3.0 branch:

http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00591.html

2001-11-09  Jakub Jelinek  <jakub@redhat.com>

        * config/sparc/sparc.md (movdf): Avoid calling validize_mem during
        or after reload.


It fixes PR/4410 (verified on 3.0.2/Solaris 8).
It is a regression from 2.95.3.

Thanks,
	Stephane

(cut&paste from web below)

--- gcc/config/sparc/sparc.md.jj        Wed Oct 24 21:25:07 2001
+++ gcc/config/sparc/sparc.md   Fri Nov  9 15:28:04 2001
@@ -3255,6 +3255,11 @@
          && fp_zero_operand (operands[1], DFmode))
        goto movdf_is_ok;
 
+      /* We are able to build any DF constant in integer registers.  */
+      if (REGNO (operands[0]) < 32
+         && (reload_completed || reload_in_progress))
+       goto movdf_is_ok;
+
       operands[1] = validize_mem (force_const_mem (GET_MODE (operands[0]),
                                                    operands[1]));
     }

Re: GCC 3.0.3

[Jakub Jelinek]

On Fri, Nov 30, 2001 at 08:26:58PM +0100, Stephane Carrez wrote:
> Can we backport the following patch on 3.0 branch:
> 
> http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00591.html
> 
> 2001-11-09  Jakub Jelinek  <jakub@redhat.com>
> 
>         * config/sparc/sparc.md (movdf): Avoid calling validize_mem during
>         or after reload.
> 
> 
> It fixes PR/4410 (verified on 3.0.2/Solaris 8).
> It is a regression from 2.95.3.

Installed on branch (including corresponding testcase).

	Jakub

Re: GCC 3.0.3

[Jakub Jelinek]

On Fri, Nov 30, 2001 at 08:26:58PM +0100, Stephane Carrez wrote:
> Can we backport the following patch on 3.0 branch:
> 
> http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00591.html
> 
> 2001-11-09  Jakub Jelinek  <jakub@redhat.com>
> 
>         * config/sparc/sparc.md (movdf): Avoid calling validize_mem during
>         or after reload.
> 
> 
> It fixes PR/4410 (verified on 3.0.2/Solaris 8).
> It is a regression from 2.95.3.

Installed on branch (including corresponding testcase).

	Jakub

Re: GCC 3.0.3

[Stephane Carrez]

Hi Mark and Jakub,

Can we backport the following patch on 3.0 branch:

http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00591.html

2001-11-09  Jakub Jelinek  <jakub@redhat.com>

        * config/sparc/sparc.md (movdf): Avoid calling validize_mem during
        or after reload.


It fixes PR/4410 (verified on 3.0.2/Solaris 8).
It is a regression from 2.95.3.

Thanks,
	Stephane

(cut&paste from web below)

--- gcc/config/sparc/sparc.md.jj        Wed Oct 24 21:25:07 2001
+++ gcc/config/sparc/sparc.md   Fri Nov  9 15:28:04 2001
@@ -3255,6 +3255,11 @@
          && fp_zero_operand (operands[1], DFmode))
        goto movdf_is_ok;
 
+      /* We are able to build any DF constant in integer registers.  */
+      if (REGNO (operands[0]) < 32
+         && (reload_completed || reload_in_progress))
+       goto movdf_is_ok;
+
       operands[1] = validize_mem (force_const_mem (GET_MODE (operands[0]),
                                                    operands[1]));
     }

Re: GCC 3.0.3

[Mark Mitchell]

--On Friday, November 30, 2001 08:26:58 PM +0100 Stephane Carrez 
<Stephane.Carrez@worldnet.fr> wrote:

> Hi Mark and Jakub,
>
> Can we backport the following patch on 3.0 branch:
>
> http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00591.html

Yes, thanks.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.0.3

[Toon Moene]

Mark Mitchell wrote:

> Please remember that Dec 1. is the freeze date for changes going into
> GCC 3.0.3.  Non-documentation changes will require my approval after
> that point.
> 
> I have received some important bug reports from people.  I will be
> posting a list of those shortly.  We will try to fix these before the
> release if possible.

I definitely want to fix fortran/4885.  It's a regression from gcc-2.95
(actually a libf2c problem that's probably introduced by the ftruncate
change requested by the GAMESS developers).

I work on it tomorrow (1st of Dec.).

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: GCC 3.0.3

[Toon Moene]

Mark Mitchell wrote:

> Please remember that Dec 1. is the freeze date for changes going into
> GCC 3.0.3.  Non-documentation changes will require my approval after
> that point.
> 
> I have received some important bug reports from people.  I will be
> posting a list of those shortly.  We will try to fix these before the
> release if possible.

I definitely want to fix fortran/4885.  It's a regression from gcc-2.95
(actually a libf2c problem that's probably introduced by the ftruncate
change requested by the GAMESS developers).

I work on it tomorrow (1st of Dec.).

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

GCC 3.0.3

[Mark Mitchell]

Please remember that Dec 1. is the freeze date for changes going into
GCC 3.0.3.  Non-documentation changes will require my approval after
that point.

I have received some important bug reports from people.  I will be
posting a list of those shortly.  We will try to fix these before the
release if possible.

Thank you,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com