GCC 3.1 prerelease

GCC 3.1 prerelease

[Mark Mitchell]

The GCC 3.1 prerelease is on gcc.gnu.org and its mirrors in the snapshots
directory.  Look for files with 20020423 in their names.

Please download the prerelease tarballs and try to build and install them.

When the next batch of critical bugs gets fixed, I will spin another
prerelease.

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

Re: GCC 3.1 prerelease

[Kurt Wall]

Scribbling feverishly on April 23, Mark Mitchell managed to emit:
> The GCC 3.1 prerelease is on gcc.gnu.org and its mirrors in the snapshots
> directory.  Look for files with 20020423 in their names.
> 
> Please download the prerelease tarballs and try to build and install them.
> 
> When the next batch of critical bugs gets fixed, I will spin another
> prerelease.

Is it a matter of policy not to generate MD5 sums for the bz2
archives? If so, I'll grab the gzip archives instead. I feel more
comfortable being able to verify the checksums...

Thanks,

Kurt
-- 
Senate, n.:
	A body of elderly gentlemen charged with high duties and
misdemeanors.
		-- Ambrose Bierce

Re: GCC 3.1 prerelease

[Phil Edwards]

On Tue, Apr 23, 2002 at 09:20:14PM -0400, Kurt Wall wrote:
> Scribbling feverishly on April 23, Mark Mitchell managed to emit:
> > The GCC 3.1 prerelease is on gcc.gnu.org and its mirrors in the snapshots
> > directory.  Look for files with 20020423 in their names.
> 
> Is it a matter of policy not to generate MD5 sums for the bz2
> archives? If so, I'll grab the gzip archives instead. I feel more
> comfortable being able to verify the checksums...

No, we generate MD5 sums for everything, but not at the same time we
upload the files.  In fact, if memory serves, it happens overnight, so
the checksums should be updated w/n 24 hours.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC 3.1 prerelease

[Mark Mitchell]

No, it's a matter of the release script not generating either.  Probably
the md5 checksums lying around with the gzips are out of date.

I'll try to add this to the release script.

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

Re: GCC 3.1 prerelease

[Joseph S. Myers]

On Wed, 24 Apr 2002, Mark Mitchell wrote:

> No, it's a matter of the release script not generating either.  Probably
> the md5 checksums lying around with the gzips are out of date.
> 
> I'll try to add this to the release script.

The MD5 sums are I think generated by some process that runs on
gcc.gnu.org and generates them for new FTP files.  I don't know the
details - this isn't documented at
<URL:http://sources.redhat.com/sourceware/ftp.html>.

It would be better for actual releases to be cryptographically signed.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.1 prerelease

[Kurt Wall]

[CCs trimmed]

Scribbling feverishly on April 24, Joseph S. Myers managed to emit:
> On Wed, 24 Apr 2002, Mark Mitchell wrote:
> 
> > No, it's a matter of the release script not generating either.  Probably
> > the md5 checksums lying around with the gzips are out of date.
> > 
> > I'll try to add this to the release script.
> 
> The MD5 sums are I think generated by some process that runs on
> gcc.gnu.org and generates them for new FTP files.  I don't know the
> details - this isn't documented at
> <URL:http://sources.redhat.com/sourceware/ftp.html>.

Ah. Revaming the autogeneration of md5 sums apparently a
long-standing TODO item:
http://sources.redhat.com/sourceware/TODO.txt
 
> It would be better for actual releases to be cryptographically signed.

Agreed, although I realize my opinion carries little weight here.

Kurt
-- 
I'm defending her honor, which is more than she ever did.

Re: GCC 3.1 Prerelease

[Tom Tromey]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

Mark> From this point hence, please do not make any further
Mark> non-documentation check-ins to the GCC 3.1 branch without my
Mark> explicit approval.

Please approve these:

http://gcc.gnu.org/ml/java-patches/2002-q2/msg00209.html

  Fixes a bug in the new resource compilation feature.
  Without this patch this feature simply doesn't work.

http://gcc.gnu.org/ml/java-patches/2002-q2/msg00208.html

  Changes -P to --resource.  PR 6314.

Tom

Re: GCC 3.1 Prerelease

[Paolo Carlini]

Gerald Pfeifer wrote:
> As promised, I performed tests comparing GCC 2.95.3, GCC 3.0, GCC 3.0.3,
> the 3.1-branch as of yesterday, the 3.1-branch with -finline-limit=800
> and 1200, respectively, and the 3.2-branch as of yesterday.

Hi,

even if it's not immediately useful in order to deal with the performance problems of 3.1-branch, I think it would be interesting to see what the 3.2-branch numbers would become with the following patch reverted:

	http://gcc.gnu.org/ml/gcc/2002-03/msg00216.html

Any chance you can do that?

(I would guess that the improvement on 3.1 comes from the better alias analysis)

Ciao,
Paolo.

GCC 3.1 Prerelease

[Mark Mitchell]

I'm now spinning the prerelease.  Assuming it works, the tarballs will
be on the FTP server by the type I wake up tomorrow morning...

From this point hence, please do not make any further non-documentation
check-ins to the GCC 3.1 branch without my explicit approval.

There are a handful of open bugs remaining that need fixes.  By far and
away the most worrisome are the IRIX regressions in PR 6212 and PR 6304.
These are significant problems (crashes in the generated code).  The
first allegedly stems from a patch by Kenner -- although one problematic
part of that patch has already been reverted.  The second problem allegedly
stems from a patch by Jan.  Gentlemen, your help in tracking down these
problems would be very much appreciated.

I unfortunately at temporarily without access to my IRIX development
platform; my access to ASCI bluemountain should be back soon, but I
don't have it now.  So, we're going to need someone else to look at
these if possible.

Joseph, if you have time to look at PR 6343 (C front end regression
involving "attribute((weak))"), please do so.  I can imagine this
being a significant problem.

Thanks,

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

Re: GCC 3.1 Prerelease

[Alan Modra]

On Tue, Apr 23, 2002 at 02:01:25AM -0700, Mark Mitchell wrote:
> 
> Joseph, if you have time to look at PR 6343 (C front end regression
> involving "attribute((weak))"), please do so.  I can imagine this
> being a significant problem.

I've been using this, which at least cures the problem with
__register_frame_info*.  Credit for the patch goes to Franz Sirl.

diff -urpN -xCVS -x'*~' -xTAGS gcc-31.orig/gcc/c-decl.c gcc-31/gcc/c-decl.c
--- gcc-31.orig/gcc/c-decl.c	2002-04-03 09:00:04.000000000 +0930
+++ gcc-31/gcc/c-decl.c	2002-04-23 18:06:31.000000000 +0930
@@ -1955,7 +1955,16 @@ duplicate_decls (newdecl, olddecl, diffe
     }
 
   /* Merge the storage class information.  */
-  DECL_WEAK (newdecl) |= DECL_WEAK (olddecl);
+  if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl))
+    declare_weak (olddecl);
+  if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl))
+    declare_weak (newdecl);
+  if (DECL_WEAK (newdecl) && DECL_RTL (newdecl)
+      && GET_CODE (DECL_RTL (newdecl)) == MEM
+      && XEXP (DECL_RTL (newdecl), 0)
+      && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF)
+    SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1;
+
   /* For functions, static overrides non-static.  */
   if (TREE_CODE (newdecl) == FUNCTION_DECL)
     {
diff -urpN -xCVS -x'*~' -xTAGS gcc-31.orig/gcc/cp/decl.c gcc-31/gcc/cp/decl.c
--- gcc-31.orig/gcc/cp/decl.c	2002-04-17 18:56:57.000000000 +0930
+++ gcc-31/gcc/cp/decl.c	2002-04-23 18:06:31.000000000 +0930
@@ -3645,7 +3645,15 @@ duplicate_decls (newdecl, olddecl)
     }
 
   /* Merge the storage class information.  */
-  DECL_WEAK (newdecl) |= DECL_WEAK (olddecl);
+  if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl))
+    declare_weak (olddecl);
+  if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl))
+    declare_weak (newdecl);
+  if (DECL_WEAK (newdecl) && DECL_RTL (newdecl)
+      && GET_CODE (DECL_RTL (newdecl)) == MEM
+      && XEXP (DECL_RTL (newdecl), 0)
+      && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF)
+    SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1;
   DECL_ONE_ONLY (newdecl) |= DECL_ONE_ONLY (olddecl);
   DECL_DEFER_OUTPUT (newdecl) |= DECL_DEFER_OUTPUT (olddecl);
   TREE_PUBLIC (newdecl) = TREE_PUBLIC (olddecl);


-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: GCC 3.1 Prerelease

[Franz Sirl]

At 12:28 23.04.2002, Alan Modra wrote:
>On Tue, Apr 23, 2002 at 02:01:25AM -0700, Mark Mitchell wrote:
> >
> > Joseph, if you have time to look at PR 6343 (C front end regression
> > involving "attribute((weak))"), please do so.  I can imagine this
> > being a significant problem.
>
>I've been using this, which at least cures the problem with
>__register_frame_info*.  Credit for the patch goes to Franz Sirl.

Hmm, have you tried recompiling glibc with this patch? I seem to recall 
glibc using constructs that would produce an error now.

Anyway, I'll look into that stuff again later today.

Franz.



>diff -urpN -xCVS -x'*~' -xTAGS gcc-31.orig/gcc/c-decl.c gcc-31/gcc/c-decl.c
>--- gcc-31.orig/gcc/c-decl.c    2002-04-03 09:00:04.000000000 +0930
>+++ gcc-31/gcc/c-decl.c 2002-04-23 18:06:31.000000000 +0930
>@@ -1955,7 +1955,16 @@ duplicate_decls (newdecl, olddecl, diffe
>      }
>
>    /* Merge the storage class information.  */
>-  DECL_WEAK (newdecl) |= DECL_WEAK (olddecl);
>+  if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl))
>+    declare_weak (olddecl);
>+  if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl))
>+    declare_weak (newdecl);
>+  if (DECL_WEAK (newdecl) && DECL_RTL (newdecl)
>+      && GET_CODE (DECL_RTL (newdecl)) == MEM
>+      && XEXP (DECL_RTL (newdecl), 0)
>+      && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF)
>+    SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1;
>+
>    /* For functions, static overrides non-static.  */
>    if (TREE_CODE (newdecl) == FUNCTION_DECL)
>      {
>diff -urpN -xCVS -x'*~' -xTAGS gcc-31.orig/gcc/cp/decl.c gcc-31/gcc/cp/decl.c
>--- gcc-31.orig/gcc/cp/decl.c   2002-04-17 18:56:57.000000000 +0930
>+++ gcc-31/gcc/cp/decl.c        2002-04-23 18:06:31.000000000 +0930
>@@ -3645,7 +3645,15 @@ duplicate_decls (newdecl, olddecl)
>      }
>
>    /* Merge the storage class information.  */
>-  DECL_WEAK (newdecl) |= DECL_WEAK (olddecl);
>+  if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl))
>+    declare_weak (olddecl);
>+  if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl))
>+    declare_weak (newdecl);
>+  if (DECL_WEAK (newdecl) && DECL_RTL (newdecl)
>+      && GET_CODE (DECL_RTL (newdecl)) == MEM
>+      && XEXP (DECL_RTL (newdecl), 0)
>+      && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF)
>+    SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1;
>    DECL_ONE_ONLY (newdecl) |= DECL_ONE_ONLY (olddecl);
>    DECL_DEFER_OUTPUT (newdecl) |= DECL_DEFER_OUTPUT (olddecl);
>    TREE_PUBLIC (newdecl) = TREE_PUBLIC (olddecl);
>
>
>--
>Alan Modra
>IBM OzLabs - Linux Technology Centre

Re: GCC 3.1 Prerelease

[Alan Modra]

On Tue, Apr 23, 2002 at 01:04:39PM +0200, Franz Sirl wrote:
> At 12:28 23.04.2002, Alan Modra wrote:
> >On Tue, Apr 23, 2002 at 02:01:25AM -0700, Mark Mitchell wrote:
> >>
> >> Joseph, if you have time to look at PR 6343 (C front end regression
> >> involving "attribute((weak))"), please do so.  I can imagine this
> >> being a significant problem.
> >
> >I've been using this, which at least cures the problem with
> >__register_frame_info*.  Credit for the patch goes to Franz Sirl.
> 
> Hmm, have you tried recompiling glibc with this patch? I seem to recall 
> glibc using constructs that would produce an error now.

