GCC-3.3.4 status report

GCC-3.3.4 status report

[Gabriel Dos Reis]

Hi,

  There are 28 PRs  open for GCC-3.3.4.  Among them only 8 are
considered GCC-3.3.4 regressions only; the remaining PRs are common with
3.4.x and mainline.  The hottest regressions for 3.3.4 are

  rtl-optimization/11841
  rtl-optimization/13653

Eric Botcazou has a proposed fix for 11841.

There are another couple of patches that I approved and are not yet
applied. 

The release date is still set to 2004-05-31.

I'll make a 3.3.4 prerelease tarballs in a few hours.

-- Gaby

Re: GCC-3.3.4 status report

[Giovanni Bajo]

Gabriel Dos Reis wrote:

> The release date is still set to 2004-05-31.
> I'll make a 3.3.4 prerelease tarballs in a few hours.

What are the plans for the 3.3 branch, after 3.3.4 is out?

Giovanni Bajo

Re: GCC-3.3.4 status report

[Gabriel Dos Reis]

"Giovanni Bajo" <giovannibajo@libero.it> writes:

| Gabriel Dos Reis wrote:
| 
| > The release date is still set to 2004-05-31.
| > I'll make a 3.3.4 prerelease tarballs in a few hours.
| 
| What are the plans for the 3.3 branch, after 3.3.4 is out?

It will depend on the GCC user community and plans for 3.5.0 or 4.0.0.
But, if GCC-3.3.5 should happen, it would be probably in 4 or 6 months.

-- Gaby

Re: GCC-3.3.4 status report

[Gabriel Dos Reis]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

| Hi,
| 
|   There are 28 PRs  open for GCC-3.3.4.  Among them only 8 are
| considered GCC-3.3.4 regressions only; the remaining PRs are common with
| 3.4.x and mainline.  The hottest regressions for 3.3.4 are
| 
|   rtl-optimization/11841
|   rtl-optimization/13653
| 
| Eric Botcazou has a proposed fix for 11841.

Eric checked in his proposed fix.

Now, the only hot regression is 13653.  My feeling is that we probably
won't fix it in time for 3.3.4.  For the records, this is a long
standing regression since 3.3.0.

Overall, I think the 3.3.4 compiler has been made better than previous
3.3.x releases.  It also has entered a stage where it is stable.  

After 3.3.4, I'm going to make more releases out of the gcc-3_3-branch.
Given the stability we've reached, I'll be applying stricter rules
than I used for 3.3.3 and 3.3.4 (for the record, the previous strategy
enabled us to attain the current good shape).

I'll make the  second (and hopefully the final) prerelease tarballs
tonight.  Then, the branch would be frozen until actual release,
planned for 2004-05-31.

Thanks,

-- Gaby

GCC-3.3.4 Status Report

