3.3.4 status, and some questions

3.3.4 status, and some questions

[Joe Buck]

I took a look at bugzilla and a first snapshot of what the release notes
would be like, if we released now, appear below.

I have some questions:

- I successfully built 3.3.3 on an ia64 GNU/Linux box and did not observe
  a bootstrap failure.  Was 13918 something that only a very few people
  observed, or was it common?

- Is 14302 the bug that caused XFree86 4.3 builds to fail on Debian ARM?

- Are there other bugs that the Debian folks have patched in their
  gcc-3.3 that we don't have in the FSF 3_3_branch?  (That's why I'm
  copying you, Matthias).

Ideally I'd like to see Debian sarge be able to come out with a compiler
that is as close to 3.3.4 as possible.  I'd also like us to tighten up
now on what we allow into 3.3.4, as we need to focus on rock-solid
stability.  Every patch has a non-zero probability of introducing some
new bug, so beyond fixing something that blocks the building of a
distribution, we should be close to done now.

------------------------------------------------------------------------
Bootstrap failures

13918 [ia64] bootstrap comparison failure (only affects some users)
14166 [ARM Thumb] GCC-3.3.3 cross build fails with internal compiler error
14348 Cannot bootstrap GCC-3.3.x with GCC-3.5 (experimental)

ICEs

12890 (Java) ICE on compilation of class with throwing method
13635 (C++) ICE in register_specialization for specific order of template
      specialization
14033 (C++) ICE during error recovery: tree check: expected class 't',
      have 'x' (error_mark) in initialize_inlined_parameters, in tree-inline.c
14083 (C++) ICE in conditional expression operator with throw
14289 ICE on (invalid) attempt to declare an array of registers

C and optimization bugs
14327 -O0 -fdefer-pop generates wrong code
14328 GCC generates incorrect debugging enum values (on DWARF platforms)
14381 sched2 moving "may throw" instructions into epilogue

C++ compiler and library
 9941 typeinfo not generated correctly when #pragmas are involved (on
      platforms without weak symbol support)
13907 valid conversion rejected unless -pedantic is set
13932 duplicate warning message for conversion
13944 exception in constructor of a class to be thrown is not caught
14250 switch() does not seem to see operator int() in template class
14409 Compiler accepts invalid function signature for explicit instantiation

x86 (Intel/AMD) specific:
 1532 -O3 generates (obviously) redundant tests and jumps
 6162 ICE with inline assembler in reload_cse_simplify_operands

m68k specific:

 7871 ICE on legal code, global register variables problems

SPARC specific:

10904 [sparc64] invalid (misaligned) FP register at -O2
13058 [sparc64] ICE in reload_cse_simplify_operands

ARM specific:

14302 ICE: error: insn does not satisfy its constraints

s390 specific:
12147 Wrong code with -O2 in context of reload

Other embedded target specific:

11864 [SH] GCC miscompiles the combination of zero extension and test if zero
14209 [cris] Bug in cris.md, shrinking access size of postincrement
14346 [cris] With -fpic/-fPIC, thunks jump through PLT, not directly to
      thunked function
14471 [cris] Workaround for errata regarding multiplication hardware bug

Re: 3.3.4 status, and some questions

[Ian Lance Taylor]

Joe Buck <Joe.Buck@synopsys.COM> writes:

> x86 (Intel/AMD) specific:
>  6162 ICE with inline assembler in reload_cse_simplify_operands

Minor comment: the fix for PR 6162 one is not x86 specific, except in
that the ICE is more likely to happen on a CPU with few available
registers.

Ian

Re: 3.3.4 status, and some questions

[Matthias Klose]

Joe Buck writes:
> I took a look at bugzilla and a first snapshot of what the release notes
> would be like, if we released now, appear below.
> 
> I have some questions:
> 
> - I successfully built 3.3.3 on an ia64 GNU/Linux box and did not observe
>   a bootstrap failure.  Was 13918 something that only a very few people
>   observed, or was it common?

I couldn't reproduce this anymore, and it was reproducible on some
machines only.

> - Is 14302 the bug that caused XFree86 4.3 builds to fail on Debian ARM?

CCed Phil Blundell

> - Are there other bugs that the Debian folks have patched in their
>   gcc-3.3 that we don't have in the FSF 3_3_branch?  (That's why I'm
>   copying you, Matthias).

The debian-gcc subversion repository is currently down, so I copied
the patches applied to the upstream source to
http://people.debian.org/~doko/gcc-patches/. Hope this doesn't get too
off-topic... The patches prefixed with an architecture are tested only
on that architecture.