I've been compiling a glibc snapshot with a last ChangeLog entry of
2002-01-18  Andreas Schwab  <schwab@suse.de>

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: GCC 3.1 Prerelease

[Franz Sirl]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

At 13:13 23.04.2002, Alan Modra wrote:
>On Tue, Apr 23, 2002 at 01:04:39PM +0200, Franz Sirl wrote:
> > At 12:28 23.04.2002, Alan Modra wrote:
> > >On Tue, Apr 23, 2002 at 02:01:25AM -0700, Mark Mitchell wrote:
> > >>
> > >> Joseph, if you have time to look at PR 6343 (C front end regression
> > >> involving "attribute((weak))"), please do so.  I can imagine this
> > >> being a significant problem.
> > >
> > >I've been using this, which at least cures the problem with
> > >__register_frame_info*.  Credit for the patch goes to Franz Sirl.
> >
> > Hmm, have you tried recompiling glibc with this patch? I seem to recall
> > glibc using constructs that would produce an error now.
>
>I've been compiling a glibc snapshot with a last ChangeLog entry of
>2002-01-18  Andreas Schwab  <schwab@suse.de>

OK, try compiling glibc with the attached patch, it should give you some 
warnings :-).

What do you all think about this patch? It covers all the cases I could 
think of, but maybe I missed something. Please take a close look at my 
changes to declare_weak, I'm not too sure my DECL checking is 100% 
correct/allowed. Can someone think of a better warning message? And what 
about a merge_weak() function (naming? in which file?) instead of 
duplicating the code?

The testcases are planned for the dg framework, but I haven't added all the 
dg funkiness yet :-).

Franz.


[-- Attachment #2: gcc-weaksym-4.patch --]
[-- Type: application/octet-stream, Size: 3000 bytes --]

Index: gcc/c-decl.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/c-decl.c,v
retrieving revision 1.300.2.5
diff -u -p -r1.300.2.5 c-decl.c
--- gcc/c-decl.c	28 Mar 2002 18:49:57 -0000	1.300.2.5
+++ gcc/c-decl.c	23 Apr 2002 16:51:11 -0000
@@ -1955,7 +1955,16 @@ duplicate_decls (newdecl, olddecl, diffe
     }
 
   /* Merge the storage class information.  */
-  DECL_WEAK (newdecl) |= DECL_WEAK (olddecl);
+  if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl))
+    declare_weak (olddecl);
+  if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl))
+    declare_weak (newdecl);
+  if (DECL_WEAK (newdecl) && DECL_RTL (newdecl)
+      && GET_CODE (DECL_RTL (newdecl)) == MEM
+      && XEXP (DECL_RTL (newdecl), 0)
+      && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF)
+    SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1;
+
   /* For functions, static overrides non-static.  */
   if (TREE_CODE (newdecl) == FUNCTION_DECL)
     {
Index: gcc/varasm.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/varasm.c,v
retrieving revision 1.250.2.7
diff -u -p -r1.250.2.7 varasm.c
--- gcc/varasm.c	25 Mar 2002 00:54:26 -0000	1.250.2.7
+++ gcc/varasm.c	23 Apr 2002 16:51:11 -0000
@@ -4998,12 +4998,14 @@ declare_weak (decl)
 {
   if (! TREE_PUBLIC (decl))
     error_with_decl (decl, "weak declaration of `%s' must be public");
-  else if (TREE_ASM_WRITTEN (decl))
+  else if (TREE_CODE (decl) == FUNCTION_DECL && TREE_ASM_WRITTEN (decl))
     error_with_decl (decl, "weak declaration of `%s' must precede definition");
   else if (SUPPORTS_WEAK)
     {
       if (! DECL_WEAK (decl))
 	weak_decls = tree_cons (NULL, decl, weak_decls);
+      if (TREE_USED (decl))
+	warning_with_decl (decl, "weak declaration of `%s' after first use may result in unspecified behaviour");
     }
   else
     warning_with_decl (decl, "weak declaration of `%s' not supported");
Index: gcc/cp/decl.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/cp/decl.c,v
retrieving revision 1.866.2.23
diff -u -p -r1.866.2.23 decl.c
--- gcc/cp/decl.c	16 Apr 2002 03:15:54 -0000	1.866.2.23
+++ gcc/cp/decl.c	23 Apr 2002 16:51:12 -0000
@@ -3645,7 +3645,16 @@ duplicate_decls (newdecl, olddecl)
     }
 
   /* Merge the storage class information.  */
-  DECL_WEAK (newdecl) |= DECL_WEAK (olddecl);
+  if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl))
+    declare_weak (olddecl);
+  if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl))
+    declare_weak (newdecl);
+  if (DECL_WEAK (newdecl) && DECL_RTL (newdecl)
+      && GET_CODE (DECL_RTL (newdecl)) == MEM
+      && XEXP (DECL_RTL (newdecl), 0)
+      && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF)
+    SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1;
+
   DECL_ONE_ONLY (newdecl) |= DECL_ONE_ONLY (olddecl);
   DECL_DEFER_OUTPUT (newdecl) |= DECL_DEFER_OUTPUT (olddecl);
   TREE_PUBLIC (newdecl) = TREE_PUBLIC (olddecl);

[-- Attachment #3: weak-2.c --]
[-- Type: text/plain, Size: 2508 bytes --]


// test function addresses with __attribute__((weak))
extern void * ffoo1a (void) __attribute__((weak));
extern void * ffoo1a (void);
void * foo1a (void)
{
  return (void *)ffoo1a;
}

extern void * ffoo2a (void);
extern void * ffoo2a (void) __attribute__((weak));
void * foo2a (void)
{
  return (void *)ffoo2a;
}

extern void * ffoo3a (void);
void * foo3a (void)
{
  return (void *)ffoo3a;
}
extern void * ffoo3a (void) __attribute__((weak));



// test function addresses with #pragma weak
#pragma weak ffoo1b
extern void * ffoo1b (void);
void * foo1b (void)
{
  return (void *)ffoo1b;
}

extern void * ffoo2b (void);
#pragma weak ffoo2b
void * foo2b (void)
{
  return (void *)ffoo2b;
}

extern void * ffoo3b (void);
void * foo3b (void)
{
  return (void *)ffoo3b;
}
#pragma weak ffoo3b




// test variable addresses with __attribute__((weak))
extern int vfoo1c __attribute__((weak));
extern int vfoo1c;
void * foo1c (void)
{
  return (void *)&vfoo1c;
}

extern int vfoo2c;
extern int vfoo2c __attribute__((weak));
void * foo2c (void)
{
  return (void *)&vfoo2c;
}

extern int vfoo3c;
void * foo3c (void)
{
  return (void *)&vfoo3c;
}
extern int vfoo3c __attribute__((weak));

extern int vfoo4c __attribute__((weak));
int vfoo4c;
void * foo4c (void)
{
  return (void *)&vfoo4c;
}

int vfoo5c;
extern int vfoo5c __attribute__((weak));
void * foo5c (void)
{
  return (void *)&vfoo5c;
}

int vfoo6c;
void * foo6c (void)
{
  return (void *)&vfoo6c;
}
extern int vfoo6c __attribute__((weak));

extern int vfoo7c;
void * foo7c (void)
{
  return (void *)&vfoo7c;
}
int vfoo7c __attribute__((weak));

extern int vfoo8c __attribute__((weak));
void * foo8c (void)
{
  return (void *)&vfoo8c;
}
extern int vfoo8c __attribute__((weak));
int vfoo8c;


// test variable addresses with #pragma weak
#pragma weak vfoo1d
extern int vfoo1d;
void * foo1d (void)
{
  return (void *)&vfoo1d;
}

extern int vfoo2d;
#pragma weak vfoo2d
void * foo2d (void)
{
  return (void *)&vfoo2d;
}

extern int vfoo3d;
void * foo3d (void)
{
  return (void *)&vfoo3d;
}
#pragma weak vfoo3d

#pragma weak vfoo4d
int vfoo4d;
void * foo4d (void)
{
  return (void *)&vfoo4d;
}

int vfoo5d;
#pragma weak vfoo5d
void * foo5d (void)
{
  return (void *)&vfoo5d;
}

int vfoo6d;
void * foo6d (void)
{
  return (void *)&vfoo6d;
}
#pragma weak vfoo6d

extern int vfoo7d;
void * foo7d (void)
{
  return (void *)&vfoo7d;
}
#pragma weak vfoo7d
int vfoo7d;

extern int vfoo8d;
void * foo8d (void)
{
  return (void *)&vfoo8d;
}
int vfoo8d;
#pragma weak vfoo8d

[-- Attachment #4: weak-3.c --]
[-- Type: text/plain, Size: 120 bytes --]



extern void * foo (void);
void * foo (void)
{
  return (void *)foo;
}
extern void * foo (void) __attribute__((weak));

[-- Attachment #5: weak-4.c --]
[-- Type: text/plain, Size: 89 bytes --]



extern void * foo (void);
void * foo (void)
{
  return (void *)foo;
}
#pragma weak foo

Re: GCC 3.1 Prerelease

[Richard Henderson]

On Tue, Apr 23, 2002 at 07:28:22PM +0200, Franz Sirl wrote:
> What do you all think about this patch? It covers all the cases I could 
> think of, but maybe I missed something.

I don't see why functions should be singled out in having to have
the weakening before the definition.

Otherwise it looks ok.


r~

Re: GCC 3.1 Prerelease

[Franz Sirl]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

On Tuesday 23 April 2002 20:04, Richard Henderson wrote:
> On Tue, Apr 23, 2002 at 07:28:22PM +0200, Franz Sirl wrote:
> > What do you all think about this patch? It covers all the cases I could
> > think of, but maybe I missed something.
>
> I don't see why functions should be singled out in having to have
> the weakening before the definition.

Hmm, I didn't want to get too aggressive in here (declare_weak wasn't called 
for VAR_DECLs before) and judging from the comments in tree.h it looks like 
TREE_ASM_WRITTEN has a slightly different meaning for a VAR_DECL. But if you 
think it's OK, I'll happily change it.

Looking at the warnings in glibc it turned out I was already too aggressive, 
the patch would warn for:

extern double strtod (__const char *__restrict __nptr,
                      char **__restrict __endptr);

extern double __strtod_internal (__const char *__restrict __nptr,
                                 char **__restrict __endptr, int __group);

extern __inline double
  strtod (__const char *__restrict __nptr, char **__restrict __endptr)
{
  return __strtod_internal (__nptr, __endptr, 0);
}

extern __inline double
  atof (__const char *__nptr)
{
    return strtod (__nptr, (char **) ((void *)0));
}

double __attribute__ ((weak))
  strtod (nptr, endptr)
    const char *nptr;
    char **endptr;
{
  return __strtod_internal (nptr, endptr, 0 );
}

I don't think we want a warning here for strtod?

Appended an updated patch with Jason's suggestions integrated as well. I'll 
run a few more tests tomorrow.

Franz.


[-- Attachment #2: gcc-weaksym-5.patch --]
[-- Type: text/plain, Size: 2826 bytes --]

Index: gcc/c-decl.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/c-decl.c,v
retrieving revision 1.300.2.5
diff -u -p -r1.300.2.5 c-decl.c
--- gcc/c-decl.c	28 Mar 2002 18:49:57 -0000	1.300.2.5
+++ gcc/c-decl.c	23 Apr 2002 21:41:28 -0000
@@ -1955,7 +1955,11 @@ duplicate_decls (newdecl, olddecl, diffe
     }
 
   /* Merge the storage class information.  */
-  DECL_WEAK (newdecl) |= DECL_WEAK (olddecl);
+  if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl))
+    declare_weak (olddecl);
+  if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl))
+    declare_weak (newdecl);
+
   /* For functions, static overrides non-static.  */
   if (TREE_CODE (newdecl) == FUNCTION_DECL)
     {
Index: gcc/varasm.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/varasm.c,v
retrieving revision 1.250.2.7
diff -u -p -r1.250.2.7 varasm.c
--- gcc/varasm.c	25 Mar 2002 00:54:26 -0000	1.250.2.7
+++ gcc/varasm.c	23 Apr 2002 21:41:28 -0000
@@ -4998,17 +4998,25 @@ declare_weak (decl)
 {
   if (! TREE_PUBLIC (decl))
     error_with_decl (decl, "weak declaration of `%s' must be public");
-  else if (TREE_ASM_WRITTEN (decl))
+  else if (TREE_CODE (decl) == FUNCTION_DECL && TREE_ASM_WRITTEN (decl))
     error_with_decl (decl, "weak declaration of `%s' must precede definition");
   else if (SUPPORTS_WEAK)
     {
       if (! DECL_WEAK (decl))
 	weak_decls = tree_cons (NULL, decl, weak_decls);
+      if (TREE_CODE (decl) != FUNCTION_DECL && TREE_USED (decl))
+	warning_with_decl (decl, "weak declaration of `%s' after first use may result in unspecified behaviour");
     }
   else
     warning_with_decl (decl, "weak declaration of `%s' not supported");
 
   DECL_WEAK (decl) = 1;
+
+  if (DECL_RTL_SET_P (decl)
+      && GET_CODE (DECL_RTL (decl)) == MEM
+      && XEXP (DECL_RTL (decl), 0)
+      && GET_CODE (XEXP (DECL_RTL (decl), 0)) == SYMBOL_REF)
+    SYMBOL_REF_WEAK (XEXP (DECL_RTL (decl), 0)) = 1;
 }
 
 /* Emit any pending weak declarations.  */
Index: gcc/cp/decl.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/cp/decl.c,v
retrieving revision 1.866.2.23
diff -u -p -r1.866.2.23 decl.c
--- gcc/cp/decl.c	16 Apr 2002 03:15:54 -0000	1.866.2.23
+++ gcc/cp/decl.c	23 Apr 2002 21:41:28 -0000
@@ -3645,7 +3645,11 @@ duplicate_decls (newdecl, olddecl)
     }
 
   /* Merge the storage class information.  */