[Gabriel Dos Reis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

Hi,

   Significant improvements have been made since last report and the 
first prerelease, thanks to the usual suspects: John David Anglin,
Éric Botcazou, Joe Buck, Richard Guenther, Richard Henderson and our
bugmasters who have been very helpful in identifying patches that fixed
problems.

  RTH had fixed the boostrapping problem Joe reported.  Éric has
a proposed patch for the long standing regression on POOMA

        rtl-optimization/13653

Combined with Dave's proposed patch to fix GC issues, GCC-3.3.4-pre is
reported as regression-free on POOMA (R.Guenther).

  Éric has identified a regression on four compilers -- namely 3.3.3,
3.3.4-pre, 3.4.0 and 3.4.1-pre -- when compiling the GNU/Linux kernel
on SPARCs.

I'm waiting for feedback from Jeff, R.Kenner and RTH about Éric's patch.
Then, I'll make a second and final prerelease.

Thanks,

-- Gaby
 
  

Re: GCC-3.3.4 status report

[Volker Reichelt]

On 27 Apr, Gabriel Dos Reis wrote:
> Volker Reichelt <reichelt@igpm.rwth-aachen.de> writes:
> 
> | Hi Gaby,
> | 
> | you wrote:
> | 
> | >   There are 25 open PRs targetted for 3.3.4.  Of course, I don't
> | > expect all of them to be fixed before the release.  The most serious
> | > PRs are the regressions:
> | >
> | >   optimization/13653
> | 
> | On the other hand you closed PR 11841 today which is probably the same
> | bug as PR 13653, but it sports a short testcase (whereas it seems to be
> 
> The audit trail of 11841 seems very confused to the point where it is
> not obvious that it is the same.

Good point. I just added a (hopefully less confusing) summary to the
audit trail, reopened the PR and marked PR 13653 as dependent on it.

> You may mark it as related to 13653.

Regards,
Volker

Re: GCC-3.3.4 status report

[Gabriel Dos Reis]

Volker Reichelt <reichelt@igpm.rwth-aachen.de> writes:

| On 27 Apr, Gabriel Dos Reis wrote:
| > Volker Reichelt <reichelt@igpm.rwth-aachen.de> writes:
| > 
| > | Hi Gaby,
| > | 
| > | you wrote:
| > | 
| > | >   There are 25 open PRs targetted for 3.3.4.  Of course, I don't
| > | > expect all of them to be fixed before the release.  The most serious
| > | > PRs are the regressions:
| > | >
| > | >   optimization/13653
| > | 
| > | On the other hand you closed PR 11841 today which is probably the same
| > | bug as PR 13653, but it sports a short testcase (whereas it seems to be
| > 
| > The audit trail of 11841 seems very confused to the point where it is
| > not obvious that it is the same.
| 
| Good point. I just added a (hopefully less confusing) summary to the
| audit trail, reopened the PR and marked PR 13653 as dependent on it.

Thanks!

-- Gaby

Re: GCC-3.3.4 status report

[Volker Reichelt]

Hi Gaby,

you wrote:

>   There are 25 open PRs targetted for 3.3.4.  Of course, I don't
> expect all of them to be fixed before the release.  The most serious
> PRs are the regressions:
>
>   optimization/13653

On the other hand you closed PR 11841 today which is probably the same
bug as PR 13653, but it sports a short testcase (whereas it seems to be
impossible to cut down the POOMA testcase in PR 13653).

So I'd suggest reopening PR 11841 and fixing that one before tackling
PR 13653.

Regards,
Volker

Re: GCC-3.3.4 status report

[Gabriel Dos Reis]

Volker Reichelt <reichelt@igpm.rwth-aachen.de> writes:

| Hi Gaby,
| 
| you wrote:
| 
| >   There are 25 open PRs targetted for 3.3.4.  Of course, I don't
| > expect all of them to be fixed before the release.  The most serious
| > PRs are the regressions:
| >
| >   optimization/13653
| 
| On the other hand you closed PR 11841 today which is probably the same
| bug as PR 13653, but it sports a short testcase (whereas it seems to be

The audit trail of 11841 seems very confused to the point where it is
not obvious that it is the same.  You may mark it as related to
13653.


| impossible to cut down the POOMA testcase in PR 13653).
| 
| So I'd suggest reopening PR 11841 and fixing that one before tackling
| PR 13653.
| 
| Regards,
| Volker
| 
| 
| 

-- 
                                                       Gabriel Dos Reis 
                                           gdr@integrable-solutions.net

GCC-3.3.4 status report

[Gabriel Dos Reis]

Hi,

  There are 25 open PRs targetted for 3.3.4.  Of course, I don't
expect all of them to be fixed before the release.  The most serious
PRs are the regressions:

  optimization/13653
  c++/14724
  target/14966
  middle-end/15054

  I have proposed patches for 4 PRs that are on their ways on being
tested.  Effective today, only real regression fixes will be applied
to gcc-3_3-branch and they need my approval.  If you have a pending
patch that did not get  reviewed, please let me know.
  For our bugmasters, I would say that new PRs that are serious
regressions should be kept, anything else should be closed as
won't fix  for 3.3.x.  If you're undecided on a specific case, please
let me know (put me in CC:) 

  Release is still scheduled for May 31.

Thanks,

-- Gaby

Re: GCC-3.3.4 status report

[Giovanni Bajo]

Gabriel Dos Reis wrote:

>   c++/14724

A straightforward backport of Mark's patch to decl.c (which fixed this in
mainline and 3.4) seems possible and sufficient to resolve this issue. Have you
already looked into this and decided it was not the correct fix?

Giovanni Bajo

Re: GCC-3.3.4 status report

[Gabriel Dos Reis]

"Giovanni Bajo" <giovannibajo@libero.it> writes:

| Gabriel Dos Reis wrote:
| 
| >   c++/14724
| 
| A straightforward backport of Mark's patch to decl.c (which fixed this in
| mainline and 3.4) seems possible and sufficient to resolve this issue. Have you
| already looked into this and decided it was not the correct fix?


It is one of the four PRs 

    I have proposed patches for 4 PRs that are on their ways on being
    tested.

-- Gaby

Re: GCC-3.3.4 status report

[Matthias Klose]

Gabriel Dos Reis writes:
> 
> Hi,
> 
>   There are 25 open PRs targetted for 3.3.4.  Of course, I don't
> expect all of them to be fixed before the release.  The most serious
> PRs are the regressions:

[...]

Two more:

- the branch currently doesn't bootstrap on sparc-linux. bootstrap
  with the patch attached succeeded. It's fixed in 3.4 and 3.3-rhl-branch.
  Patch by Jakub.

- PR14235 is a regression against gcc-2.95 at least on m68k-linux.
  bootstrapped on *-linux, found in the 3.3-rhl-branch as
  well. Checked in by Jakub on the 3.3-rhl-branch.

Both patches sent offline to you as well. Ok to checkin?

	Matthias


2004-04-01  Jakub Jelinek  <jakub@redhat.com>
 
	* config/sparc/sparc.h (FLOATDITF2_LIBCALL, FIX_TRUNCTFDI2_LIBCALL,
	FIXUNS_TRUNCTFDI2_LIBCALL): Define.
	(INIT_TARGET_OPTABS): If DITF_CONVERSION_LIBFUNCS, initialize
	DI <-> TF libfuncs for TARGET_ARCH32.
	(DITF_CONVERSION_LIBFUNCS): Define to 0.
	* config/sparc/linux.h (DITF_CONVERSION_LIBFUNCS): Redefine to 1.
	* config/sparc/linux64.h (DITF_CONVERSION_LIBFUNCS): Redefine to 1.
	* config.gcc (sparc-*-linux*): Revert 2004-03-25 change.
	* config/sparc/t-linux64 (TARGET_LIBGCC2_CFLAGS): Likewise.
	* config/sparc/t-linux: Removed.

--- gcc/config/sparc/t-linux64.jj	2004-03-25 23:34:49.000000000 +0100
+++ gcc/config/sparc/t-linux64	2004-04-01 18:32:10.222310746 +0200
@@ -17,7 +17,3 @@ SHLIB_MAPFILES = $(srcdir)/libgcc-std.ve
 CRTSTUFF_T_CFLAGS = `if test x$$($(GCC_FOR_TARGET) $(MULTILIB_CFLAGS) \
 				 -print-multi-os-directory) \
 			= x../lib64; then echo -mcmodel=medany; fi`
-
-# Compile libgcc2.a with pic and for -m32 also IEEE quad long double.
-# -m64 implies -mlong-double-128, so this is no change for 64-bit.
-TARGET_LIBGCC2_CFLAGS = -fPIC -mlong-double-128
--- gcc/config/sparc/sparc.h.jj	2004-03-08 14:24:36.000000000 +0100
+++ gcc/config/sparc/sparc.h	2004-04-01 18:31:20.341250081 +0200
@@ -2586,10 +2586,18 @@ do {                                    
 #define LTTF2_LIBCALL "_Q_flt"
 #define LETF2_LIBCALL "_Q_fle"
 
+/* These functions were added in SCD 2.3, so not necessarily all targets
+   support them.  */
+#define FLOATDITF2_LIBCALL "_Q_lltoq"
+#define FIX_TRUNCTFDI2_LIBCALL "_Q_qtoll"
+#define FIXUNS_TRUNCTFDI2_LIBCALL "_Q_qtoull"
+
+#define DITF_CONVERSION_LIBFUNCS	0
+
 /* Assume by default that the _Qp_* 64-bit libcalls are implemented such
    that the inputs are fully consumed before the output memory is clobbered.  */
 
-#define TARGET_BUGGY_QP_LIB	0
+#define TARGET_BUGGY_QP_LIB		0
 
 /* We can define the TFmode sqrt optab only if TARGET_FPU.  This is because
    with soft-float, the SFmode and DFmode sqrt instructions will be absent,
@@ -2623,6 +2631,13 @@ do {                                    
 	fixtfsi_libfunc = init_one_libfunc (FIX_TRUNCTFSI2_LIBCALL);	\
 	fixunstfsi_libfunc						\
 	  = init_one_libfunc (FIXUNS_TRUNCTFSI2_LIBCALL);		\
+	if (DITF_CONVERSION_LIBFUNCS)					\
+	  {								\
+	    floatditf_libfunc = init_one_libfunc (FLOATDITF2_LIBCALL);	\
+	    fixtfdi_libfunc = init_one_libfunc (FIX_TRUNCTFDI2_LIBCALL);\
+	    fixunstfdi_libfunc						\
+	      = init_one_libfunc (FIXUNS_TRUNCTFDI2_LIBCALL);		\
+	  }								\
 	if (TARGET_FPU)							\
 	  sqrt_optab->handlers[(int) TFmode].libfunc			\
 	    = init_one_libfunc ("_Q_sqrt");				\
--- gcc/config/sparc/linux.h.jj	2003-12-02 17:52:35.000000000 +0100
+++ gcc/config/sparc/linux.h	2004-04-01 18:31:20.358247035 +0200
@@ -245,6 +245,9 @@ do {									\
 #define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 64
 #endif
 
+#undef DITF_CONVERSION_LIBFUNCS
+#define DITF_CONVERSION_LIBFUNCS       1
+
 #if !defined(USE_GNULIBC_1) && defined(HAVE_LD_EH_FRAME_HDR)
 #define LINK_EH_SPEC "%{!static:--eh-frame-hdr} "
 #endif
--- gcc/config/sparc/t-linux.jj	2004-03-25 23:34:49.000000000 +0100
+++ gcc/config/sparc/t-linux	2004-04-01 18:32:01.394892734 +0200
@@ -1,2 +0,0 @@
-# Compile libgcc2.a with pic and IEEE quad long double.
-TARGET_LIBGCC2_CFLAGS = -fPIC -mlong-double-128
--- gcc/config/sparc/linux64.h.jj	2003-12-02 17:52:35.000000000 +0100
+++ gcc/config/sparc/linux64.h	2004-04-01 18:31:20.359246856 +0200
@@ -308,6 +308,9 @@ do {									\
 
 /* #define DWARF_OFFSET_SIZE PTR_SIZE */
 
+#undef DITF_CONVERSION_LIBFUNCS
+#define DITF_CONVERSION_LIBFUNCS       1
+
 #if defined(HAVE_LD_EH_FRAME_HDR)
 #define LINK_EH_SPEC "%{!static:--eh-frame-hdr} "
 #endif
--- gcc/config.gcc.jj	2004-04-01 18:14:40.000000000 +0200
+++ gcc/config.gcc	2004-04-01 18:32:29.049936590 +0200
@@ -2439,7 +2439,7 @@ sparc-*-linux*libc1*)	# SPARC's running 
 	;;
 sparc-*-linux*)		# SPARC's running GNU/Linux, libc6
 	tm_file="${tm_file} dbxelf.h elfos.h svr4.h sparc/sysv4.h sparc/linux.h"