arm-10730.dpatch:
2003-05-15  Philip Blundell  <philb@gnu.org>

	PR target/10730
	* config/arm/arm.c (adjacent_mem_locations): Reject offsets
	involving invalid constants.

arm12527.dpatch:
2004-01-14  Richard Earnshaw  <rearnsha@arm.com>

	PR bootstrap/12527
	* config.gcc (arm*-*-linux*): Don't include unknown-elf.h in tm_file.
	Move linux-gas.h and linux-elf.h before aout.h.
	* arm/arm.h (INITIALIZE_TRAMPOLINE): Only define if not already.
	* arm/linux-elf.h (SUBTARGET_CPU_DEFAULT): Define.

arm-233633.dpatch:
Phil Blundell:
	Patch for invalid QImode insn resulting from HImode reload on ARMv3

arm-common.dpatch:
Phil Blundell:
	delete ASM_OUTPUT_ALIGNED_COMMON from arm/elf.h, since it outputs
	the alignment in bits not bytes.

arm-gotoff.dpatch:
Phil Blundell:
	use GOTOFF not GOT relocs for .LCn and other local symbols;
	don't use gotoff for non-static functions, even if defined locally

arm-ldm.dpatch:
Phil Blundell:
	try harder to avoid ldm in function epilogues

arm-tune.dpatch:
Phil Blundell:
	ARM patch for default tuning for XScale

libtool-rpath.dpatch:
2003-03-10  Andreas Schwab  <schwab at suse dot de>
	With the introduction of multi-os-directory the libdir specification in
	*.la files have /. appended to $(libdir).  This confuses libtool when it
	tries to find out whether to add -rpath, because it only matches literally
	against sys_lib_dlsearch_path members.  Tested on i386-linux.

m68k-subreg.dpatch:
2003-04-07  Roman Zippel  <zippel@linux-m68k.org>

	* gcc/final.c (alter_subreg): Adjust stack offset for a paradoxical
	SUBREG, when it's pushed on the stack.

m68k-update2.dpatch:
#177840 / PR9812
2003-06-27  James E Wilson  <wilson@tuliptree.org>
	* rtl.h (mem_for_const_double): Delete prototype.
	* varasm.c (mem_for_const_double): Delete function.
	* config/m68k/hp320.h, config/m68k/linux.h, config/m68k/m68kelf.h,
	config/m68k/m68kv4.h, config/m68k/netbsd-elf.h
	(LEGITIMATE_PIC_OPERAND_P): Delete duplicate definitions.
	* config/m68k/m68k.h (LEGITIMATE_CONSTANT_P): Disallow XFmode.
	(LEGITIMATE_PIC_OPERAND_P): Delete CONST_DOUBLE tests.
	* config/m68k/m68k.md (movxf): Add reload_in_progress guard. Add
	comment about confused support for XFmode constants.

m68k-update3.dpatch:
2004-01-15  Andreas Schwab  <schwab@suse.de>
        PR bootstrap/13562
        * config/m68k/m68k.c (output_move_const_into_data_reg): Clear cc
        status for NOTB/NOTW/NEGW methods.

The absence of this patch doesn't result in a bootstrap error.

mips-branch-fix.dpatch:
	Fix #207915 (PR11716).
	Make GCC think that the maximum length of a short branch is
	64K instead of 128K.  It's a big hammer, but it works.

powerpc-pthread-spec.dpatch:
	link libraries with -pthread on powerpc-linux

s390-ifcft.dpatch:
Gerhard Tonn <gt@debian.org>
	backport of ifcvt patch
	see http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01072.html

s390-nonlocal-goto.dpatch:
Gerhard Tonn <gt@debian.org>
	nonlocal goto patch


all other patches are Debian specific configure/build/install patches:
- build bi-arch compilers, defaulting to 32bit
- change cpu defaults for code generation
- debian-hurd and debian-netbsd changes
- turn on -mieee by default for alpha-linux
- some patches to build gpc.
- renaming of info files
- libffi and libjava support for hppa (doesn't break anything else,
  but needs to be submitted for mainline first).

> Ideally I'd like to see Debian sarge be able to come out with a compiler
> that is as close to 3.3.4 as possible.

that will be difficult. see
http://lists.debian.org/debian-devel-announce/2004/debian-devel-announce-200402/msg00009.html
I'll build a new package this weekend, then lets what our release
people think about "Last changes" for another update.

	Matthias

Re: 3.3.4 status, and some questions

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.COM> writes:

| I took a look at bugzilla and a first snapshot of what the release notes
| would be like, if we released now, appear below.
| 
| I have some questions:
| 
| - I successfully built 3.3.3 on an ia64 GNU/Linux box and did not observe
|   a bootstrap failure.