-  DECL_WEAK (newdecl) |= DECL_WEAK (olddecl);
+  if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl))
+    declare_weak (olddecl);
+  if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl))
+    declare_weak (newdecl);
+
   DECL_ONE_ONLY (newdecl) |= DECL_ONE_ONLY (olddecl);
   DECL_DEFER_OUTPUT (newdecl) |= DECL_DEFER_OUTPUT (olddecl);
   TREE_PUBLIC (newdecl) = TREE_PUBLIC (olddecl);

Re: GCC 3.1 Prerelease

[Richard Henderson]

On Wed, Apr 24, 2002 at 12:03:42AM +0200, Franz Sirl wrote:
> (declare_weak wasn't called for VAR_DECLs before)

Huh?  It must have been.

> ... and judging from the comments in tree.h it looks like 
> TREE_ASM_WRITTEN has a slightly different meaning for a VAR_DECL.

What makes you think that?

> I don't think we want a warning here for strtod?

I can make an argument either way.  I'm inclined to warn, since
older gcc would in fact render this into rtl right away, which 
has then already made decisions based on DECL_WEAK.


r~

Re: GCC 3.1 Prerelease

[Jason Merrill]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

While I was looking at this bug earlier (before I saw that you were working
on it), I made this change.  Checking TREE_SYMBOL_REFERENCED makes more
sense than TREE_USED anyway, since it's the symbol we care about.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 652 bytes --]

*** varasm.c.~1~	Wed Apr 24 01:04:56 2002
--- varasm.c	Tue Apr 23 15:43:46 2002
*************** weak_finish ()
*** 5022,5028 ****
        tree decl = TREE_VALUE (t);
        const char *name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl));
  
!       if (! TREE_USED (decl))
  	continue;
  
  #ifdef ASM_WEAKEN_DECL
--- 5022,5030 ----
        tree decl = TREE_VALUE (t);
        const char *name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl));
  
!       /* We can't rely on TREE_USED here, as decl might be a discarded
! 	 duplicate.  */
!       if (! TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl)))
  	continue;
  
  #ifdef ASM_WEAKEN_DECL

Re: GCC 3.1 Prerelease

[Franz Sirl]

On Wednesday 24 April 2002 19:31, Jason Merrill wrote:
> While I was looking at this bug earlier (before I saw that you were working
> on it), I made this change.  Checking TREE_SYMBOL_REFERENCED makes more
> sense than TREE_USED anyway, since it's the symbol we care about.

Hmm, it seems to make more sense for the warning check too, with TREE_USED 
changed to TREE_SYMBOL_REFERENCED the c++ regression 
g++.old-deja/g++.jason/template39.C went away along with a bunch of 
regressions in the libstdc++ testsuite, except one:

FAIL: 26_numerics/complex_inserters_extractors.cc (test for excess errors)
Excess errors:
/home/fsirl/TC/gcc/BUILD/obj-gcc31-ppc/ppc-linux/libstdc++-v3/include/bits/basic_string.h: 
In instantiation of `const size_t std::basic_string<char, gnu_cha
r_traits, std::allocator<char> >::npos':
/home/fsirl/TC/gcc/BUILD/gcc-3.1/libstdc++-v3/testsuite/26_numerics/complex_inserters_extractors.cc:109:   
instantiated from here
/home/fsirl/TC/gcc/BUILD/obj-gcc31-ppc/ppc-linux/libstdc++-v3/include/bits/basic_string.h:217: 
warning: weak declaration of `const size_t std::basic_string<
char, gnu_char_traits, std::allocator<char> >::npos' after first use may 
result in unspecified behaviour

Can a c++ expert tell me if this warning makes sense in this testcase or does 
the warning check need still more refinement?

Hmm, Jason, I'm just noticing the purpose of the test in weak_finish. This 
seems to be a behaviour change compared to earlier gcc releases. A simple 
file like that:

#pragma weak foo1
extern int foo2 __attribute__((weak));

will now result in this assembly file:

        .file   "weak-pragma.c"
        .ident  "GCC: (GNU) 3.1 20020423 (prerelease)"

But upto 3.0.x we got:

        .file   "weak-pragma.c"
        .weak   foo2
        .weak   foo1
        .ident  "GCC: (GNU) 3.0.3 20011213 (prerelease)"

Are we sure there is no code out there relying on these lonely .weak 
statements? Was this change intended?

Franz.

Re: GCC 3.1 Prerelease

[Richard Henderson]

On Wed, Apr 24, 2002 at 09:01:39PM +0200, Franz Sirl wrote:
> Are we sure there is no code out there relying on these lonely .weak 
> statements? Was this change intended?

Yes and yes.


r~

Re: GCC 3.1 Prerelease

[Jason Merrill]

>>>>> "Franz" == Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

> Hmm, it seems to make more sense for the warning check too, with TREE_USED 
> changed to TREE_SYMBOL_REFERENCED the c++ regression 
> g++.old-deja/g++.jason/template39.C went away along with a bunch of 
> regressions in the libstdc++ testsuite, except one:

> FAIL: 26_numerics/complex_inserters_extractors.cc (test for excess errors)
> Excess errors:
> /home/fsirl/TC/gcc/BUILD/obj-gcc31-ppc/ppc-linux/libstdc++-v3/include/bits/basic_string.h: 
> In instantiation of `const size_t std::basic_string<char, gnu_char_traits, std::allocator<char> >::npos':
> /home/fsirl/TC/gcc/BUILD/gcc-3.1/libstdc++-v3/testsuite/26_numerics/complex_inserters_extractors.cc:109:   
> instantiated from here
> /home/fsirl/TC/gcc/BUILD/obj-gcc31-ppc/ppc-linux/libstdc++-v3/include/bits/basic_string.h:217: 
> warning: weak declaration of `const size_t std::basic_string<char,
> gnu_char_traits, std::allocator<char> >::npos' after first use may result
> in unspecified behaviour

> Can a c++ expert tell me if this warning makes sense in this testcase or does 
> the warning check need still more refinement?

The latter.  We don't want to warn about the C++ frontend's internal
trickery with DECL_WEAK.

I'd prefer to omit the warning entirely on the branch.

> Hmm, Jason, I'm just noticing the purpose of the test in weak_finish.
...
> Are we sure there is no code out there relying on these lonely .weak 
> statements? Was this change intended?

I believe so.  But Richard was the one who made the change.

Jason

Re: GCC 3.1 Prerelease

[Jason Merrill]

>>>>> "Franz" == Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

> +  if (DECL_WEAK (newdecl) && DECL_RTL (newdecl)
> +      && GET_CODE (DECL_RTL (newdecl)) == MEM
> +      && XEXP (DECL_RTL (newdecl), 0)
> +      && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF)
> +    SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1;

This should use DECL_RTL_SET_P.  Also, wouldn't it make sense to handle
this in declare_weak?

Jason

Re: GCC 3.1 Prerelease

[Per Bothner]

I just created pr java/6425.
I'm biased, but I think this needs to be fixed before the release.
Nic Ferrier discovered it, I verified it yesterday, and sent a
message to the java list.  No answers yet.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: GCC 3.1 Prerelease

[Mark Mitchell]

--On Tuesday, April 23, 2002 08:54:45 AM -0700 Per Bothner 
<per@bothner.com> wrote:

> I just created pr java/6425.
> I'm biased, but I think this needs to be fixed before the release.

Don't be biased; just tell me if it's a regression. :-)

If it is, we should fix it.

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

Re: GCC 3.1 Prerelease

[Per Bothner]

Mark Mitchell wrote:
> 
> 
> --On Tuesday, April 23, 2002 08:54:45 AM -0700 Per Bothner 
> <per@bothner.com> wrote:
> 
>> I just created pr java/6425.
>> I'm biased, but I think this needs to be fixed before the release.
> 
> 
> Don't be biased; just tell me if it's a regression. :-)
> 
> If it is, we should fix it.

It's a regression.  Last time I tried to build Kawa using
gcj, it worked.  Now it doesn't.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: GCC 3.1 Prerelease

[Mark Mitchell]

--On Tuesday, April 23, 2002 09:49:34 AM -0700 Per Bothner 
<per@bothner.com> wrote:

> Mark Mitchell wrote:
>>
>>
>> --On Tuesday, April 23, 2002 08:54:45 AM -0700 Per Bothner
>> <per@bothner.com> wrote:
>>
>>> I just created pr java/6425.
>>> I'm biased, but I think this needs to be fixed before the release.
>>
>>
>> Don't be biased; just tell me if it's a regression. :-)
>>
>> If it is, we should fix it.
>
> It's a regression.  Last time I tried to build Kawa using
> gcj, it worked.  Now it doesn't.

Please mark that sucker high priority then.  And see if you can fix it! :-)

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

Re: GCC 3.1 Prerelease

[Tom Tromey]

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

Per> I just created pr java/6425.  I'm biased, but I think this needs
Per> to be fixed before the release.

I looked at this.

First, the problem occurs on this line:

    sbuf.append(RealNum.toScaledInt(number, 10).toString());

Breaking this into two lines, like so, makes the code compile:

    IntNum x = RealNum.toScaledInt(number, 10);
    sbuf.append(x.toString());

That's interesting information.  It helped me track down the
difference between what happens when things go ok and when they don't.
However I don't fully understand what it means.


The class-loading code seems pretty fragile.  If it is going to
compare file names it seems like it ought to compare the results of
realpath().  Otherwise there might be ways to fool it.  However, while
this code isn't ideal (as far as I can see anyway), I think the
problem lies elsewhere.


The appended patch fixes the problem for me.  What happened was we got
to this code with an EXPR_WITH_FILE_LOCATION like this:

            arg 0 <expr_with_file_location 0x4012a420
                arg 0 <identifier_node 0x4012a480 RealNum.toScaledInt tree_2> arg 1 <identifier_node 0x40126340 FixedRealFormat.java>
                arg 2 <tree_list 0x4012917c
                    purpose <expr_with_file_location 0x4012a4a0
                        arg 0 <identifier_node 0x4012a400 RealNum> arg 1 <identifier_node 0x40126340 FixedRealFormat.java>
                        FixedRealFormat.java:9:16>
                    chain <tree_list 0x40129190
                        purpose <expr_with_file_location 0x4012a4c0 arg 0 <identifier_node 0x4012a440 toScaledInt> arg 1 <identifier_node 0x40126340 FixedRealFormat.java>
                            FixedRealFormat.java:9:23>>>
                FixedRealFormat.java:9:16>

If we strip the outer EXPR_WITH_FILE_LOCATION, as the patch does, we
end up with qual_wfl as:

    <identifier_node 0x4012a400 RealNum>