-	tmake_file="t-slibgcc-elf-ver t-linux sparc/t-linux sparc/t-crtfm"
+	tmake_file="t-slibgcc-elf-ver t-linux sparc/t-crtfm"
 	;;
 sparc-*-lynxos*)
 	if test x$gas = xyes

	Jakub

Re: GCC-3.3.4 status report

[Gabriel Dos Reis]

Matthias Klose <doko@cs.tu-berlin.de> writes:

| Gabriel Dos Reis writes:
| > 
| > Hi,
| > 
| >   There are 25 open PRs targetted for 3.3.4.  Of course, I don't
| > expect all of them to be fixed before the release.  The most serious
| > PRs are the regressions:
| 
| [...]
| 
| Two more:
| 
| - the branch currently doesn't bootstrap on sparc-linux. bootstrap
|   with the patch attached succeeded. It's fixed in 3.4 and 3.3-rhl-branch.
|   Patch by Jakub.
| 
| - PR14235 is a regression against gcc-2.95 at least on m68k-linux.
|   bootstrapped on *-linux, found in the 3.3-rhl-branch as
|   well. Checked in by Jakub on the 3.3-rhl-branch.
| 
| Both patches sent offline to you as well. Ok to checkin?

Yes; thanks for having tracked those.

-- Gaby