The same here.  Here at the Parasol Labs, we use gcc-3.3.3 internally
(along with gcc-3.5.x).


| Was 13918 something that only a very few people observed, or was it common?

This is a non-blocking issue.   See the excellent explanation by Jim
Wilson.  This is not a PR that would block 3.3.4.


Do you think there is any real urgence to release GCC-3.3.4 before
end of May?

-- Gaby

Re: 3.3.4 status, and some questions

[Andreas Schwab]

Joe Buck <Joe.Buck@synopsys.COM> writes:

> - I successfully built 3.3.3 on an ia64 GNU/Linux box and did not observe
>   a bootstrap failure.  Was 13918 something that only a very few people
>   observed, or was it common?

It seems to be depending very much on memory layout.  I was never been
able to reproduce it during a manual build, only with an automatic
regression tester (which runs in a slightly different environment).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 3.3.4 status, and some questions

[Philip Blundell]

On Fri, 2004-03-12 at 06:38, Matthias Klose wrote:
> > - Is 14302 the bug that caused XFree86 4.3 builds to fail on Debian ARM?
> 
> CCed Phil Blundell

No.  The XFree86 problem was also in GO_IF_LEGITIMATE_ADDRESS, but this
was a different bug.  I don't think we had a PR filed for the XFree86
thing.

p.

Re: 3.3.4 status, and some questions

[Richard Earnshaw]

> On Fri, 2004-03-12 at 06:38, Matthias Klose wrote:
> > > - Is 14302 the bug that caused XFree86 4.3 builds to fail on Debian ARM?
> > 
> > CCed Phil Blundell
> 
> No.  The XFree86 problem was also in GO_IF_LEGITIMATE_ADDRESS, but this
> was a different bug.  I don't think we had a PR filed for the XFree86
> thing.
> 
> p.
> 
> 

I don't think there is a PR for it since the code in question does not 
provoke the bug on a vanilla FSF build.

In fact, the patch for that bug hasn't been installed on the 3.3 branch 
yet.  It needs a back-port of this change.  However, it's not completely 
trivial since the code in question was a macro in arm.h for 3.3 whereas 
it's now a function in arm.c.


2004-02-25  Richard Earnshaw  <rearnsha@arm.com>

        * arm.c (arm_legitimate_index_p): For QImode the range of an offset
        is -4095...+4095 inclusive.

Phil, were you going to commit the back-port you had done?

R.

Re: 3.3.4 status, and some questions

[Philip Blundell]

On Fri, 2004-03-12 at 12:08, Richard Earnshaw wrote:
> Phil, were you going to commit the back-port you had done?

Yep, I can do that.

p.

Re: 3.3.4 status, and some questions

[Gerhard Tonn]

Matthias Klose wrote:

> s390-ifcft.dpatch:
> Gerhard Tonn <gt@debian.org>
> 	backport of ifcvt patch
> 	see http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01072.html
> 
> s390-nonlocal-goto.dpatch:
> Gerhard Tonn <gt@debian.org>
> 	nonlocal goto patch
> 
> 

These two patches are not needed any more for gcc-3.4.

Regards,
Gerhard

Re: 3.3.4 status, and some questions

[Joe Buck]

On Fri, Mar 12, 2004 at 10:44:10AM +0000, Philip Blundell wrote:
> On Fri, 2004-03-12 at 06:38, Matthias Klose wrote:
> > > - Is 14302 the bug that caused XFree86 4.3 builds to fail on Debian ARM?
> > 
> > CCed Phil Blundell
> 
> No.  The XFree86 problem was also in GO_IF_LEGITIMATE_ADDRESS, but this
> was a different bug.  I don't think we had a PR filed for the XFree86
> thing.

Is the bug fixed in the gcc-3.3 CVS branch?  This one was serious and
visible enough that we should have a PR for it (so there's a referenceable
bug description for the 3.3.4 release notes when they come out).

Re: 3.3.4 status, and some questions

[Phil Blundell]

on Fri, Mar 12, 2004 at 08:46:36AM -0800, Joe Buck wrote:
> Is the bug fixed in the gcc-3.3 CVS branch?  This one was serious and
> visible enough that we should have a PR for it (so there's a referenceable
> bug description for the 3.3.4 release notes when they come out).

Not yet.  I think Richard has already fixed this in the HEAD, and he
suggested that I should check in a backport of his patch to the 3.3
branch.  I'll do that later today.

p.

Re: 3.3.4 status, and some questions

[Joe Buck]