Anyway, I don't really understand what is going on here.  I assume
there is some reason for the existing `if', but I don't know what it
is.  I'm going to try rebuilding libgcj with this patch and see how
that goes.

Alex, can you look at this quickly?  As far as I know you're the only
one who really understands this code.

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	* parse.y (qualify_ambiguous_name) [case CALL_EXPR]: Always choose
	EXPR_WFL_QUALIFICATION of qual_wfl.

Index: parse.y
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v
retrieving revision 1.353.2.17
diff -u -r1.353.2.17 parse.y
--- parse.y 15 Apr 2002 09:28:53 -0000 1.353.2.17
+++ parse.y 23 Apr 2002 21:01:01 -0000
@@ -11219,11 +11219,8 @@
       {
       case CALL_EXPR:
 	qual_wfl = TREE_OPERAND (qual_wfl, 0);
-	if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION)
-	  {
-	    qual = EXPR_WFL_QUALIFICATION (qual_wfl);
-	    qual_wfl = QUAL_WFL (qual);
-	  }
+	qual = EXPR_WFL_QUALIFICATION (qual_wfl);
+	qual_wfl = QUAL_WFL (qual);
 	break;
       case NEW_ARRAY_EXPR:
       case NEW_ANONYMOUS_ARRAY_EXPR:

Re: GCC 3.1 Prerelease

[Per Bothner]

Tom Tromey wrote:
> Index: ChangeLog
> from  Tom Tromey  <tromey@redhat.com>
> 
> 	* parse.y (qualify_ambiguous_name) [case CALL_EXPR]: Always choose
> 	EXPR_WFL_QUALIFICATION of qual_wfl.
> 
> Index: parse.y
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v
> retrieving revision 1.353.2.17
> diff -u -r1.353.2.17 parse.y
> --- parse.y 15 Apr 2002 09:28:53 -0000 1.353.2.17
> +++ parse.y 23 Apr 2002 21:01:01 -0000
> @@ -11219,11 +11219,8 @@
>        {
>        case CALL_EXPR:
>  	qual_wfl = TREE_OPERAND (qual_wfl, 0);
> -	if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION)
> -	  {
> -	    qual = EXPR_WFL_QUALIFICATION (qual_wfl);
> -	    qual_wfl = QUAL_WFL (qual);
> -	  }
> +	qual = EXPR_WFL_QUALIFICATION (qual_wfl);
> +	qual_wfl = QUAL_WFL (qual);
>  	break;
>        case NEW_ARRAY_EXPR:
>        case NEW_ANONYMOUS_ARRAY_EXPR:

This patch causes building Kawa to break even earlier (while
generating class files).
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: GCC 3.1 Prerelease

[Tom Tromey]

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

Per> This patch causes building Kawa to break even earlier (while
Per> generating class files).

Yeah, I saw that once I started rebuilding libgcj with it.  Try the
appended.  We really need Alex to look at this though.

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	* parse.y (qualify_ambiguous_name) [case CALL_EXPR]: Always choose
	EXPR_WFL_QUALIFICATION of qual_wfl.

Index: parse.y
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v
retrieving revision 1.353.2.17
diff -u -r1.353.2.17 parse.y
--- parse.y 15 Apr 2002 09:28:53 -0000 1.353.2.17
+++ parse.y 23 Apr 2002 23:04:15 -0000
@@ -11219,7 +11219,9 @@
       {
       case CALL_EXPR:
 	qual_wfl = TREE_OPERAND (qual_wfl, 0);
-	if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION)
+	if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION
+	    || (EXPR_WFL_QUALIFICATION (qual_wfl)
+		&& TREE_CODE (EXPR_WFL_QUALIFICATION (qual_wfl)) == TREE_LIST))
 	  {
 	    qual = EXPR_WFL_QUALIFICATION (qual_wfl);
 	    qual_wfl = QUAL_WFL (qual);

Re: GCC 3.1 Prerelease

[Alexandre Petit-Bianco]

Tom Tromey writes:

> Yeah, I saw that once I started rebuilding libgcj with it.  Try the
> appended.  We really need Alex to look at this though.

From the debug session information that you sent, this is making
sense. I'm not seing any regression in all my build tests (3500 files)
and I believe it improves the situation with my (old) copy of Freenet.

I'll be able to do some real debugging tonight at the earliest. In the
meantime, if we're short on time, this should probably go in.

Thank you for looking into this,

./A

Re: GCC 3.1 Prerelease

[Tom Tromey]

>>>>> "Alex" == Alexandre Petit-Bianco <apbianco@cygnus.com> writes:

Alex> From the debug session information that you sent, this is making
Alex> sense. I'm not seing any regression in all my build tests (3500
Alex> files) and I believe it improves the situation with my (old)
Alex> copy of Freenet.

Alex> I'll be able to do some real debugging tonight at the
Alex> earliest. In the meantime, if we're short on time, this should
Alex> probably go in.

Thanks.

It rebuilt libgcj fine.  I'll run the test suite (plus Mauve) shortly.
I also plan to rebuild rhug with this patch.

Mark, assuming the tests go well, is this ok for the branch?  It fixes
the last high priority gcj PR.

Alex,

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>
	For PR java/6425:
	* parse.y (qualify_ambiguous_name) [case CALL_EXPR]: Always choose
	EXPR_WFL_QUALIFICATION of qual_wfl.

Index: parse.y
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v
retrieving revision 1.353.2.17
diff -u -r1.353.2.17 parse.y
--- parse.y 15 Apr 2002 09:28:53 -0000 1.353.2.17
+++ parse.y 24 Apr 2002 17:24:30 -0000
@@ -11219,7 +11219,9 @@
       {
       case CALL_EXPR:
 	qual_wfl = TREE_OPERAND (qual_wfl, 0);
-	if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION)
+	if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION
+	    || (EXPR_WFL_QUALIFICATION (qual_wfl)
+		&& TREE_CODE (EXPR_WFL_QUALIFICATION (qual_wfl)) == TREE_LIST))
 	  {
 	    qual = EXPR_WFL_QUALIFICATION (qual_wfl);
 	    qual_wfl = QUAL_WFL (qual);

Re: GCC 3.1 Prerelease

[Mark Mitchell]

> Mark, assuming the tests go well, is this ok for the branch?  It fixes
> the last high priority gcj PR.

Yes, thanks!

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

Re: GCC 3.1 Prerelease

[Richard Henderson]

On Tue, Apr 23, 2002 at 02:01:25AM -0700, Mark Mitchell wrote:
> There are a handful of open bugs remaining that need fixes.  By far and
> away the most worrisome are the IRIX regressions in PR 6212 and PR 6304.

I've been looking at them off and on for the last week or so, but have
made practically no headway.  I've been thwarted by the inability to
attach a debugger to an N64 binary.  (SGI's dbx crashes and GDB complains
about incorrect dwarf2, i.e. gdb doesn't understand the random changes
SGI made to dwarf2.)

I've been considering ripping out all of the MIPS_DEBUGGING_INFO bits
in dwarf2out.c and seeing if that would allow progress.  :-/


r~

Re: GCC 3.1 Prerelease

[Mark Mitchell]

--On Tuesday, April 23, 2002 12:22:54 PM -0700 Richard Henderson 
<rth@redhat.com> wrote:

> On Tue, Apr 23, 2002 at 02:01:25AM -0700, Mark Mitchell wrote:
>> There are a handful of open bugs remaining that need fixes.  By far and
>> away the most worrisome are the IRIX regressions in PR 6212 and PR 6304.
>
> I've been looking at them off and on for the last week or so, but have
> made practically no headway.  I've been thwarted by the inability to
> attach a debugger to an N64 binary.

Bummer.

> I've been considering ripping out all of the MIPS_DEBUGGING_INFO bits
> in dwarf2out.c and seeing if that would allow progress.  :-/

Or use printf?

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

Re: GCC 3.1 Prerelease

[Richard Henderson]

On Tue, Apr 23, 2002 at 01:22:18PM -0700, Mark Mitchell wrote:
> Or use printf?

In all likelyhood, it's a problem restoring registers.  In 
which case, making any function calls at all is a non-starter.


r~

Re: GCC 3.1 Prerelease

[Mark Mitchell]

--On Tuesday, April 23, 2002 01:28:40 PM -0700 Richard Henderson 
<rth@redhat.com> wrote:

> On Tue, Apr 23, 2002 at 01:22:18PM -0700, Mark Mitchell wrote:
>> Or use printf?
>
> In all likelyhood, it's a problem restoring registers.  In
> which case, making any function calls at all is a non-starter.

I meant in the unwinder to try to see what it thought it was doing.

Are we already hosed at that point?

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

Re: GCC 3.1 Prerelease

[Richard Henderson]

On Tue, Apr 23, 2002 at 01:35:05PM -0700, Mark Mitchell wrote:
> I meant in the unwinder to try to see what it thought it was doing.

Oh, I see.  Yes, one could verify that we did in fact find
the frame we intended that way.

> Are we already hosed at that point?

I doubt it.


r~

RE: GCC 3.1 Prerelease

[Billinghurst, David (CRTS)]

I have updated the two irix PRs with test cases and additional information

PR6212 - g++ testsuite EH regressions for irix6 -mabi=64
PR6304 - Failure of LAPACK test dtest on irix6.5 with -mabi=64 -O2

Re: GCC 3.1 Prerelease

[Wolfgang Bangerth]

> To that end, I would very much like to see if we can get some more of
> the open bugs fixed before that point.  (I know that people are already
> working on some of these at this point.)
>
> Here is a list of the current high-priority bugs order by category.

Maybe it's too late, but maybe not: PR c++/6256 is another one that might 
be worth fixing since it can't be worked around and since it is a 
regression from 2.95.

Regards
  Wolfgang

-------------------------------------------------------------------------
Wolfgang Bangerth                  email:           bangerth@math.ethz.ch
                                   www: http://www.math.ethz.ch/~bangerth

Re: GCC 3.1 Prerelease

[Toon Moene]

Dave wrote:

>> 2002-04-21  Mark Mitchell  <mark@codesourcery.com>
>> 
>>       PR f/6318.

> Thanks for spending your precious time to fix this problem.

Seconded !

The fix makes clear that this problem was far beyond my capabilities
w.r.t. hacking gcc ...

Thanks Mark !

--
Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands.
Tel. +31302206443, Fax +31302210407,  e-mail moene@knmi.nl
URL: http://www.knmi.nl/hirlam

Re: GCC 3.1 Prerelease

[John David Anglin]

These are the PA issues regarding the 3.1 release:

Fortran:

PR6138: Incorrect access of interger*1 variables on PA.

This is a regression from 3.0.x, and it also affects powerpc. In my opinion,
it is a verious serious bug affecting many programs and should be fixed
before the 3.1 release.  The problem is in the front-end, in code that
I am not familiar with.

C++:

g++.jason/synth5.C: this testsuite fail is a regression that occurred
about March 15.  The errors are:

synth5.h:3: storage size of `_ZTI1A' isn't known
synth5.h:7: storage size of `_ZTI1B' isn't known

At the moment, I don't consider this regression to be a very serious problem.
It also affects powerpc.

C:

This thread <http://gcc.gnu.org/ml/gcc/2002-04/msg00534.html> discusses
a problem initially found building bleadperl with hppa64-hp-hpux.  While
there is a problem with the machine definition, the analysis done so
far points to problems in register allocation and optimization as the root
causes of the compilation failure.  These problems are not in 3.0.x.

The register allocation issue seems similar to that discussed in this
thread <http://gcc.gnu.org/ml/gcc-patches/2002-04/msg01094.html>.  In
the PA case, a FP register was selected in a situation where a general
register should have been selected.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.1 Prerelease

[Mark Mitchell]

> C++:
>
> g++.jason/synth5.C: this testsuite fail is a regression that occurred
> about March 15.  The errors are:

Please file a PR for this issue and send me the PR number.

> C:

Likewise.

It would have been really nice to have known about these issues sooner.

Let's all try to use our bug-tracking system.  Please mark regressions
as high-priority when they are discovered -- or ask a maintainer to
do it for you.  Also, when these issues get reported on mailing lists,
we should try to fix them quickly.  For example, if the synth5.C
problem was discovered March 15th, and the offending patch identified,
and the offending patcher pinged, we'd likely already have a fix. :-)

If you can identify a patch that causes a new failure, please hound
the contributor until they fix the problem.  Don't fear being rude;
the person who checked in the patch is responsible for fixing the
damage done, or backing out the patch.

Thanks to all,

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

Re: GCC 3.1 Prerelease

[John David Anglin]

> > C++:
> >
> > g++.jason/synth5.C: this testsuite fail is a regression that occurred
> > about March 15.  The errors are:
> 
> Please file a PR for this issue and send me the PR number.

I have updated PR6395 after confirming this afternoon that the suspected
patch

2002-03-15  Jason Merrill  <jason@redhat.com>

        * decl.c (make_rtl_for_nonlocal_decl): Also defer COMDAT
	variables.

is in fact the cause of the regression.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.1 Prerelease

[Toon Moene]

John David Anglin wrote:

> Fortran:
> 
> PR6138: Incorrect access of interger*1 variables on PA.
> 
> This is a regression from 3.0.x, and it also affects powerpc. In my opinion,
> it is a verious serious bug affecting many programs and should be fixed
> before the 3.1 release.  The problem is in the front-end, in code that
> I am not familiar with.

This and PR Fortran/6304 are indeed the only Fortran *regressions* I'm
aware of.  Whether this one affects a lot of people is open to debate:
In my experience not many are using the INTEGER*1 extension (mostly
because its support in g77 is not complete).

I'm not entirely sure it's a bug in the frontend; however, in the four
hours I spent on it yesterday I was unable to find a C equivalent for
the following, minimal, example of the problem:

      integer*2 j
      integer*1 k
      j = -9
      k = j
      if (k .ne. j) call abort
      print*,j
      end

[ The `print*,j' line is necessary because it forces gcc to store
  j on the stack - which leads to the access error. ]

The problem is hard to track down - already the .f.00.rtl dump is wrong
when optimizing (another hint that it might be a bug in the frontend -
however, that means that we have to explain how the frontend can
generate different RTL based on optimization flags) ...

Affects powerpc and hppa.

Hope this helps,

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

[Mark Mitchell]

--On Sunday, April 21, 2002 02:46:52 PM +0200 Toon Moene 
<toon@moene.indiv.nluug.nl> wrote:

> John David Anglin wrote:
>
>> Fortran:
>>
>> PR6138: Incorrect access of interger*1 variables on PA.

> The problem is hard to track down - already the .f.00.rtl dump is wrong
> when optimizing (another hint that it might be a bug in the frontend -
> however, that means that we have to explain how the frontend can
> generate different RTL based on optimization flags) ...
>
> Affects powerpc and hppa.

Often, the change between optimizing and non-optimizing comes up in
fixup_var_refs -- and that is the culprit here.  (When optimizing,
we try to keep things in registers, and only dump them to the stack
when necessary.)

Before fixup_var_refs, we have:

(insn 12 10 14 (set (reg/v:SI 115)
        (const_int -9 [0xfffffffffffffff7])) -1 (nil)
    (nil))

(insn 17 15 19 (set (reg/v:SI 116)
        (sign_extend:SI (subreg:QI (reg/v:SI 115) 3))) -1 (nil)
    (nil))

Insn 17 is the one that gets screwed up.  What happens is that
we replace (reg/v:SI 115) with (mem/f:HI (reg/f:SI 111 virtual-stack-vars))
because the original mode of the variable was HImode, not SImode.  (We
created an SImode register because we thought that would be more
efficient.)

So, after substitution, we have, in insn 17:

  (set (reg/v:SI 116)
       (sign_extend:SI (subreg:QI (mem/f:HI ...) 3)))

This is bogus; we no longer want byte 3 of the HI mode mem, we want
byte 1 of the HI mode mem.

Here's a patch which I think will fix the problem.  I'm going to
test this on i686-pc-linux-gnu, but I'd appreciate it if

a) someone knowledgeable would sanity check the patch, and

b) someone would bootstrap/test on a PowerPC or HPPA platform, which
   we know is susceptible to these issues.

Thanks,

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

2002-04-21  Mark Mitchell  <mark@codesourcery.com>

	PR f/6318.
	* function.c (fixup_memory_subreg): Add promoted_mode parameter.
	(walk_fixup_memory_subreg): Likewise.
	(fixup_var_refs_insn): Adjust accordingly.
	(fixup_var_refs_1): Likewise.

Index: function.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/function.c,v
retrieving revision 1.347.2.4
diff -c -p -r1.347.2.4 function.c
*** function.c	12 Apr 2002 11:37:42 -0000	1.347.2.4
--- function.c	21 Apr 2002 18:36:43 -0000
*************** static void fixup_var_refs_insn PARAMS (
*** 252,259 ****
  					 int, int, rtx));
  static void fixup_var_refs_1	PARAMS ((rtx, enum machine_mode, rtx *, rtx,
  					 struct fixup_replacement **, rtx));
! static rtx fixup_memory_subreg	PARAMS ((rtx, rtx, int));
! static rtx walk_fixup_memory_subreg  PARAMS ((rtx, rtx, int));
  static rtx fixup_stack_1	PARAMS ((rtx, rtx));
  static void optimize_bit_field	PARAMS ((rtx, rtx, rtx *));
  static void instantiate_decls	PARAMS ((tree, int));
--- 252,260 ----
  					 int, int, rtx));
  static void fixup_var_refs_1	PARAMS ((rtx, enum machine_mode, rtx *, rtx,
  					 struct fixup_replacement **, rtx));
! static rtx fixup_memory_subreg	PARAMS ((rtx, rtx, enum machine_mode, 
int));
! static rtx walk_fixup_memory_subreg  PARAMS ((rtx, rtx, enum 
machine_mode,
! 					      int));
  static rtx fixup_stack_1	PARAMS ((rtx, rtx));
  static void optimize_bit_field	PARAMS ((rtx, rtx, rtx *));
  static void instantiate_decls	PARAMS ((tree, int));
*************** fixup_var_refs_insn (insn, var, promoted
*** 1868,1874 ****
  	      /* OLD might be a (subreg (mem)).  */
  	      if (GET_CODE (replacements->old) == SUBREG)
  		replacements->old
! 		  = fixup_memory_subreg (replacements->old, insn, 0);
  	      else
  		replacements->old
  		  = fixup_stack_1 (replacements->old, insn);
--- 1869,1876 ----
  	      /* OLD might be a (subreg (mem)).  */
  	      if (GET_CODE (replacements->old) == SUBREG)
  		replacements->old
! 		  = fixup_memory_subreg (replacements->old, insn,
! 					 promoted_mode, 0);
  	      else
  		replacements->old
  		  = fixup_stack_1 (replacements->old, insn);
*************** fixup_var_refs_insn (insn, var, promoted
*** 1908,1914 ****
      {
        if (GET_CODE (note) != INSN_LIST)
  	XEXP (note, 0)
! 	  = walk_fixup_memory_subreg (XEXP (note, 0), insn, 1);
        note = XEXP (note, 1);
      }
  }
--- 1910,1917 ----
      {
        if (GET_CODE (note) != INSN_LIST)
  	XEXP (note, 0)
! 	  = walk_fixup_memory_subreg (XEXP (note, 0), insn,
! 				      promoted_mode, 1);
        note = XEXP (note, 1);
      }
  }
*************** fixup_var_refs_1 (var, promoted_mode, lo
*** 2079,2085 ****
  		  return;
  		}
  	      else
! 		tem = fixup_memory_subreg (tem, insn, 0);
  	    }
  	  else
  	    tem = fixup_stack_1 (tem, insn);
--- 2082,2088 ----
  		  return;
  		}
  	      else
! 		tem = fixup_memory_subreg (tem, insn, promoted_mode, 0);
  	    }
  	  else
  	    tem = fixup_stack_1 (tem, insn);
*************** fixup_var_refs_1 (var, promoted_mode, lo
*** 2194,2200 ****
  	      return;
  	    }

! 	  replacement->new = *loc = fixup_memory_subreg (x, insn, 0);

  	  INSN_CODE (insn) = -1;
  	  if (! flag_force_mem && recog_memoized (insn) >= 0)
--- 2197,2204 ----
  	      return;
  	    }

! 	  replacement->new = *loc = fixup_memory_subreg (x, insn,
! 							 promoted_mode, 0);

  	  INSN_CODE (insn) = -1;
  	  if (! flag_force_mem && recog_memoized (insn) >= 0)
*************** fixup_var_refs_1 (var, promoted_mode, lo
*** 2285,2291 ****
  	       This was legitimate when the MEM was a REG.  */
  	    if (GET_CODE (tem) == SUBREG
  		&& SUBREG_REG (tem) == var)
! 	      tem = fixup_memory_subreg (tem, insn, 0);
  	    else
  	      tem = fixup_stack_1 (tem, insn);

--- 2289,2295 ----
  	       This was legitimate when the MEM was a REG.  */
  	    if (GET_CODE (tem) == SUBREG
  		&& SUBREG_REG (tem) == var)
! 	      tem = fixup_memory_subreg (tem, insn, promoted_mode, 0);
  	    else
  	      tem = fixup_stack_1 (tem, insn);

*************** fixup_var_refs_1 (var, promoted_mode, lo
*** 2387,2393 ****
  		  SET_SRC (x) = replacement->new;
  		else if (GET_CODE (SET_SRC (x)) == SUBREG)
  		  SET_SRC (x) = replacement->new
! 		    = fixup_memory_subreg (SET_SRC (x), insn, 0);
  		else
  		  SET_SRC (x) = replacement->new
  		    = fixup_stack_1 (SET_SRC (x), insn);
--- 2391,2398 ----
  		  SET_SRC (x) = replacement->new;
  		else if (GET_CODE (SET_SRC (x)) == SUBREG)
  		  SET_SRC (x) = replacement->new
! 		    = fixup_memory_subreg (SET_SRC (x), insn, promoted_mode,
! 					   0);
  		else
  		  SET_SRC (x) = replacement->new
  		    = fixup_stack_1 (SET_SRC (x), insn);
*************** fixup_var_refs_1 (var, promoted_mode, lo
*** 2440,2446 ****
  	    rtx pat, last;

  	    if (GET_CODE (SET_DEST (x)) == SUBREG)
! 	      SET_DEST (x) = fixup_memory_subreg (SET_DEST (x), insn, 0);
  	    else
  	      SET_DEST (x) = fixup_stack_1 (SET_DEST (x), insn);

--- 2445,2452 ----
  	    rtx pat, last;

  	    if (GET_CODE (SET_DEST (x)) == SUBREG)
! 	      SET_DEST (x) = fixup_memory_subreg (SET_DEST (x), insn,
! 						  promoted_mode, 0);
  	    else
  	      SET_DEST (x) = fixup_stack_1 (SET_DEST (x), insn);

*************** fixup_var_refs_1 (var, promoted_mode, lo
*** 2492,2498 ****
  	    /* Convert (SUBREG (MEM)) to a MEM in a changed mode.  */
  	    if (GET_CODE (fixeddest) == SUBREG)
  	      {
! 		fixeddest = fixup_memory_subreg (fixeddest, insn, 0);
  		promoted_mode = GET_MODE (fixeddest);
  	      }
  	    else
--- 2498,2505 ----
  	    /* Convert (SUBREG (MEM)) to a MEM in a changed mode.  */
  	    if (GET_CODE (fixeddest) == SUBREG)
  	      {
! 		fixeddest = fixup_memory_subreg (fixeddest, insn,
! 						 promoted_mode, 0);
  		promoted_mode = GET_MODE (fixeddest);
  	      }
  	    else
*************** fixup_var_refs_1 (var, promoted_mode, lo
*** 2531,2554 ****
      }
  }
  \f
! /* Given X, an rtx of the form (SUBREG:m1 (MEM:m2 addr)),
!    return an rtx (MEM:m1 newaddr) which is equivalent.
!    If any insns must be emitted to compute NEWADDR, put them before INSN.

     UNCRITICAL nonzero means accept paradoxical subregs.
     This is used for subregs found inside REG_NOTES.  */

  static rtx
! fixup_memory_subreg (x, insn, uncritical)
       rtx x;
       rtx insn;
       int uncritical;
  {
!   int offset = SUBREG_BYTE (x);
    rtx addr = XEXP (SUBREG_REG (x), 0);
    enum machine_mode mode = GET_MODE (x);
    rtx result;

    /* Paradoxical SUBREGs are usually invalid during RTL generation.  */
    if (GET_MODE_SIZE (mode) > GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)))
        && ! uncritical)
--- 2538,2569 ----
      }
  }
  \f