On Fri, Mar 12, 2004 at 04:50:13PM +0000, Phil Blundell wrote:
> on Fri, Mar 12, 2004 at 08:46:36AM -0800, Joe Buck wrote:
> > Is the bug fixed in the gcc-3.3 CVS branch?  This one was serious and
> > visible enough that we should have a PR for it (so there's a referenceable
> > bug description for the 3.3.4 release notes when they come out).
> 
> Not yet.  I think Richard has already fixed this in the HEAD, and he
> suggested that I should check in a backport of his patch to the 3.3
> branch.  I'll do that later today.

OK.  I just filed it as target/14558.  Could you please mark your
backport as closing this bug?

Re: 3.3.4 status, and some questions

[Phil Blundell]

on Fri, Mar 12, 2004 at 07:38:54AM +0100, Matthias Klose wrote:
> arm-10730.dpatch:
> 2003-05-15  Philip Blundell  <philb@gnu.org>
> 
> 	PR target/10730
> 	* config/arm/arm.c (adjacent_mem_locations): Reject offsets
> 	involving invalid constants.

I guess this one should also be applied to the branch.  I'll take care
of that.

p.

Re: 3.3.4 status, and some questions

[Joe Buck]

On Fri, Mar 12, 2004 at 12:08:30PM +0000, Richard Earnshaw wrote:
> > On Fri, 2004-03-12 at 06:38, Matthias Klose wrote:
> > > > - Is 14302 the bug that caused XFree86 4.3 builds to fail on Debian ARM?
> > > 
> > > CCed Phil Blundell
> > 
> > No.  The XFree86 problem was also in GO_IF_LEGITIMATE_ADDRESS, but this
> > was a different bug.  I don't think we had a PR filed for the XFree86
> > thing.
> > 
> > p.
> > 
> > 
> 
> I don't think there is a PR for it since the code in question does not 
> provoke the bug on a vanilla FSF build.

Now I'm confused.  If the bug is not present in 3.3.3, then what is there
to backport?  Or are you saying that the bug is present, but that this
particular testcase doesn't tweak the bug because of some other difference
between Debian's gcc and ours?

If this is the case, then this is yet another argument for my goal of
getting the Debian and FSF gcc's to be as identical as possible, so that
both will be as reliable as possible.  If only one side does changes,
then those changes get less testing (especially on less common platforms).

> In fact, the patch for that bug hasn't been installed on the 3.3 branch 
> yet.  It needs a back-port of this change.  However, it's not completely 
> trivial since the code in question was a macro in arm.h for 3.3 whereas 
> it's now a function in arm.c.
> 
> 
> 2004-02-25  Richard Earnshaw  <rearnsha@arm.com>
> 
>         * arm.c (arm_legitimate_index_p): For QImode the range of an offset
>         is -4095...+4095 inclusive.
> 
> Phil, were you going to commit the back-port you had done?
> 
> R.

Re: 3.3.4 status, and some questions

[Richard Earnshaw]

> > I don't think there is a PR for it since the code in question does not 
> > provoke the bug on a vanilla FSF build.
> 
> Now I'm confused.  If the bug is not present in 3.3.3, then what is there
> to backport? 

The bug is present, by inspection.

> Or are you saying that the bug is present, but that this
> particular testcase doesn't tweak the bug because of some other difference
> between Debian's gcc and ours?

That seems to be the case.

R.

Re: 3.3.4 status, and some questions

[Hans-Peter Nilsson]

On Thu, 11 Mar 2004, Joe Buck wrote:
> Other embedded target specific:
>
> 11864 [SH] GCC miscompiles the combination of zero extension and test if zero
> 14209 [cris] Bug in cris.md, shrinking access size of postincrement
...

Nit: it's CRIS, not cris.  Alternatively, spell
SH (et al) as sh in your table; either way would be ok with me.

It's only lower-case when referring to the GNU
triple-that-is-4tuple.  And supposedly in the MAINTAINERS file
for gnu-triple-related reasons.

Patches to fix any existing inconsistencies for MMIX and CRIS
are pre-approved. ;-)  (And would IMHO be "obvious" for other platforms.)

brgds, H-P

Re: 3.3.4 status, and some questions

[Jim Wilson]

Joe Buck wrote:
> 13918 [ia64] bootstrap comparison failure (only affects some users)

This was fixed when Andreas checked in a sched-ebb.c patch on the 
gcc-3.3 branch.  The same patch could be added to the gcc-3.4 branch if 
necessary.  This is fixed differently on mainline, with a number of 
cselib/alias/etc patches.

This is a memory corruption problem.  I believe it depends on the 
environment size, so only people with certain environment sizes can 
reproduce it.  I never tried testing this theory.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com