! /* Previously, X had the form (SUBREG:m1 (REG:PROMOTED_MODE ...)).
!    The REG  was placed on the stack, so X now has the form (SUBREG:m1
!    (MEM:m2 ...)).
!
!    Return an rtx (MEM:m1 newaddr) which is equivalent.  If any insns
!    must be emitted to compute NEWADDR, put them before INSN.

     UNCRITICAL nonzero means accept paradoxical subregs.
     This is used for subregs found inside REG_NOTES.  */

  static rtx
! fixup_memory_subreg (x, insn, promoted_mode, uncritical)
       rtx x;
       rtx insn;
+      enum machine_mode promoted_mode;
       int uncritical;
  {
!   int offset;
    rtx addr = XEXP (SUBREG_REG (x), 0);
    enum machine_mode mode = GET_MODE (x);
    rtx result;

+   offset = (SUBREG_BYTE (x)
+ 	    - (GET_MODE_SIZE (promoted_mode)
+ 	       - GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)))));
+
    /* Paradoxical SUBREGs are usually invalid during RTL generation.  */
    if (GET_MODE_SIZE (mode) > GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)))
        && ! uncritical)
*************** fixup_memory_subreg (x, insn, uncritical
*** 2571,2584 ****
     If X itself is a (SUBREG (MEM ...) ...), return the replacement 
expression.
     Otherwise return X, with its contents possibly altered.

!    If any insns must be emitted to compute NEWADDR, put them before INSN.
!
!    UNCRITICAL is as in fixup_memory_subreg.  */

  static rtx
! walk_fixup_memory_subreg (x, insn, uncritical)
       rtx x;
       rtx insn;
       int uncritical;
  {
    enum rtx_code code;
--- 2586,2599 ----
     If X itself is a (SUBREG (MEM ...) ...), return the replacement 
expression.
     Otherwise return X, with its contents possibly altered.

!    INSN, PROMOTED_MODE and UNCRITICAL are as for
!    fixup_memory_subreg.  */

  static rtx
! walk_fixup_memory_subreg (x, insn, promoted_mode, uncritical)
       rtx x;
       rtx insn;
+      enum machine_mode promoted_mode;
       int uncritical;
  {
    enum rtx_code code;
*************** walk_fixup_memory_subreg (x, insn, uncri
*** 2591,2597 ****
    code = GET_CODE (x);

    if (code == SUBREG && GET_CODE (SUBREG_REG (x)) == MEM)
!     return fixup_memory_subreg (x, insn, uncritical);

    /* Nothing special about this RTX; fix its operands.  */

--- 2606,2612 ----
    code = GET_CODE (x);

    if (code == SUBREG && GET_CODE (SUBREG_REG (x)) == MEM)
!     return fixup_memory_subreg (x, insn, promoted_mode, uncritical);

    /* Nothing special about this RTX; fix its operands.  */

*************** walk_fixup_memory_subreg (x, insn, uncri
*** 2599,2611 ****
    for (i = GET_RTX_LENGTH (code) - 1; i >= 0; i--)
      {
        if (fmt[i] == 'e')
! 	XEXP (x, i) = walk_fixup_memory_subreg (XEXP (x, i), insn, uncritical);
        else if (fmt[i] == 'E')
  	{
  	  int j;
  	  for (j = 0; j < XVECLEN (x, i); j++)
  	    XVECEXP (x, i, j)
! 	      = walk_fixup_memory_subreg (XVECEXP (x, i, j), insn, uncritical);
  	}
      }
    return x;
--- 2614,2628 ----
    for (i = GET_RTX_LENGTH (code) - 1; i >= 0; i--)
      {
        if (fmt[i] == 'e')
! 	XEXP (x, i) = walk_fixup_memory_subreg (XEXP (x, i), insn,
! 						promoted_mode, uncritical);
        else if (fmt[i] == 'E')
  	{
  	  int j;
  	  for (j = 0; j < XVECLEN (x, i); j++)
  	    XVECEXP (x, i, j)
! 	      = walk_fixup_memory_subreg (XVECEXP (x, i, j), insn,
! 					  promoted_mode, uncritical);
  	}
      }
    return x;

Re: GCC 3.1 Prerelease

[Franz Sirl]

On Sunday 21 April 2002 20:44, Mark Mitchell wrote:
> b) someone would bootstrap/test on a PowerPC or HPPA platform, which
>    we know is susceptible to these issues.

I can confirm that this patch fixes the testcase on powerpc-linux-gnu, I'll 
run a full bootstrap tomorrow, as I've currently a -O3 bootstrap running.

Overall I'm currently _highly_ satisfied with the status of the branch on 
powerpc-linux-gnu :-))).

Mark, this leaves only one PR I would like to see fixed before the release, 
namely PR c++/6112 (which hasn't been upgraded to 'high priority', even 
though it's a regression). This PR may be related to the other PR's on lost 
'const' qualifiers in c++.

Franz.

Re: GCC 3.1 Prerelease

[Gerald Pfeifer]

On Sun, 21 Apr 2002, Franz Sirl wrote:
> Mark, this leaves only one PR I would like to see fixed before the release,
> namely PR c++/6112 (which hasn't been upgraded to 'high priority', even
> though it's a regression).

I have upgraded it for you now.

(As you have CVS write access, you should have also received GNATS write
access with your account, BTW.)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: GCC 3.1 Prerelease

[Franz Sirl]

On Sunday 21 April 2002 21:58, Franz Sirl wrote:
> On Sunday 21 April 2002 20:44, Mark Mitchell wrote:
> > b) someone would bootstrap/test on a PowerPC or HPPA platform, which
> >    we know is susceptible to these issues.
>
> I can confirm that this patch fixes the testcase on powerpc-linux-gnu, I'll
> run a full bootstrap tomorrow, as I've currently a -O3 bootstrap running.

Bootstrapped and tested on powerpc-linux-gnu without regressions. Built and 
checked glibc with it, no problems either.

Franz.

Re: GCC 3.1 Prerelease

[Mark Mitchell]

--On Monday, April 22, 2002 07:46:53 PM +0200 Franz Sirl 
<Franz.Sirl-kernel@lauterbach.com> wrote:

> On Sunday 21 April 2002 21:58, Franz Sirl wrote:
>> On Sunday 21 April 2002 20:44, Mark Mitchell wrote:
>> > b) someone would bootstrap/test on a PowerPC or HPPA platform, which
>> >    we know is susceptible to these issues.
>>
>> I can confirm that this patch fixes the testcase on powerpc-linux-gnu,
>> I'll run a full bootstrap tomorrow, as I've currently a -O3 bootstrap
>> running.
>
> Bootstrapped and tested on powerpc-linux-gnu without regressions. Built
> and  checked glibc with it, no problems either.

Thanks!

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

Re: GCC 3.1 Prerelease

[John David Anglin]

Mark,

> 2002-04-21  Mark Mitchell  <mark@codesourcery.com>
> 
> 	PR f/6318.
> 	* function.c (fixup_memory_subreg): Add promoted_mode parameter.
> 	(walk_fixup_memory_subreg): Likewise.
> 	(fixup_var_refs_insn): Adjust accordingly.
> 	(fixup_var_refs_1): Likewise.

I have completed a bootstrap and check with the patch on hppa2.0w-hp-hpux11.11.
There are no regressions and the fortran problem is fixed.  There are now no
unexpected failures in the fortran testsuite :-)

Thanks for spending your precious time to fix this problem.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.1 Prerelease

[Richard Henderson]

On Sun, Apr 21, 2002 at 11:44:27AM -0700, Mark Mitchell wrote:
> +   offset = (SUBREG_BYTE (x)
> + 	    - (GET_MODE_SIZE (promoted_mode)
> + 	       - GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)))));

Surely this adjustment should be big-endian only.


r~

Re: GCC 3.1 Prerelease

[Mark Mitchell]

--On Monday, April 22, 2002 12:07:01 AM -0700 Richard Henderson 
<rth@redhat.com> wrote:

> On Sun, Apr 21, 2002 at 11:44:27AM -0700, Mark Mitchell wrote:
>> +   offset = (SUBREG_BYTE (x)
>> + 	    - (GET_MODE_SIZE (promoted_mode)
>> + 	       - GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)))));
>
> Surely this adjustment should be big-endian only.

Indeed.  Also, there is this oddity in fixup_var_refs_1:

	    if (GET_CODE (fixeddest) == SUBREG)
	      {
		fixeddest = fixup_memory_subreg (fixeddest, insn, 0);
		promoted_mode = GET_MODE (fixeddest);
	      }

This makes no sense since promoted_mode is supposed to be the property
of the thing being replaced and that's not changing.  I fixed
that, too; only the new temporary register needs the mode of fixeddest.

I'll commit a modified version of the patch that corrects these two
issues after one more test cycle on my local box.

Thanks,

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

RE: GCC 3.1 Prerelease

[Billinghurst, David (CRTS)]

These two irix6.5 PRs are significant regressions

PR6212 - g++ testsuite EH regressions for irix6 -mabi=64
PR6304 - Failure of LAPACK test dtest on irix6.5 with -mabi=64 -O2

PR6304 was introduced on 2001-12-13 between 00:00 and 13:00 UTC.  I should find the exact patch in the next 24 hours, or so.  

RE: GCC 3.1 Prerelease

[Mark Mitchell]

--On Sunday, April 21, 2002 12:03:47 PM +1000 "Billinghurst, David (CRTS)" 
<David.Billinghurst@riotinto.com> wrote:

> These two irix6.5 PRs are significant regressions
>
> PR6212 - g++ testsuite EH regressions for irix6 -mabi=64

Have you gotten Kenner the preprocessed source of the file that
changed with his patch?  Can you confirm that reverting Kenner's
patch still fixes the problem, or is there something else going
wrong as well?

The expand_eh_return/expand_builtin_eh_return changes could certainly
be affecting things.  (The change you highlighted in your original
posting has already been reverted.)

Please update the PR with this additional information and work with
Kenner to resolve the problem if it is indeed his patch that is
causing it.

> PR6304 - Failure of LAPACK test dtest on irix6.5 with -mabi=64 -O2

I've upgraded these to high priority.  Please add the dsptrf.f source to
the bug report for convenience of those trying to fix it.

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

Re: GCC 3.1 Prerelease

[Peter Schmid]

In my option PR c++/5504, a gcc 3.0 regression, is a critical bug
which should be fixed for the upcoming gcc 3.1 release. Otherwise
blitz will not compile on systems with less than 1.2 GB of virtual
memory, for this small example. A full blown program will contain much
more user code requiring even more memory.

gcc 2.95.2 consumes about 100 MB of virtual memory when optimisation is
turned on.

Peter Schmid

Re: GCC 3.1 Prerelease

[Mark Mitchell]

--On Sunday, April 21, 2002 02:35:57 AM +0200 Peter Schmid 
<schmid@snake.iap.physik.tu-darmstadt.de> wrote:

> In my option PR c++/5504, a gcc 3.0 regression, is a critical bug
> which should be fixed for the upcoming gcc 3.1 release. Otherwise
> blitz will not compile on systems with less than 1.2 GB of virtual
> memory, for this small example. A full blown program will contain much
> more user code requiring even more memory.

This is a compile-time performance regression caused by fixing a
correctness bug.  Correctness trumps; if we can't be both efficient
and correct, we should be correct, within reason.  (And here lots of
programs still compile efficiently; some heavily inlined programs are now
taking more memory to compile.)

I don't quite understand Richard's last note on the topic -- but I
understand his conclusion, which is basically that it's not easy to
fix this problem.  It sounds like maybe if the front end were to
promise that there were no gotos in a particular function, this would
improve things, but I'm not sure.

Jason, Richard, what do you think about this?  The only practical
option, beyond the speedups Richard already implemented, is to
revert Jason's correctness patch at this point.

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

Re: GCC 3.1 Prerelease

[Richard Henderson]

On Sat, Apr 20, 2002 at 05:24:15PM -0700, Mark Mitchell wrote:
> It sounds like maybe if the front end were to promise that there
> were no gotos in a particular function, this would improve things,
> but I'm not sure.

Less severe than that.  No gotos within a specific region.  Or
more to the point, binding cleanup code with exception regions
before generating rtl for them rather than after.

> Jason, Richard, what do you think about this?  The only practical
> option, beyond the speedups Richard already implemented, is to
> revert Jason's correctness patch at this point.

I really dislike the idea of reverting the correctness patch.

The most practical solution for people actually using these
sorts of template packages is to not nest the expressions
quite so deeply.  I.e. use

	c = a + b;
	e = c * d;
	g = e + f;

instead of

	g = (a + b) * d + f;

or whatever.


r~

Re: GCC 3.1 Prerelease

[Mark Mitchell]

--On Sunday, April 21, 2002 01:50:47 PM -0700 Richard Henderson 
<rth@redhat.com> wrote:

> On Sat, Apr 20, 2002 at 05:24:15PM -0700, Mark Mitchell wrote:
>> It sounds like maybe if the front end were to promise that there
>> were no gotos in a particular function, this would improve things,
>> but I'm not sure.
>
> Less severe than that.  No gotos within a specific region.  Or
> more to the point, binding cleanup code with exception regions
> before generating rtl for them rather than after.

OK.

>> Jason, Richard, what do you think about this?  The only practical
>> option, beyond the speedups Richard already implemented, is to
>> revert Jason's correctness patch at this point.
>
> I really dislike the idea of reverting the correctness patch.

Me too.

> The most practical solution for people actually using these
> sorts of template packages is to not nest the expressions
> quite so deeply.

In general, that hoses the performance of those packages.  The point
is to do loop fusion and such using the expression-template magic;
less nesting means less loop fusion means worse performance.  Perhaps,
however, they could avoid using *destructors* in these objects; that's
not necessary in many of the situations I'm familiar with.

I'm inclined just to suffer here, but let's see what Jason thinks.

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

Re: GCC 3.1 Prerelease

[Jason Merrill]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

> I'm inclined just to suffer here, but let's see what Jason thinks.

I think I'm inclined to restore the bug on the branch.  The code affected
by the bug (throwing an exception in a destructor) is much less common than
the expression template code; killing compile-time performance for
expression templates will impair 3.1's usefulness much more than failing to
fix a bug which has always been present.

Jason

Re: GCC 3.1 Prerelease

[Mark Mitchell]

--On Tuesday, April 23, 2002 01:43:27 PM +0100 Jason Merrill 
<jason@redhat.com> wrote:

>>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
>
>> I'm inclined just to suffer here, but let's see what Jason thinks.
>
> I think I'm inclined to restore the bug on the branch.

That makes some sense.

OK, let's respect your decision.  Would you please undo your change?

I guess we should keep the PR open -- and high priority -- since keeping
the change on the mainline means we already have a known performance
regression to GCC 3.2.

Thanks,

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

GCC 3.1 Prerelease

[Mark Mitchell]

The GCC 3.1 release is starting to take shape.  Many people have worked
very hard.

I will make GCC 3.1 prerelease tarballs on Monday.

To that end, I would very much like to see if we can get some more of
the open bugs fixed before that point.  (I know that people are already
working on some of these at this point.)

Here is a list of the current high-priority bugs order by category.  I
suspect that some of these (Java bugs, especially) are not really
regressions.  If you know about any of these bugs and know that they are
not regressions, please let me know.

I have deliberately omitted Ada bugs; hopefully they will get fixed,
but they will not block the release in any event.  Similarly for
PR3386 which refers to undocumented target macros.

C
=

PR6300 sparc-sun-solaris2.7 failure in gcc.dg/cpp/charconst.c

C++
===

PR4979 g++ compile fails with "unable to find register to spill"
PR3083 C++ frontend consumes inacceptable amounts of CPU with -O3

Libstdc++
=========

PR5396 ifstream read()'s data multiple times on Solaris
PR4150 Catastrophic performance decrease in C++ code

Java
====

PR6314 gcj -R options conflicts with gcc
PR6066 incorrect error message compiling classpath

Bootstrap
=========

PR4165 gcc 3.0.1 fails to build on linux for sh-coff,sh-hms for language c++
PR3373 make boostrap fails in libjava if --with-gnu-as is used

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

Re: GCC 3.1 Prerelease

[Stan Shebs]

Mark Mitchell wrote:
> 
> PR4165 gcc 3.0.1 fails to build on linux for sh-coff,sh-hms for language c++

Why is this one critical?  The SH isn't even listed as a release
criterion, and sh-coff/hms is kind of an archaic config.  It might
be a fun bit of nostalgia to fix (once upon a time I was one of
ver few people who knew how to work an E7000), but there are a
hundred more important things to do first.

Stan

Re: GCC 3.1 Prerelease

[Mark Mitchell]

--On Saturday, April 20, 2002 01:50:28 PM -0700 Stan Shebs 
<shebs@apple.com> wrote:

> Mark Mitchell wrote:
>>
>> PR4165 gcc 3.0.1 fails to build on linux for sh-coff,sh-hms for language
>> c++
>
> Why is this one critical?  The SH isn't even listed as a release
> criterion, and sh-coff/hms is kind of an archaic config.  It might
> be a fun bit of nostalgia to fix (once upon a time I was one of
> ver few people who knew how to work an E7000), but there are a
> hundred more important things to do first.

Me, I just print out what's in GANTS. :-)

It does look like this PR was never verified as a regression; is there
an SH maintainer who cares to comment?

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

Re: GCC 3.1 Prerelease

[Joel Sherrill]

Stan Shebs wrote:
> 
> Mark Mitchell wrote:
> >
> > PR4165 gcc 3.0.1 fails to build on linux for sh-coff,sh-hms for language c++
> 
> Why is this one critical?  The SH isn't even listed as a release
> criterion, and sh-coff/hms is kind of an archaic config.  It might
> be a fun bit of nostalgia to fix (once upon a time I was one of
> ver few people who knew how to work an E7000), but there are a
> hundred more important things to do first.

Besides the targets sh-coff and sh-elf appear to be a bit healthier
than this PR indicates.  A long way from perfect as these test runs
I made reflect:

sh-elf results for 3.1 on 4/18

	http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00723.html

sh-coff results for 3.1 on 4/18 

	http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00716.html
> Stan

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: GCC 3.1 Prerelease

[Joseph S. Myers]

On Sat, 20 Apr 2002, Mark Mitchell wrote:

> The GCC 3.1 release is starting to take shape.  Many people have worked
> very hard.
> 
> I will make GCC 3.1 prerelease tarballs on Monday.

I think the mainline gcc_release script should be merged to the branch.

Relevant fixes: the mainline script properly generates .bz2 diffs and
generates diffs for Ada.  (However, the mainline script has a stray
reference to Chill that should go away.)

gcc.pot (mainline and branch) should be regenerated before the prerelease,
and the prerelease tarball submitted to the translation project.  This
will save translators from translating Chill messages, if they haven't
already translated them.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.1 Prerelease

[Mark Mitchell]

> Relevant fixes: the mainline script properly generates .bz2 diffs and
> generates diffs for Ada.  (However, the mainline script has a stray
> reference to Chill that should go away.)

I'll do this.

> gcc.pot (mainline and branch) should be regenerated before the prerelease,
> and the prerelease tarball submitted to the translation project.  This
> will save translators from translating Chill messages, if they haven't
> already translated them.

I don't do internationalization.

I'm not really sure it's helpful to give them the prerelease tarball;
we'll soon have a release tarball to send.

In any case, if someone wants to do this, by all means feel free.

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

Re: GCC 3.1 Prerelease

[Jakub Jelinek]

On Sat, Apr 20, 2002 at 12:46:06PM -0700, Mark Mitchell wrote:
> PR6300 sparc-sun-solaris2.7 failure in gcc.dg/cpp/charconst.c

Doesn't look serious enough to be a blocker. There are lots of far more
serious bugs in GNATS IMHO.
This one is about wchar_t x = L'Very long'; generating two warnings instead
of one...

I'd say a blocker on SPARC shall be instead inoperability between
compiler defaulting to 64-bit and compiler defaulting to 32-bit
(the libgcc_s naming problem).

	Jakub

Re: GCC 3.1 Prerelease

[Mark Mitchell]

> I'd say a blocker on SPARC shall be instead inoperability between
> compiler defaulting to 64-bit and compiler defaulting to 32-bit
> (the libgcc_s naming problem).

Submit a PR explaining the problem and send me a pointer to the PR.

My brain is not clever enough to remember everything, sadly.

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

Re: GCC 3.1 Prerelease

[Jakub Jelinek]

On Sat, Apr 20, 2002 at 05:13:26PM -0700, Mark Mitchell wrote:
> > I'd say a blocker on SPARC shall be instead inoperability between
> > compiler defaulting to 64-bit and compiler defaulting to 32-bit
> > (the libgcc_s naming problem).
> 
> Submit a PR explaining the problem and send me a pointer to the PR.

target/6429
Though I'm afraid I won't have time for it until Thursday afternoon.
Should I mark it high priority?

	Jakub

Re: GCC 3.1 Prerelease

[Mark Mitchell]

--On Tuesday, April 23, 2002 12:44:28 PM -0400 Jakub Jelinek 
<jakub@redhat.com> wrote:

> On Sat, Apr 20, 2002 at 05:13:26PM -0700, Mark Mitchell wrote:
>> > I'd say a blocker on SPARC shall be instead inoperability between
>> > compiler defaulting to 64-bit and compiler defaulting to 32-bit
>> > (the libgcc_s naming problem).
>>
>> Submit a PR explaining the problem and send me a pointer to the PR.
>
> target/6429
> Though I'm afraid I won't have time for it until Thursday afternoon.
> Should I mark it high priority?

If it's a regression, yes.

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

Re: GCC 3.1 Prerelease

[Tom Tromey]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

Mark> Here is a list of the current high-priority bugs order by
Mark> category.  I suspect that some of these (Java bugs, especially)
Mark> are not really regressions.

Mark> PR6314 gcj -R options conflicts with gcc

I'm working on a patch.  This isn't a regression per se but letting
this go out unfixed would be irresponsible.

Mark> PR6066 incorrect error message compiling classpath

This is a regression, sort of.  We used to be able to compile
Classpath.  Now Classpath has changed (but is still valid code) and we
can't compile it.  It is a regression in the utility of gcj.

Tom

Re: GCC 3.1 Prerelease

[Mark Mitchell]

> Mark> PR6066 incorrect error message compiling classpath
>
> This is a regression, sort of.  We used to be able to compile
> Classpath.  Now Classpath has changed (but is still valid code) and we
> can't compile it.  It is a regression in the utility of gcj.

Is a fix in progress?

Thanks,

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

Re: GCC 3.1 Prerelease

[David S. Miller]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Sat, 20 Apr 2002 12:46:06 -0700

   Java
   ====
   
   PR6314 gcj -R options conflicts with gcc

Tom Tromey did the fix, but it needs a Java person to approve it.
See the thread starting at:

	http://gcc.gnu.org/ml/gcc-patches/2002-04/msg01167.html

Re: GCC 3.1 Prerelease

[Mark Mitchell]

> Tom Tromey did the fix, but it needs a Java person to approve it.
> See the thread starting at:
>
> 	http://gcc.gnu.org/ml/gcc-patches/2002-04/msg01167.html

Thanks.

You underestimate your own power; you have global write privileges
so you may approve the patch. :-)  I've reviewed it, too, and it
looks OK to me.

Tom, please check this in and close the PR.

Thanks!

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

Re: GCC 3.1 Prerelease

[David S. Miller]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Sat, 20 Apr 2002 20:02:51 -0700

   You underestimate your own power; you have global write privileges
   so you may approve the patch. :-)  I've reviewed it, too, and it
   looks OK to me.
   
   Tom, please check this in and close the PR.

I wanted to give Java maintainers an opportunity to
say "Don't use -P because..."

I do this out of courtesy to the Java people, not because
I don't know what my global write privileges afford me.

Indeed, it is a privilege not a right, and being conscientious
is a part of retaining that privilege.

Re: GCC 3.1 Prerelease

[Per Bothner]

David S. Miller wrote:
> I wanted to give Java maintainers an opportunity to
> say "Don't use -P because..."

And at least two of us have said we'd rather use a
lang format like --resources.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: GCC 3.1 Prerelease

[Tom Tromey]

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

>> I wanted to give Java maintainers an opportunity to
>> say "Don't use -P because..."

Per> And at least two of us have said we'd rather use a
Per> lang format like --resources.

I'm rewriting it to use `--resource'.  I prefer singular over plural,
but perhaps --resource-name is even more appropriate since it is more
accurate.  I'll submit it soon, but probably not today.

I thought Mark was asking about the Classpath bug though.  This bug
has probably been resolved in a different way, at least if a small
patch gets approved.  There's a recent post from Mark Wielaard on the
issue on the java list.

Tom

Re: GCC 3.1 Prerelease

[Mark Mitchell]

> I do this out of courtesy to the Java people, not because
> I don't know what my global write privileges afford me.

:-)

> Indeed, it is a privilege not a right, and being conscientious
> is a part of retaining that privilege.

Certainly true; you perhaps interpreted my comment too seriously.  We
certainly do not want to stomp over one-another's areas of expertise.

It's fine to wait for Per/Alexandre to approve the patch

On the other hand, Tom is an experienced contributor both for Java
and in general; if there's something risky about -P, I'm confident he'd
have noticed it and/or warner about it, and I'm confident that we
can easily change -P to something else, so it's not like it's very
risky to have the patch in the tree.

Tom, use your best judgement.  It's OK to check it in.  If you don't
want to, that's OK too.

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

Re: GCC 3.1 Prerelease

[Alan Modra]

c/6343 causes glibc build failures on powerpc64-linux, and probably
other targets.  Franz Sirl provided a patch in
http://gcc.gnu.org/ml/gcc-patches/2002-04/msg01026.html, which
with the obvious extension to cp/decl.c seems to be the right thing.

c/6344 miscompiles the linux kernel on powerpc64-linux.  I suspect
this one is a generic bug too.  I tried to fix it but quickly
became lost.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: GCC 3.1 Prerelease

[Gerald Pfeifer]

On Sat, 20 Apr 2002, Mark Mitchell wrote:
> PR3083 C++ frontend consumes inacceptable amounts of CPU with -O3

This is a report of mine.  I believe it can be (more or less) closed, but
will do a careful investigation tomorrow and possible Tuesday and provide
an analysis then.

Gerald

Re: GCC 3.1 Prerelease

[Gerald Pfeifer]

On Sun, 21 Apr 2002, Gerald Pfeifer wrote:
>> PR3083 C++ frontend consumes inacceptable amounts of CPU with -O3
> This is a report of mine.  I believe it can be (more or less) closed, but
> will do a careful investigation tomorrow and possible Tuesday and provide
> an analysis then.

As promised, I performed tests comparing GCC 2.95.3, GCC 3.0, GCC 3.0.3,
the 3.1-branch as of yesterday, the 3.1-branch with -finline-limit=800
and 1200, respectively, and the 3.2-branch as of yesterday.

ANALYSIS:

The situation isn't as bad as it used to be, but still release critical.
Compiling the file attached to PR 3083/C++ takes 62.4s with the 3.1-branch
versus 46.9s with GCC 3.0.3 (on a PIII/1000).

Considering not only PR 3083/C++, but the situation in general, it seems
that for template/STL-heavy code with deeply nested structures, GCC 2.95
still is the compiler of choice, especially in terms of code quality.

GCC 3.1 seems to generate equivalent code to GCC 3.0.3 but is measurably
slower.

Current mainline produces slightly better code than 3.0.3 and 3.1 at the
expense of even longer build times, but still does not reach GCC 2.95 on
average.

(Note that the first test above was performed using the same preprocessed
file, while the other tests were performed compiling from source, which
means that GCC 2.95 gets the benefit of a much lighter libstdc++.)

DIAGNOSIS:

Especially considering the runs where I increased -finline-limit, I
strongly suspect our inliner is still quite bad.

DETAILED DATA:

The first table shows the time needed to build DLV
(http://www.dbai.tuwien.ac.at/proj/dlv/), a C++ application that makes
heavy use of STL and has deeply nested template structures, on an
Athlon/1200. It also shows the size of the resulting static binary.

The second table shows DLV running selected benchmarks that exercise
different modules of the system (which is basically equivalent to
evaluating GCC code generation on completely separate applications).

                    | 2.95.3|  3.0  | 3.0.3 |  3.1  |...-800|..-1200|  3.2  |
--------------------+-------+-------+-------+-------+-------+-------+-------+
Build time              4:01   23:54    3:58    4:38    6:37   16:50    5:15
Binary size          4430752 6295044 3948444 3996096 4177344 4597888 4003276

                    | 2.95.3|  3.0  | 3.0.3 |  3.1  |...-800|..-1200|  3.2  |
--------------------+-------+-------+-------+-------+-------+-------+-------+
      STRATCOMP1-ALL|  3.57 | 79.39 | 71.41 | 96.33 | 85.40 | 82.83 | 92.01 |
   STRATCOMP-770.2-Q|  0.73 |  0.93 |  0.90 |  0.95 |  0.98 |  0.87 |  0.93 |
               2QBF1| 19.08 | 27.66 | 22.96 | 22.25 | 19.90 | 18.46 | 20.97 |
          PRIMEIMPL2| 10.74 | 16.39 | 12.92 | 12.90 | 11.74 | 10.29 | 12.35 |
            ANCESTOR|  8.88 |  9.23 |  9.63 |  9.55 | 10.52 |  9.15 |  9.46 |
       3COL-SIMPLEX1|  6.30 |  6.75 |  7.20 |  7.15 |  7.29 |  6.75 |  7.26 |
        3COL-LADDER1| 36.24 | 49.20 | 44.47 | 42.35 | 39.27 | 35.79 | 40.99 |
      3COL-N-LADDER1| 19.81 | 23.25 | 21.27 | 22.60 | 21.11 | 19.99 | 21.32 |
        3COL-RANDOM1| 10.69 | 15.38 | 12.72 | 12.22 | 11.69 | 10.61 | 11.55 |
          HP-RANDOM1| 13.16 | 13.85 | 14.55 | 14.79 | 14.39 | 14.08 | 14.43 |
       HAMCYCLE-FREE|  1.18 |  1.42 |  1.71 |  1.70 |  1.58 |  1.54 |  1.59 |
             DECOMP2| 21.91 | 26.36 | 24.24 | 24.08 | 24.15 | 22.48 | 24.38 |
        BW-P4-Esra-a| 91.71 |102.26 | 97.70 | 99.30 | 95.60 | 92.25 | 96.51 |
        BW-P5-nopush|  6.96 |  7.89 |  7.42 |  7.44 |  7.26 |  7.01 |  7.24 |
       BW-P5-pushbin|  6.20 |  6.99 |  6.52 |  6.48 |  6.30 |  6.04 |  6.31 |
     BW-P5-nopushbin|  1.94 |  2.23 |  2.10 |  2.07 |  2.05 |  1.94 |  2.04 |
              3SAT-1| 32.92 | 47.37 | 37.65 | 38.45 | 35.10 | 30.96 | 36.81 |
   3SAT-1-CONSTRAINT| 17.46 | 27.28 | 21.97 | 20.62 | 18.95 | 17.06 | 19.26 |
        HANOI-Towers|  4.73 |  5.36 |  5.03 |  4.96 |  5.09 |  4.81 |  5.05 |
              RAMSEY|  8.00 |  9.55 |  9.08 |  8.68 |  8.95 |  8.00 |  8.66 |
             CRISTAL| 11.07 | 12.54 | 13.15 | 13.35 | 13.47 | 12.65 | 13.28 |
             HANOI-K| 33.41 | 46.27 | 38.33 | 38.66 | 34.79 | 32.50 | 36.76 |
           21-QUEENS|  9.66 | 13.73 | 10.92 | 10.41 |  9.95 |  9.07 |  9.23 |
   MSTDir[V=13,A=40]| 25.71 | 24.85 | 24.46 | 21.09 | 19.52 | 19.31 | 20.47 |
   MSTDir[V=15,A=40]| 25.81 | 24.88 | 24.47 | 21.15 | 19.61 | 19.39 | 20.52 |
 MSTUndir[V=13,A=40]| 12.86 | 12.86 | 12.82 | 11.45 | 10.53 | 10.40 | 11.04 |
 MSTUndir[V=15,A=40]|214.87 |210.69 |210.63 |188.57 |172.70 |171.26 |182.65 |
         TIMETABLING|  9.63 | 10.58 | 10.74 | 10.62 | 11.78 |  9.98 | 10.80 |
--------------------+-------+-------+-------+-------+-------+-------+-------+
(The STRATCOMP1-ALL regression is probably due to third-party code -- a
SAT solver -- experiencing alignment issues due to dirty programming.)

Re: GCC 3.1 Prerelease

[Mark Mitchell]

--On Tuesday, April 23, 2002 05:22:54 PM +0200 Gerald Pfeifer 
<pfeifer@dbai.tuwien.ac.at> wrote:

> On Sun, 21 Apr 2002, Gerald Pfeifer wrote:
>>> PR3083 C++ frontend consumes inacceptable amounts of CPU with -O3
>> This is a report of mine.  I believe it can be (more or less) closed, but
>> will do a careful investigation tomorrow and possible Tuesday and provide
>> an analysis then.
>
> As promised, I performed tests comparing GCC 2.95.3, GCC 3.0, GCC 3.0.3,
> the 3.1-branch as of yesterday, the 3.1-branch with -finline-limit=800
> and 1200, respectively, and the 3.2-branch as of yesterday.

Thanks very much for doing this.

The good news is that your code compiles and runs.

I don't think we're in a position to do much at this point.  The numbers
look only slightly different from GCC 3.0.x.  There are even some
improvements assuming that smaller numbers in your benchmark table
imply better results.

I agree that we should investigate these issues, but I don't think we
should hold up the release to try to work on them.

Do you agree or disagree?

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

Re: GCC 3.1 Prerelease

[Joe Buck]

Gerald writes:
> > As promised, I performed tests comparing GCC 2.95.3, GCC 3.0, GCC 3.0.3,
> > the 3.1-branch as of yesterday, the 3.1-branch with -finline-limit=800
> > and 1200, respectively, and the 3.2-branch as of yesterday.
> 
> Thanks very much for doing this.
> 
> The good news is that your code compiles and runs.
> 
> I don't think we're in a position to do much at this point.  The numbers
> look only slightly different from GCC 3.0.x.  There are even some
> improvements assuming that smaller numbers in your benchmark table
> imply better results.

It's still a performance regression from 2.95.x, but as you say it looks
like a wash with respect to 3.0.4.  I have other test cases where 3.1 does
about as well as 2.95.x.  Only in very C-like code do we really see
improvements in 3.1.

> I agree that we should investigate these issues, but I don't think we
> should hold up the release to try to work on them.

Any fixes will probably need architectural changes that will need
extensive testing, so it really isn't feasible.

If we're going to do something, I think that we should consider insisting
on performance improvements in 3.2, otherwise we do mandatory schedule
slips for as long as it takes.  There's no point in continuing down the
track we're on: releases that take longer and longer to compile code that
is no better.

(but then didn't we say something like that about 3.1?  Sigh)

I think Gerald's right: the problem seems to be that the new inliner
sucks for some reason.

3.1 does have many bug fixes and C on x86 is faster, so I think it's
releasable (modulo the last few high-priority bugs).

Re: GCC 3.1 Prerelease

[Gerald Pfeifer]

On Tue, 23 Apr 2002, Mark Mitchell wrote:
> I don't think we're in a position to do much at this point.  The numbers
> look only slightly different from GCC 3.0.x.

What most worries me is the following part of my report:

|  Compiling the file attached to PR 3083/C++ takes 62.4s with the 3.1-branch
| versus 46.9s with GCC 3.0.3 (on a PIII/1000).

This is a slowdown by one third or 33% from 3.0.3 to the 3.1-branch!

> I agree that we should investigate these issues, but I don't think we
> should hold up the release to try to work on them.

It's a bit frustrating that the high priority PR with this testcase is
now over 10 months old, but I agree we shouldn't hold up the release
just because of this issue.

It would be nice, though, if someone could have a look to see whether
there's some easy fish to be caught there.

On Tue, 23 Apr 2002, Joe Buck wrote:
> Any fixes will probably need architectural changes that will need
> extensive testing, so it really isn't feasible.

Well, perhaps some of the improvements are not too intrusive and could
be backported in time for 3.1.1 after a period of testing on mainline?

> If we're going to do something, I think that we should consider
> insisting on performance improvements in 3.2, otherwise we do mandatory
> schedule slips for as long as it takes. There's no point in continuing
> down the track we're on: releases that take longer and longer to compile
> code that is no better.

Agreed!  (Though ideally the problem will be attacked much sooner, that
is, before 3.2 branches.)

> I think Gerald's right: [...]

It's kind of relieving to see that I'm not the only experiencing this kind
of problem; sometimes I've been wondering whether I was doing something
stupid...

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: GCC 3.1 Prerelease

[Andreas Schwab]

I have upgraded PR6331 to high priority, it's a regression against 3.0.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."