* Release 2.21 (ready ?)
@ 2010-11-19 11:45 Tristan Gingold
2010-11-19 16:11 ` Doug Kwan (關振德)
` (2 more replies)
0 siblings, 3 replies; 40+ messages in thread
From: Tristan Gingold @ 2010-11-19 11:45 UTC (permalink / raw)
To: binutils
Hi,
I do not plan to make the release today, but it looks like I can now do it at anytime: nobody currently expect to backport a patch.
If I am wrong, don't forget to tell me.
Tristan.
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: Release 2.21 (ready ?) 2010-11-19 11:45 Release 2.21 (ready ?) Tristan Gingold @ 2010-11-19 16:11 ` Doug Kwan (關振德) 2010-11-20 0:02 ` Ian Lance Taylor 2010-11-19 17:10 ` Joel Sherrill 2010-11-23 16:32 ` Release 2.21 - Pre tests Tristan Gingold 2 siblings, 1 reply; 40+ messages in thread From: Doug Kwan (關振德) @ 2010-11-19 16:11 UTC (permalink / raw) To: Tristan Gingold; +Cc: binutils Do you have another snapshot with all back ported patches? I would like to run the regression tests for gold on x86 and ARM to verify that there is no failure. Other people might want to do that too. -Doug On Fri, Nov 19, 2010 at 3:45 AM, Tristan Gingold <gingold@adacore.com> wrote: > Hi, > > I do not plan to make the release today, but it looks like I can now do it at anytime: nobody currently expect to backport a patch. > If I am wrong, don't forget to tell me. > > Tristan. > > ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 (ready ?) 2010-11-19 16:11 ` Doug Kwan (關振德) @ 2010-11-20 0:02 ` Ian Lance Taylor 0 siblings, 0 replies; 40+ messages in thread From: Ian Lance Taylor @ 2010-11-20 0:02 UTC (permalink / raw) To: Doug Kwan (關振德); +Cc: Tristan Gingold, binutils "Doug Kwan (關振德)" <dougkwan@google.com> writes: > Do you have another snapshot with all back ported patches? I would > like to run the regression tests for gold on x86 and ARM to verify > that there is no failure. Other people might want to do that too. You should be able to check out the release branch via cvs co -r binutils-2_21-branch binutils Ian ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 (ready ?) 2010-11-19 11:45 Release 2.21 (ready ?) Tristan Gingold 2010-11-19 16:11 ` Doug Kwan (關振德) @ 2010-11-19 17:10 ` Joel Sherrill 2010-11-23 16:32 ` Release 2.21 - Pre tests Tristan Gingold 2 siblings, 0 replies; 40+ messages in thread From: Joel Sherrill @ 2010-11-19 17:10 UTC (permalink / raw) To: Tristan Gingold; +Cc: binutils, Ralf Corsepius On 11/19/2010 05:45 AM, Tristan Gingold wrote: > Hi, > > I do not plan to make the release today, but it looks like I can now do it at anytime: nobody currently expect to backport a patch. > If I am wrong, don't forget to tell me. I tried to reply earlier from my phone but don't know if it got out. We have a regression on arm-rtems ld which turned up when Ralf built tool RPMs using 2.20.90. I just prepared a reproducible test case with objects. The PR is: http://sourceware.org/bugzilla/show_bug.cgi?id=12242 There is a link to a tarball with the objects, libraries, and a "doit" script to reproduce the error just using arm-rtems-ld. Thanks. > Tristan. > -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherrill@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Release 2.21 - Pre tests 2010-11-19 11:45 Release 2.21 (ready ?) Tristan Gingold 2010-11-19 16:11 ` Doug Kwan (關振德) 2010-11-19 17:10 ` Joel Sherrill @ 2010-11-23 16:32 ` Tristan Gingold 2010-11-23 18:54 ` Matthias Klose ` (3 more replies) 2 siblings, 4 replies; 40+ messages in thread From: Tristan Gingold @ 2010-11-23 16:32 UTC (permalink / raw) To: binutils Hi, here is the result of a first pre-test. I still plan to update the target list. Two comments: 1) are the arm-eabi failures expected ? 2) I wasn't able to build gold with the compilers I used (gcc 4.1.2 from RH or gcc 4.1.0 from SUSE) Tristan. alpha-linux: OK arc-elf: OK arm-eabi: FAIL: R_ARM_THM_JUMP24 Relocation veneers: Long arm-eabi: FAIL: R_ARM_THM_JUMP24 Relocation veneers: Short 1 arm-eabi: FAIL: R_ARM_THM_JUMP24 Relocation veneers: Short 2 arm-linux-gnueabi: OK avr: OK bfin-elf: OK cr16-elf: OK crx-elf: OK d10v-elf: OK frv-elf: FAIL: FRV uClinux PIC relocs to weak undefined symbols, pie linking frv-elf: FAIL: FRV uClinux PIC relocs to weak undefined symbols, shared linking h8300-elf: OK hppa-linux-gnu: OK i686-pc-cygwin: OK i686-pc-linux-gnu: OK ia64-linux: OK m32c-elf: OK m32r-elf: OK m68k-elf: OK mcore-elf: OK mep-elf: OK mingw32-pe: OK mips-elf: FAIL: --localize-hidden test 1 mips-elf: FAIL: Global calls from mips16 mips-elf: FAIL: MIPS eh-frame 3 mips-elf: FAIL: MIPS eh-frame 4 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-00 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-01 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-02 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-03 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-04 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-05 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-10 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-11 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-12 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-13 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-14 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-15 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-20 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-21 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-22 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-23 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-24 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-25 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-30 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-31 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-32 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-33 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-34 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-35 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-40 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-41 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-42 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-43 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-44 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-45 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-51 mips-linux: OK mips64-elf: FAIL: --localize-hidden test 1 mips64-elf: FAIL: Global calls from mips16 mips64-elf: FAIL: MIPS eh-frame 3 mips64-elf: FAIL: MIPS eh-frame 4 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-00 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-01 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-02 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-03 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-04 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-05 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-10 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-11 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-12 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-13 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-14 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-15 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-20 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-21 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-22 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-23 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-24 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-25 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-30 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-31 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-32 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-33 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-34 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-35 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-40 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-41 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-42 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-43 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-44 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-45 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-51 mn10300-elf: OK msp430-elf: OK powerpc-elf: OK powerpc64-elf: OK rs6000-ibm-aix6: OK s390-linux: OK score-elf: FAIL: gas/score/branch_32 score-elf: FAIL: gas/score/branch_32-lt score-elf: FAIL: ld-elf/orphan4 sh4-elf: OK sh64-elf: OK sparc-elf: OK sparc64-elf: OK spu-elf: OK tic4x-coff: FAIL: .strings tests tic4x-coff: FAIL: bad byte directive tic4x-coff: FAIL: include-1 tic4x-coff: FAIL: ld-scripts/data tic4x-coff: FAIL: ld-scripts/size-1 tic54x-coff: FAIL: -l: test tic54x-coff: FAIL: bad byte directive tic54x-coff: FAIL: c54x cons tests tic54x-coff: FAIL: c54x cons tests, w/extended addressing tic54x-coff: FAIL: c54x field directive tic54x-coff: FAIL: c54x set/equ directive tic54x-coff: FAIL: c54x subsyms tic54x-coff: FAIL: include-1 tic54x-coff: FAIL: ld-scripts/data tic54x-coff: FAIL: ld-scripts/default-script1 tic54x-coff: FAIL: ld-scripts/default-script2 tic54x-coff: FAIL: ld-scripts/default-script3 tic54x-coff: FAIL: ld-scripts/default-script4 tic54x-coff: FAIL: ld-scripts/empty-address-1 tic54x-coff: FAIL: ld-scripts/empty-address-2a tic54x-coff: FAIL: ld-scripts/empty-address-2b tic54x-coff: FAIL: ld-scripts/provide-1 tic54x-coff: FAIL: ld-scripts/provide-2 tic54x-coff: FAIL: ld-scripts/size-1 v850-elf: OK vax-netbsdelf: OK x86_64-pc-linux-gnu: OK x86_64-w64-mingw32: OK xstormy16-elf: OK xtensa-elf: OK ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-23 16:32 ` Release 2.21 - Pre tests Tristan Gingold @ 2010-11-23 18:54 ` Matthias Klose 2010-11-24 9:28 ` Richard Sandiford 2010-11-23 21:04 ` Ian Lance Taylor ` (2 subsequent siblings) 3 siblings, 1 reply; 40+ messages in thread From: Matthias Klose @ 2010-11-23 18:54 UTC (permalink / raw) To: Tristan Gingold; +Cc: binutils On 23.11.2010 17:32, Tristan Gingold wrote: > Hi, > > here is the result of a first pre-test. I still plan to update the target list. > > Two comments: > > 1) are the arm-eabi failures expected ? I see these too, these seem to be introduced after 20101028. > 2) I wasn't able to build gold with the compilers I used (gcc 4.1.2 from RH or gcc 4.1.0 from SUSE) the gold builds did succeed with 4.4 and 4.5. Looking at https://buildd.debian.org/status/package.php?p=binutils&suite=experimental afaics these are not regressions compared to 2.20.1 alpha-linux: Running /build/buildd-binutils_2.20.90.20101121-1-alpha-Je8ajU/binutils-2.20.90.20101121/ld/testsuite/ld-elf/shared.exp ... FAIL: Build libpr9676-4a.so FAIL: Build libpr9679.so Running /build/buildd-binutils_2.20.90.20101121-1-alpha-Je8ajU/binutils-2.20.90.20101121/ld/testsuite/ld-elfvers/vers.exp ... FAIL: vers24a FAIL: vers24b FAIL: vers24c FAIL: vers30 FAIL: vers31 Running /build/buildd-binutils_2.20.90.20101121-1-alpha-Je8ajU/binutils-2.20.90.20101121/ld/testsuite/ld-plugin/plugin.exp ... FAIL: plugin claimfile lost symbol x86_64-linux-gnu: ok > arm-eabi: FAIL: R_ARM_THM_JUMP24 Relocation veneers: Long > arm-eabi: FAIL: R_ARM_THM_JUMP24 Relocation veneers: Short 1 > arm-eabi: FAIL: R_ARM_THM_JUMP24 Relocation veneers: Short 2 > arm-linux-gnueabi: OK same here. ia64-linux: ok mips,mipsel-linux: ok, 67 fails, but no regressions. powerpc-linux: Running /build/buildd-binutils_2.20.90.20101121-1-powerpc-XdExQa/binutils-2.20.90.20101121/ld/testsuite/ld-plugin/plugin.exp ... FAIL: plugin claimfile lost symbol FAIL: plugin claimfile replace symbol FAIL: plugin claimfile resolve symbol FAIL: plugin claimfile replace file FAIL: plugin set symbol visibility FAIL: plugin ignore lib FAIL: plugin claimfile replace lib s390-linux: ok sparc-linux: ok hurd, kfreebsd-i386, kfreebsd-amd64: Running /build/buildd-binutils_2.20.90.20101121-1-hurd-i386-bmt3A9/binutils-2.20.90.20101121/ld/testsuite/ld-bootstrap/bootstrap.exp ... FAIL: bootstrap FAIL: bootstrap with strip FAIL: bootstrap with --traditional-format FAIL: bootstrap with --no-keep-memory FAIL: bootstrap with --relax Running /build/buildd-binutils_2.20.90.20101121-1-hurd-i386-bmt3A9/binutils-2.20.90.20101121/ld/testsuite/ld-cdtest/cdtest.exp ... FAIL: cdtest FAIL: cdtest with -Ur ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-23 18:54 ` Matthias Klose @ 2010-11-24 9:28 ` Richard Sandiford 2010-11-24 14:40 ` Matthew Gretton-Dann 0 siblings, 1 reply; 40+ messages in thread From: Richard Sandiford @ 2010-11-24 9:28 UTC (permalink / raw) To: Matthias Klose; +Cc: Tristan Gingold, binutils Matthias Klose <doko@ubuntu.com> writes: > On 23.11.2010 17:32, Tristan Gingold wrote: >> Hi, >> >> here is the result of a first pre-test. I still plan to update the target list. >> >> Two comments: >> >> 1) are the arm-eabi failures expected ? > > I see these too, these seem to be introduced after 20101028. They were (rightly, IMO) introduced by the fix for ld/12001: we now complain if a symbol is defined by both -defsym and an input file. The patch below seems to work on both arm-linux-gnueabi and arm-eabi. Matthew, could you sanity-check it? I realise these -defsyms must be there for a reason, so I'm probably missing something, sorry. Richard ld/testsuite/ * ld-arm/arm-elf.exp (armeabitests): Remove --defsym argument from jump-reloc-veneers* tests. Index: ld/testsuite/ld-arm/arm-elf.exp =================================================================== --- ld/testsuite/ld-arm/arm-elf.exp 2010-11-24 08:58:57.000000000 +0000 +++ ld/testsuite/ld-arm/arm-elf.exp 2010-11-24 09:11:10.000000000 +0000 @@ -464,19 +464,19 @@ set armeabitests { "farcall-data"} {"R_ARM_THM_JUMP24 Relocation veneers: Short 1" - "-defsym _start=0x8000 --section-start destsect=0x00009000" + "--section-start destsect=0x00009000" "-march=armv7-a -mthumb" {jump-reloc-veneers.s} {{objdump -d jump-reloc-veneers-short1.d}} "jump-reloc-veneers-short1"} {"R_ARM_THM_JUMP24 Relocation veneers: Short 2" - "-defsym _start=0x8000 --section-start destsect=0x00900000" + "--section-start destsect=0x00900000" "-march=armv7-a -mthumb" {jump-reloc-veneers.s} {{objdump -d jump-reloc-veneers-short2.d}} "jump-reloc-veneers-short2"} {"R_ARM_THM_JUMP24 Relocation veneers: Long" - "-defsym _start=0x8000 --section-start destsect=0x09000000" + "--section-start destsect=0x09000000" "-march=armv7-a -mthumb" {jump-reloc-veneers.s} {{objdump -d jump-reloc-veneers-long.d}} ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-24 9:28 ` Richard Sandiford @ 2010-11-24 14:40 ` Matthew Gretton-Dann 2010-11-25 1:40 ` Alan Modra 0 siblings, 1 reply; 40+ messages in thread From: Matthew Gretton-Dann @ 2010-11-24 14:40 UTC (permalink / raw) To: Richard Sandiford; +Cc: Matthias Klose, Tristan Gingold, binutils [-- Attachment #1: Type: text/plain, Size: 3103 bytes --] Richard, On Wed, 2010-11-24 at 09:27 +0000, Richard Sandiford wrote: > Matthias Klose <doko@ubuntu.com> writes: > > On 23.11.2010 17:32, Tristan Gingold wrote: > >> Hi, > >> > >> here is the result of a first pre-test. I still plan to update the target list. > >> > >> Two comments: > >> > >> 1) are the arm-eabi failures expected ? > > > > I see these too, these seem to be introduced after 20101028. > > They were (rightly, IMO) introduced by the fix for ld/12001: we now > complain if a symbol is defined by both -defsym and an input file. > The patch below seems to work on both arm-linux-gnueabi and arm-eabi. > Matthew, could you sanity-check it? I realise these -defsyms must > be there for a reason, so I'm probably missing something, sorry. I agree that the tests are wrong and the fix for ld/12001 is correct. The -defsyms were in the tests originally to ensure that the code was put at particular locations to make sure we generated the correct relocation veneers when necessary. > Richard > > ld/testsuite/ > * ld-arm/arm-elf.exp (armeabitests): Remove --defsym argument > from jump-reloc-veneers* tests. > > Index: ld/testsuite/ld-arm/arm-elf.exp > =================================================================== > --- ld/testsuite/ld-arm/arm-elf.exp 2010-11-24 08:58:57.000000000 +0000 > +++ ld/testsuite/ld-arm/arm-elf.exp 2010-11-24 09:11:10.000000000 +0000 > @@ -464,19 +464,19 @@ set armeabitests { > "farcall-data"} > > {"R_ARM_THM_JUMP24 Relocation veneers: Short 1" > - "-defsym _start=0x8000 --section-start destsect=0x00009000" > + "--section-start destsect=0x00009000" > "-march=armv7-a -mthumb" > {jump-reloc-veneers.s} > {{objdump -d jump-reloc-veneers-short1.d}} > "jump-reloc-veneers-short1"} > {"R_ARM_THM_JUMP24 Relocation veneers: Short 2" > - "-defsym _start=0x8000 --section-start destsect=0x00900000" > + "--section-start destsect=0x00900000" > "-march=armv7-a -mthumb" > {jump-reloc-veneers.s} > {{objdump -d jump-reloc-veneers-short2.d}} > "jump-reloc-veneers-short2"} > {"R_ARM_THM_JUMP24 Relocation veneers: Long" > - "-defsym _start=0x8000 --section-start destsect=0x09000000" > + "--section-start destsect=0x09000000" > "-march=armv7-a -mthumb" > {jump-reloc-veneers.s} > {{objdump -d jump-reloc-veneers-long.d}} The current default ld script lays the code out as desired for the tests, and so your proposed change is correct. But in an effort to keep these tests future proof I suggest that we force the '.text' section to start at 0x8000 on the command line as well as the 'destsect' section. I have attached a patch which does this. Any comments welcome, and if there are no issues can someone please approve. Thanks, Matt ld/testsuite/ * ld-arm/arm-elf.exp (armeabitests): Replace --defsym argument in jump-reloc-veneers* tests with --section-start .text=0x8000. -- Matthew Gretton-Dann Principal Engineer - PDSW Tools ARM Ltd [-- Attachment #2: 1011-ld-testsuite-fix.patch --] [-- Type: text/x-patch, Size: 1255 bytes --] diff --git a/ld/testsuite/ld-arm/arm-elf.exp b/ld/testsuite/ld-arm/arm-elf.exp index ef5f0f4..80f521e 100644 --- a/ld/testsuite/ld-arm/arm-elf.exp +++ b/ld/testsuite/ld-arm/arm-elf.exp @@ -464,19 +464,19 @@ set armeabitests { "farcall-data"} {"R_ARM_THM_JUMP24 Relocation veneers: Short 1" - "-defsym _start=0x8000 --section-start destsect=0x00009000" + "--section-start destsect=0x00009000 --section-start .text=0x8000" "-march=armv7-a -mthumb" {jump-reloc-veneers.s} {{objdump -d jump-reloc-veneers-short1.d}} "jump-reloc-veneers-short1"} {"R_ARM_THM_JUMP24 Relocation veneers: Short 2" - "-defsym _start=0x8000 --section-start destsect=0x00900000" + "--section-start destsect=0x00900000 --section-start .text=0x8000" "-march=armv7-a -mthumb" {jump-reloc-veneers.s} {{objdump -d jump-reloc-veneers-short2.d}} "jump-reloc-veneers-short2"} {"R_ARM_THM_JUMP24 Relocation veneers: Long" - "-defsym _start=0x8000 --section-start destsect=0x09000000" + "--section-start destsect=0x09000000 --section-start .text=0x8000" "-march=armv7-a -mthumb" {jump-reloc-veneers.s} {{objdump -d jump-reloc-veneers-long.d}} ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-24 14:40 ` Matthew Gretton-Dann @ 2010-11-25 1:40 ` Alan Modra 2010-11-25 9:49 ` Matthew Gretton-Dann 0 siblings, 1 reply; 40+ messages in thread From: Alan Modra @ 2010-11-25 1:40 UTC (permalink / raw) To: Matthew Gretton-Dann Cc: Richard Sandiford, Matthias Klose, Tristan Gingold, binutils On Wed, Nov 24, 2010 at 02:40:26PM +0000, Matthew Gretton-Dann wrote: > ld/testsuite/ > * ld-arm/arm-elf.exp (armeabitests): Replace --defsym argument > in jump-reloc-veneers* tests with --section-start .text=0x8000. OK, assuming you have actually run the testsuite. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-25 1:40 ` Alan Modra @ 2010-11-25 9:49 ` Matthew Gretton-Dann 2010-11-25 9:55 ` Tristan Gingold 0 siblings, 1 reply; 40+ messages in thread From: Matthew Gretton-Dann @ 2010-11-25 9:49 UTC (permalink / raw) To: Alan Modra; +Cc: Richard Sandiford, Matthias Klose, Tristan Gingold, binutils On Thu, 2010-11-25 at 12:10 +1030, Alan Modra wrote: > On Wed, Nov 24, 2010 at 02:40:26PM +0000, Matthew Gretton-Dann wrote: > > ld/testsuite/ > > * ld-arm/arm-elf.exp (armeabitests): Replace --defsym argument > > in jump-reloc-veneers* tests with --section-start .text=0x8000. > > OK, assuming you have actually run the testsuite. I had run the testsuite (arm-none-eabi - I should have said). These are now checked in: http://sourceware.org/ml/binutils-cvs/2010-11/msg00162.html Tristan, Can I check the change in onto the 2.21 branch as well? Thanks, Matt -- Matthew Gretton-Dann Principal Engineer - PDSW Tools ARM Ltd ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-25 9:49 ` Matthew Gretton-Dann @ 2010-11-25 9:55 ` Tristan Gingold 2010-11-25 15:16 ` Matthew Gretton-Dann 0 siblings, 1 reply; 40+ messages in thread From: Tristan Gingold @ 2010-11-25 9:55 UTC (permalink / raw) To: Matthew Gretton-Dann Cc: Alan Modra, Richard Sandiford, Matthias Klose, binutils On Nov 25, 2010, at 10:49 AM, Matthew Gretton-Dann wrote: > On Thu, 2010-11-25 at 12:10 +1030, Alan Modra wrote: >> On Wed, Nov 24, 2010 at 02:40:26PM +0000, Matthew Gretton-Dann wrote: >>> ld/testsuite/ >>> * ld-arm/arm-elf.exp (armeabitests): Replace --defsym argument >>> in jump-reloc-veneers* tests with --section-start .text=0x8000. >> >> OK, assuming you have actually run the testsuite. > > I had run the testsuite (arm-none-eabi - I should have said). > > These are now checked in: > http://sourceware.org/ml/binutils-cvs/2010-11/msg00162.html > > Tristan, Can I check the change in onto the 2.21 branch as well? Yes, please. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-25 9:55 ` Tristan Gingold @ 2010-11-25 15:16 ` Matthew Gretton-Dann 0 siblings, 0 replies; 40+ messages in thread From: Matthew Gretton-Dann @ 2010-11-25 15:16 UTC (permalink / raw) To: Tristan Gingold; +Cc: Alan Modra, Richard Sandiford, Matthias Klose, binutils On Thu, 2010-11-25 at 10:55 +0100, Tristan Gingold wrote: > On Nov 25, 2010, at 10:49 AM, Matthew Gretton-Dann wrote: > > > On Thu, 2010-11-25 at 12:10 +1030, Alan Modra wrote: > >> On Wed, Nov 24, 2010 at 02:40:26PM +0000, Matthew Gretton-Dann wrote: > >>> ld/testsuite/ > >>> * ld-arm/arm-elf.exp (armeabitests): Replace --defsym argument > >>> in jump-reloc-veneers* tests with --section-start .text=0x8000. > >> > >> OK, assuming you have actually run the testsuite. > > > > I had run the testsuite (arm-none-eabi - I should have said). > > > > These are now checked in: > > http://sourceware.org/ml/binutils-cvs/2010-11/msg00162.html > > > > Tristan, Can I check the change in onto the 2.21 branch as well? > > Yes, please. > Now done. Thanks, Matt -- Matthew Gretton-Dann Principal Engineer - PDSW Tools ARM Ltd ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-23 16:32 ` Release 2.21 - Pre tests Tristan Gingold 2010-11-23 18:54 ` Matthias Klose @ 2010-11-23 21:04 ` Ian Lance Taylor 2010-11-23 21:17 ` H.J. Lu 2010-11-24 8:23 ` Tristan Gingold 2010-11-24 9:53 ` Matthew Gretton-Dann 2010-12-01 15:14 ` Release 2.21 - Soon Tristan Gingold 3 siblings, 2 replies; 40+ messages in thread From: Ian Lance Taylor @ 2010-11-23 21:04 UTC (permalink / raw) To: Tristan Gingold; +Cc: binutils Tristan Gingold <gingold@adacore.com> writes: > 2) I wasn't able to build gold with the compilers I used (gcc 4.1.2 from RH or gcc 4.1.0 from SUSE) What failed? Ian ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-23 21:04 ` Ian Lance Taylor @ 2010-11-23 21:17 ` H.J. Lu 2010-11-23 23:00 ` Ian Lance Taylor 2010-11-24 8:23 ` Tristan Gingold 1 sibling, 1 reply; 40+ messages in thread From: H.J. Lu @ 2010-11-23 21:17 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Tristan Gingold, binutils On Tue, Nov 23, 2010 at 1:03 PM, Ian Lance Taylor <iant@google.com> wrote: > Tristan Gingold <gingold@adacore.com> writes: > >> 2) I wasn't able to build gold with the compilers I used (gcc 4.1.2 from RH or gcc 4.1.0 from SUSE) > > What failed? > Gold requires GCC 4.2. -- H.J. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-23 21:17 ` H.J. Lu @ 2010-11-23 23:00 ` Ian Lance Taylor 2010-11-23 23:09 ` H.J. Lu 0 siblings, 1 reply; 40+ messages in thread From: Ian Lance Taylor @ 2010-11-23 23:00 UTC (permalink / raw) To: H.J. Lu; +Cc: Tristan Gingold, binutils "H.J. Lu" <hjl.tools@gmail.com> writes: > On Tue, Nov 23, 2010 at 1:03 PM, Ian Lance Taylor <iant@google.com> wrote: >> Tristan Gingold <gingold@adacore.com> writes: >> >>> 2) I wasn't able to build gold with the compilers I used (gcc 4.1.2 from RH or gcc 4.1.0 from SUSE) >> >> What failed? >> > > Gold requires GCC 4.2. Gold is currently only documented as requiring 4.0.3. If it does require 4.2, we should at least understand why. Ian ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-23 23:00 ` Ian Lance Taylor @ 2010-11-23 23:09 ` H.J. Lu 0 siblings, 0 replies; 40+ messages in thread From: H.J. Lu @ 2010-11-23 23:09 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Tristan Gingold, binutils On Tue, Nov 23, 2010 at 2:59 PM, Ian Lance Taylor <iant@google.com> wrote: > "H.J. Lu" <hjl.tools@gmail.com> writes: > >> On Tue, Nov 23, 2010 at 1:03 PM, Ian Lance Taylor <iant@google.com> wrote: >>> Tristan Gingold <gingold@adacore.com> writes: >>> >>>> 2) I wasn't able to build gold with the compilers I used (gcc 4.1.2 from RH or gcc 4.1.0 from SUSE) >>> >>> What failed? >>> >> >> Gold requires GCC 4.2. > > Gold is currently only documented as requiring 4.0.3. If it does > require 4.2, we should at least understand why. > GCC 4.1 ICEd when compiling one or more source files. -- H.J. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-23 21:04 ` Ian Lance Taylor 2010-11-23 21:17 ` H.J. Lu @ 2010-11-24 8:23 ` Tristan Gingold 2010-12-01 0:21 ` Ian Lance Taylor 1 sibling, 1 reply; 40+ messages in thread From: Tristan Gingold @ 2010-11-24 8:23 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: binutils On Nov 23, 2010, at 10:03 PM, Ian Lance Taylor wrote: > Tristan Gingold <gingold@adacore.com> writes: > >> 2) I wasn't able to build gold with the compilers I used (gcc 4.1.2 from RH or gcc 4.1.0 from SUSE) > > What failed? ../../binutils-2.20.90/gold/arm.cc: In instantiation of 'const size_t <unnamed>::Target_arm<false>::fake_relnum_for_stubs': ../../binutils-2.20.90/gold/arm.cc:8627: instantiated from 'bool<unnamed>::Target_arm<big_endian>::Relocate::relocate(const gold::Relocate_info<32, big_endian>*, <unnamed>::Target_arm<big_endian>*, gold::Output_section*, size_t, const elfcpp::Rel<32, big_endian>&, unsigned int, const gold::Sized_symbol<32>*, const gold::Symbol_value<32>*, unsigned char*, <unnamed>::Arm_address, gold::section_size_type) [with bool big_endian = false]' ../../binutils-2.20.90/gold/target-reloc.h:334: instantiated from 'void gold::relocate_section(const gold::Relocate_info<size, big_endian>*, Target_type*, const unsigned char*, size_t, gold::Output_section*, bool, unsigned char*, typename elfcpp::Elf_types<size>::Elf_Addr, gold::section_size_type, const gold::Reloc_symbol_changes*) [with int size = 32, bool big_endian = false, Target_type = <unnamed>::Target_arm<false>, int sh_type = 9, Relocate = <unnamed>::Target_arm<false>::Relocate]' ../../binutils-2.20.90/gold/arm.cc:9263: instantiated from 'void<unnamed>::Target_arm<big_endian>::relocate_section(const gold::Relocate_info<32, big_endian>*, unsigned int, const unsigned char*, size_t, gold::Output_section*, bool, unsigned char*, <unnamed>::Arm_address, gold::section_size_type, const gold::Reloc_symbol_changes*) [with bool big_endian = false]' ../../binutils-2.20.90/gold/arm.cc:11770: instantiated from here ../../binutils-2.20.90/gold/arm.cc:2140: internal compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:5067 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugzilla.redhat.com/bugzilla> for instructions. Preprocessed source stored into /tmp/ccEtfk5w.out file, please attach this to your bugreport. or (on SUSE): ../../binutils-2.20.90/gold/icf.cc: In function ‘bool gold::match_sections(unsigned int, gold::Symbol_table*, std::vector<unsigned int, std::allocator<unsigned int> >*, std::vector<unsigned int, std::allocator<unsigned int> >*, const std::vector<std::pair<gold::Object*, unsigned int>, std::allocator<std::pair<gold::Object*, unsigned int> > >&, std::vector<bool, std::allocator<bool> >*, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)’: ../../binutils-2.20.90/gold/icf.cc:616: error: no matching function for call to ‘Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>::hashtable_iterator()’ /usr/include/c++/4.1.0/tr1/hashtable:309: note: candidates are: Internal::hashtable_iterator<Value, constant_iterators, cache>::hashtable_iterator(Internal::hash_node<Value, cache>**) [with Value = std::pair<const unsigned int, unsigned int>, bool constant_iterators = false, bool cache = false] /usr/include/c++/4.1.0/tr1/hashtable:305: note: Internal::hashtable_iterator<Value, constant_iterators, cache>::hashtable_iterator(Internal::hash_node<Value, cache>*, Internal::hash_node<Value, cache>**) [with Value = std::pair<const unsigned int, unsigned int>, bool constant_iterators = false, bool cache = false] /usr/include/c++/4.1.0/tr1/hashtable:295: note: Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>::hashtable_iterator(const Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>&) /usr/include/c++/4.1.0/bits/stl_pair.h: In constructor ‘std::pair<_T1, _T2>::pair() [with _T1 = Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>, _T2 = bool]’: ../../binutils-2.20.90/gold/icf.cc:173: instantiated from here /usr/include/c++/4.1.0/bits/stl_pair.h:81: error: no matching function for call to ‘Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>::hashtable_iterator()’ /usr/include/c++/4.1.0/tr1/hashtable:309: note: candidates are: Internal::hashtable_iterator<Value, constant_iterators, cache>::hashtable_iterator(Internal::hash_node<Value, cache>**) [with Value = std::pair<const unsigned int, unsigned int>, bool constant_iterators = false, bool cache = false] /usr/include/c++/4.1.0/tr1/hashtable:305: note: Internal::hashtable_iterator<Value, constant_iterators, cache>::hashtable_iterator(Internal::hash_node<Value, cache>*, Internal::hash_node<Value, cache>**) [with Value = std::pair<const unsigned int, unsigned int>, bool constant_iterators = false, bool cache = false] /usr/include/c++/4.1.0/tr1/hashtable:295: note: Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>::hashtable_iterator(const Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>&) /usr/include/c++/4.1.0/bits/stl_pair.h: In constructor ‘std::pair<_T1, _T2>::pair() [with _T1 = Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>, _T2 = Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>]’: ../../binutils-2.20.90/gold/icf.cc:552: instantiated from here /usr/include/c++/4.1.0/bits/stl_pair.h:81: error: no matching function for call to ‘Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>::hashtable_iterator()’ /usr/include/c++/4.1.0/tr1/hashtable:309: note: candidates are: Internal::hashtable_iterator<Value, constant_iterators, cache>::hashtable_iterator(Internal::hash_node<Value, cache>**) [with Value = std::pair<const unsigned int, unsigned int>, bool constant_iterators = false, bool cache = false] /usr/include/c++/4.1.0/tr1/hashtable:305: note: Internal::hashtable_iterator<Value, constant_iterators, cache>::hashtable_iterator(Internal::hash_node<Value, cache>*, Internal::hash_node<Value, cache>**) [with Value = std::pair<const unsigned int, unsigned int>, bool constant_iterators = false, bool cache = false] /usr/include/c++/4.1.0/tr1/hashtable:295: note: Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>::hashtable_iterator(const Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>&) /usr/include/c++/4.1.0/bits/stl_pair.h:81: error: no matching function for call to ‘Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>::hashtable_iterator()’ /usr/include/c++/4.1.0/tr1/hashtable:309: note: candidates are: Internal::hashtable_iterator<Value, constant_iterators, cache>::hashtable_iterator(Internal::hash_node<Value, cache>**) [with Value = std::pair<const unsigned int, unsigned int>, bool constant_iterators = false, bool cache = false] /usr/include/c++/4.1.0/tr1/hashtable:305: note: Internal::hashtable_iterator<Value, constant_iterators, cache>::hashtable_iterator(Internal::hash_node<Value, cache>*, Internal::hash_node<Value, cache>**) [with Value = std::pair<const unsigned int, unsigned int>, bool constant_iterators = false, bool cache = false] /usr/include/c++/4.1.0/tr1/hashtable:295: note: Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>::hashtable_iterator(const Internal::hashtable_iterator<std::pair<const unsigned int, unsigned int>, false, false>&) Tristan. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-24 8:23 ` Tristan Gingold @ 2010-12-01 0:21 ` Ian Lance Taylor 2010-12-01 11:03 ` Tristan Gingold 0 siblings, 1 reply; 40+ messages in thread From: Ian Lance Taylor @ 2010-12-01 0:21 UTC (permalink / raw) To: Tristan Gingold; +Cc: binutils Tristan Gingold <gingold@adacore.com> writes: > On Nov 23, 2010, at 10:03 PM, Ian Lance Taylor wrote: > >> Tristan Gingold <gingold@adacore.com> writes: >> >>> 2) I wasn't able to build gold with the compilers I used (gcc 4.1.2 from RH or gcc 4.1.0 from SUSE) >> >> What failed? > > ../../binutils-2.20.90/gold/arm.cc: In instantiation of 'const size_t <unnamed>::Target_arm<false>::fake_relnum_for_stubs': > ../../binutils-2.20.90/gold/arm.cc:8627: instantiated from 'bool<unnamed>::Target_arm<big_endian>::Relocate::relocate(const gold::Relocate_info<32, big_endian>*, <unnamed>::Target_arm<big_endian>*, gold::Output_section*, size_t, const elfcpp::Rel<32, big_endian>&, unsigned int, const gold::Sized_symbol<32>*, const gold::Symbol_value<32>*, unsigned char*, <unnamed>::Arm_address, gold::section_size_type) [with bool big_endian = false]' > ../../binutils-2.20.90/gold/target-reloc.h:334: instantiated from 'void gold::relocate_section(const gold::Relocate_info<size, big_endian>*, Target_type*, const unsigned char*, size_t, gold::Output_section*, bool, unsigned char*, typename elfcpp::Elf_types<size>::Elf_Addr, gold::section_size_type, const gold::Reloc_symbol_changes*) [with int size = 32, bool big_endian = false, Target_type = <unnamed>::Target_arm<false>, int sh_type = 9, Relocate = <unnamed>::Target_arm<false>::Relocate]' > ../../binutils-2.20.90/gold/arm.cc:9263: instantiated from 'void<unnamed>::Target_arm<big_endian>::relocate_section(const gold::Relocate_info<32, big_endian>*, unsigned int, const unsigned char*, size_t, gold::Output_section*, bool, unsigned char*, <unnamed>::Arm_address, gold::section_size_type, const gold::Reloc_symbol_changes*) [with bool big_endian = false]' > ../../binutils-2.20.90/gold/arm.cc:11770: instantiated from here > ../../binutils-2.20.90/gold/arm.cc:2140: internal compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:5067 > Please submit a full bug report, I just tried building gold with gcc 4.1.3 20080704 from the 4.1 release branch and it succeeded. I'm not sure whether to do anything about this. Ian ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-12-01 0:21 ` Ian Lance Taylor @ 2010-12-01 11:03 ` Tristan Gingold 2010-12-01 16:53 ` Ian Lance Taylor 0 siblings, 1 reply; 40+ messages in thread From: Tristan Gingold @ 2010-12-01 11:03 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: binutils On Dec 1, 2010, at 1:14 AM, Ian Lance Taylor wrote: > Tristan Gingold <gingold@adacore.com> writes: > >> On Nov 23, 2010, at 10:03 PM, Ian Lance Taylor wrote: >> >>> Tristan Gingold <gingold@adacore.com> writes: >>> >>>> 2) I wasn't able to build gold with the compilers I used (gcc 4.1.2 from RH or gcc 4.1.0 from SUSE) >>> >>> What failed? >> >> ../../binutils-2.20.90/gold/arm.cc: In instantiation of 'const size_t <unnamed>::Target_arm<false>::fake_relnum_for_stubs': >> ../../binutils-2.20.90/gold/arm.cc:8627: instantiated from 'bool<unnamed>::Target_arm<big_endian>::Relocate::relocate(const gold::Relocate_info<32, big_endian>*, <unnamed>::Target_arm<big_endian>*, gold::Output_section*, size_t, const elfcpp::Rel<32, big_endian>&, unsigned int, const gold::Sized_symbol<32>*, const gold::Symbol_value<32>*, unsigned char*, <unnamed>::Arm_address, gold::section_size_type) [with bool big_endian = false]' >> ../../binutils-2.20.90/gold/target-reloc.h:334: instantiated from 'void gold::relocate_section(const gold::Relocate_info<size, big_endian>*, Target_type*, const unsigned char*, size_t, gold::Output_section*, bool, unsigned char*, typename elfcpp::Elf_types<size>::Elf_Addr, gold::section_size_type, const gold::Reloc_symbol_changes*) [with int size = 32, bool big_endian = false, Target_type = <unnamed>::Target_arm<false>, int sh_type = 9, Relocate = <unnamed>::Target_arm<false>::Relocate]' >> ../../binutils-2.20.90/gold/arm.cc:9263: instantiated from 'void<unnamed>::Target_arm<big_endian>::relocate_section(const gold::Relocate_info<32, big_endian>*, unsigned int, const unsigned char*, size_t, gold::Output_section*, bool, unsigned char*, <unnamed>::Arm_address, gold::section_size_type, const gold::Reloc_symbol_changes*) [with bool big_endian = false]' >> ../../binutils-2.20.90/gold/arm.cc:11770: instantiated from here >> ../../binutils-2.20.90/gold/arm.cc:2140: internal compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:5067 >> Please submit a full bug report, > > I just tried building gold with gcc 4.1.3 20080704 from the 4.1 release > branch and it succeeded. > > I'm not sure whether to do anything about this. Not sure too. Maybe we should document that gcc 4.1.3 is know to work too, while gcc 4.1.0 - 4.1.2 are known to fail. Anyway, we will see if we have complaints from users. Tristan. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-12-01 11:03 ` Tristan Gingold @ 2010-12-01 16:53 ` Ian Lance Taylor 2010-12-08 10:47 ` Tristan Gingold 0 siblings, 1 reply; 40+ messages in thread From: Ian Lance Taylor @ 2010-12-01 16:53 UTC (permalink / raw) To: Tristan Gingold; +Cc: binutils [-- Attachment #1: Type: text/plain, Size: 338 bytes --] Tristan Gingold <gingold@adacore.com> writes: > Not sure too. Maybe we should document that gcc 4.1.3 is know to work > too, while gcc 4.1.0 - 4.1.2 are known to fail. I have committed this patch to mainline and 2.21 branch. Ian 2010-12-01 Ian Lance Taylor <iant@google.com> * README: Update compilers known to work and fail. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: README --] [-- Type: text/x-diff, Size: 695 bytes --] Index: README =================================================================== RCS file: /cvs/src/src/gold/README,v retrieving revision 1.5 diff -u -r1.5 README --- README 8 Sep 2010 16:10:31 -0000 1.5 +++ README 1 Dec 2010 16:51:19 -0000 @@ -53,8 +53,8 @@ ================== The gold source code uses templates heavily. Building it requires a -recent version of g++. g++ 4.0.3 is known to work. g++ 3.2 and g++ -3.4.3 are known to fail. +recent version of g++. g++ 4.0.3 and 4.1.3 are known to work. g++ +3.2, 3.4.3, and 4.1.2 are known to fail. The linker script parser uses features which are only in newer versions of bison. bison 2.3 is known to work. bison 1.26 is known ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-12-01 16:53 ` Ian Lance Taylor @ 2010-12-08 10:47 ` Tristan Gingold 2010-12-08 15:55 ` Ian Lance Taylor 0 siblings, 1 reply; 40+ messages in thread From: Tristan Gingold @ 2010-12-08 10:47 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: binutils On Dec 1, 2010, at 5:53 PM, Ian Lance Taylor wrote: > Tristan Gingold <gingold@adacore.com> writes: > >> Not sure too. Maybe we should document that gcc 4.1.3 is know to work >> too, while gcc 4.1.0 - 4.1.2 are known to fail. > > I have committed this patch to mainline and 2.21 branch. BTW, is the web page still accurate: * gold - A new, faster, ELF only linker, still in beta test. Ie, do you consider gold as 'still in beta test' ? Tristan. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-12-08 10:47 ` Tristan Gingold @ 2010-12-08 15:55 ` Ian Lance Taylor 2010-12-08 16:02 ` Tristan Gingold 0 siblings, 1 reply; 40+ messages in thread From: Ian Lance Taylor @ 2010-12-08 15:55 UTC (permalink / raw) To: Tristan Gingold; +Cc: binutils Tristan Gingold <gingold@adacore.com> writes: > On Dec 1, 2010, at 5:53 PM, Ian Lance Taylor wrote: > >> Tristan Gingold <gingold@adacore.com> writes: >> >>> Not sure too. Maybe we should document that gcc 4.1.3 is know to work >>> too, while gcc 4.1.0 - 4.1.2 are known to fail. >> >> I have committed this patch to mainline and 2.21 branch. > > BTW, is the web page still accurate: > > * gold - A new, faster, ELF only linker, still in beta test. > > Ie, do you consider gold as 'still in beta test' ? I don't really, but in the wider scheme of things gold is perhaps reasonably described as in beta test until it is the standard linker for at least one distro. Also I would like to see the kernel developers reliably test with gold, and of course the glibc build still does not work with gold. I don't really know what the web page should say. Ian ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-12-08 15:55 ` Ian Lance Taylor @ 2010-12-08 16:02 ` Tristan Gingold 0 siblings, 0 replies; 40+ messages in thread From: Tristan Gingold @ 2010-12-08 16:02 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: binutils On Dec 8, 2010, at 4:55 PM, Ian Lance Taylor wrote: > > I don't really, but in the wider scheme of things gold is perhaps > reasonably described as in beta test until it is the standard linker for > at least one distro. Also I would like to see the kernel developers > reliably test with gold, and of course the glibc build still does not > work with gold. I don't really know what the web page should say. Ok, let's wait for the next release if we want to update the web page. Tristan. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-23 16:32 ` Release 2.21 - Pre tests Tristan Gingold 2010-11-23 18:54 ` Matthias Klose 2010-11-23 21:04 ` Ian Lance Taylor @ 2010-11-24 9:53 ` Matthew Gretton-Dann 2010-11-24 9:56 ` Tristan Gingold 2010-12-01 15:14 ` Release 2.21 - Soon Tristan Gingold 3 siblings, 1 reply; 40+ messages in thread From: Matthew Gretton-Dann @ 2010-11-24 9:53 UTC (permalink / raw) To: Tristan Gingold; +Cc: binutils On Tue, 2010-11-23 at 17:32 +0100, Tristan Gingold wrote: > here is the result of a first pre-test. I still plan to update the target list. > > Two comments: > > 1) are the arm-eabi failures expected ? These are due to this change: http://sourceware.org/ml/binutils-cvs/2010-11/msg00012.html which fixes: http://sourceware.org/bugzilla/show_bug.cgi?id=12001 I think the problem is with the test rather than the fix itself, and am working through creating a patch - but I don't think it should hold up the release. Thanks, Matt -- Matthew Gretton-Dann Principal Engineer - PDSW Tools ARM Ltd ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Pre tests 2010-11-24 9:53 ` Matthew Gretton-Dann @ 2010-11-24 9:56 ` Tristan Gingold 0 siblings, 0 replies; 40+ messages in thread From: Tristan Gingold @ 2010-11-24 9:56 UTC (permalink / raw) To: Matthew Gretton-Dann; +Cc: binutils On Nov 24, 2010, at 10:53 AM, Matthew Gretton-Dann wrote: > On Tue, 2010-11-23 at 17:32 +0100, Tristan Gingold wrote: >> here is the result of a first pre-test. I still plan to update the target list. >> >> Two comments: >> >> 1) are the arm-eabi failures expected ? > > These are due to this change: > http://sourceware.org/ml/binutils-cvs/2010-11/msg00012.html > > which fixes: http://sourceware.org/bugzilla/show_bug.cgi?id=12001 > > I think the problem is with the test rather than the fix itself, and am > working through creating a patch - but I don't think it should hold up > the release. Yes, Richard Sandiford has already proposed a patch to fix the tests. Tristan. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Release 2.21 - Soon... 2010-11-23 16:32 ` Release 2.21 - Pre tests Tristan Gingold ` (2 preceding siblings ...) 2010-11-24 9:53 ` Matthew Gretton-Dann @ 2010-12-01 15:14 ` Tristan Gingold 2010-12-01 15:18 ` H.J. Lu ` (2 more replies) 3 siblings, 3 replies; 40+ messages in thread From: Tristan Gingold @ 2010-12-01 15:14 UTC (permalink / raw) To: binutils Hi, here are my latest results from the release branch. The most worrying issues (arm-eabi) are now fixed, and most of the targets are in a good state. (I added a some targets compared to the previous tests results in this report). I plan to do the 2.21 release very soon... Tristan. alpha-linux: OK arc-elf: OK arm-eabi: OK arm-linux-gnueabi: OK avr: OK bfin-elf: OK cr16-elf: OK cris-elf: OK crx-elf: OK d10v-elf: OK d30v-elf: OK dlx-elf: OK fr30-elf: OK frv-elf: FAIL: FRV uClinux PIC relocs to weak undefined symbols, pie linking frv-elf: FAIL: FRV uClinux PIC relocs to weak undefined symbols, shared linking h8300-elf: OK hppa-hp-hpux10: OK hppa-linux-gnu: OK hppa64-hp-hpux11.23: OK i370-linux: FAIL: -shared --entry foo -u foo archive i370-linux: FAIL: -shared --entry foo archive i370-linux: FAIL: Weak symbols in dynamic objects 1 (main test) i370-linux: FAIL: bad byte directive i370-linux: FAIL: ld link shared library i370-linux: FAIL: ld-elf/compress1c i370-linux: FAIL: ld-elf/dynsym1 i370-linux: FAIL: ld-elf/hash i370-linux: FAIL: ld-elf/local1 i370-linux: FAIL: ld-elf/textaddr1 i370-linux: FAIL: ld-elf/textaddr2 i370-linux: FAIL: ld-elf/textaddr3 i370-linux: FAIL: ld-elf/textaddr4 i370-linux: FAIL: ld-elf/textaddr5 i370-linux: FAIL: ld-elf/textaddr6 i370-linux: FAIL: ld-elf/unknown2 i370-linux: FAIL: read-only .eh_frame section i370-linux: FAIL: read-only .gcc_except_table section i686-pc-cygwin: OK i686-pc-linux-gnu: OK ia64-linux: OK ip2k-elf: OK iq2000-elf: OK lm32-elf: OK m32c-elf: OK m32r-elf: OK m68hc11-elf: OK m68k-elf: OK mcore-elf: OK mep-elf: OK microblaze-elf: OK mingw32-pe: OK mips-ecoff: FAIL: .set arch=FOO mips-ecoff: FAIL: APP with macro then NO_APP mips-ecoff: FAIL: APP with macro then NO_APP then more code mips-ecoff: FAIL: APP with macro without NO_APP mips-ecoff: FAIL: MIPS -mgp32 -mfp32 mips-ecoff: FAIL: MIPS -mgp32 -mfp64 mips-ecoff: FAIL: MIPS -mgp64 -mfp32 mips-ecoff: FAIL: MIPS -mgp64 -mfp64 mips-ecoff: FAIL: MIPS DSP ASE Rev2 for MIPS32 mips-ecoff: FAIL: MIPS DSP ASE for MIPS32 mips-ecoff: FAIL: MIPS DSP ASE for MIPS64 mips-ecoff: FAIL: MIPS MT ASE for MIPS32 mips-ecoff: FAIL: MIPS VR4111 mips-ecoff: FAIL: MIPS VR4120 mips-ecoff: FAIL: MIPS VR4130 workarounds mips-ecoff: FAIL: MIPS VR5400 mips-ecoff: FAIL: MIPS VR5500 mips-ecoff: FAIL: MIPS align maximum mips-ecoff: FAIL: MIPS l.d (mips3) mips-ecoff: FAIL: MIPS l.d (mips4) mips-ecoff: FAIL: MIPS l.d (mips5) mips-ecoff: FAIL: MIPS l.d (mips64) mips-ecoff: FAIL: MIPS l.d (mips64r2) mips-ecoff: FAIL: MIPS l.d (octeon) mips-ecoff: FAIL: MIPS l.d (r4000) mips-ecoff: FAIL: MIPS l.d (sb1) mips-ecoff: FAIL: MIPS l.d (vr5400) mips-ecoff: FAIL: MIPS l.d (xlr) mips-ecoff: FAIL: MIPS l.d forward (mips3) mips-ecoff: FAIL: MIPS l.d forward (mips4) mips-ecoff: FAIL: MIPS l.d forward (mips5) mips-ecoff: FAIL: MIPS l.d forward (mips64) mips-ecoff: FAIL: MIPS l.d forward (mips64r2) mips-ecoff: FAIL: MIPS l.d forward (octeon) mips-ecoff: FAIL: MIPS l.d forward (r4000) mips-ecoff: FAIL: MIPS l.d forward (sb1) mips-ecoff: FAIL: MIPS l.d forward (vr5400) mips-ecoff: FAIL: MIPS l.d forward (xlr) mips-ecoff: FAIL: MIPS lb (mips1) mips-ecoff: FAIL: MIPS lb (r3000) mips-ecoff: FAIL: MIPS lb (r3900) mips-ecoff: FAIL: MIPS ld (mips3) mips-ecoff: FAIL: MIPS ld (mips4) mips-ecoff: FAIL: MIPS ld (mips5) mips-ecoff: FAIL: MIPS ld (mips64) mips-ecoff: FAIL: MIPS ld (mips64r2) mips-ecoff: FAIL: MIPS ld (octeon) mips-ecoff: FAIL: MIPS ld (r4000) mips-ecoff: FAIL: MIPS ld (sb1) mips-ecoff: FAIL: MIPS ld (vr5400) mips-ecoff: FAIL: MIPS ld (xlr) mips-ecoff: FAIL: MIPS ld forward (mips3) mips-ecoff: FAIL: MIPS ld forward (mips4) mips-ecoff: FAIL: MIPS ld forward (mips5) mips-ecoff: FAIL: MIPS ld forward (mips64) mips-ecoff: FAIL: MIPS ld forward (mips64r2) mips-ecoff: FAIL: MIPS ld forward (octeon) mips-ecoff: FAIL: MIPS ld forward (r4000) mips-ecoff: FAIL: MIPS ld forward (sb1) mips-ecoff: FAIL: MIPS ld forward (vr5400) mips-ecoff: FAIL: MIPS ld forward (xlr) mips-ecoff: FAIL: MIPS ld-st-la (EABI64) mips-ecoff: FAIL: MIPS ld-st-la bad constants (ABI o32) mips-ecoff: FAIL: MIPS ld-st-la bad constants (ABI o32, mips3) mips-ecoff: FAIL: MIPS ld-st-la bad constants (ABI o32, mips3, shared) mips-ecoff: FAIL: MIPS ld-st-la bad constants (ABI o32, shared) mips-ecoff: FAIL: MIPS ld-st-la constants (ABI o32) mips-ecoff: FAIL: MIPS ld-st-la constants (ABI o32, mips3) mips-ecoff: FAIL: MIPS ld-st-la constants (ABI o32, mips3, shared) mips-ecoff: FAIL: MIPS ld-st-la constants (ABI o32, shared) mips-ecoff: FAIL: MIPS ldc1 (mips3) mips-ecoff: FAIL: MIPS ldc1 (mips4) mips-ecoff: FAIL: MIPS ldc1 (mips5) mips-ecoff: FAIL: MIPS ldc1 (mips64) mips-ecoff: FAIL: MIPS ldc1 (mips64r2) mips-ecoff: FAIL: MIPS ldc1 (octeon) mips-ecoff: FAIL: MIPS ldc1 (r4000) mips-ecoff: FAIL: MIPS ldc1 (sb1) mips-ecoff: FAIL: MIPS ldc1 (vr5400) mips-ecoff: FAIL: MIPS ldc1 (xlr) mips-ecoff: FAIL: MIPS ldc1 forward (mips3) mips-ecoff: FAIL: MIPS ldc1 forward (mips4) mips-ecoff: FAIL: MIPS ldc1 forward (mips5) mips-ecoff: FAIL: MIPS ldc1 forward (mips64) mips-ecoff: FAIL: MIPS ldc1 forward (mips64r2) mips-ecoff: FAIL: MIPS ldc1 forward (octeon) mips-ecoff: FAIL: MIPS ldc1 forward (r4000) mips-ecoff: FAIL: MIPS ldc1 forward (sb1) mips-ecoff: FAIL: MIPS ldc1 forward (vr5400) mips-ecoff: FAIL: MIPS ldc1 forward (xlr) mips-ecoff: FAIL: MIPS mips32r2-ill-fp64 (mips64r2) mips-ecoff: FAIL: MIPS mips32r2-ill-fp64 (octeon) mips-ecoff: FAIL: MIPS octeon instructions (octeon) mips-ecoff: FAIL: MIPS octeon-pref mfix-cn63xxp1 (octeon) mips-ecoff: FAIL: MIPS odd float mips-ecoff: FAIL: MIPS relax mips-ecoff: FAIL: MIPS s.d (mips3) mips-ecoff: FAIL: MIPS s.d (mips4) mips-ecoff: FAIL: MIPS s.d (mips5) mips-ecoff: FAIL: MIPS s.d (mips64) mips-ecoff: FAIL: MIPS s.d (mips64r2) mips-ecoff: FAIL: MIPS s.d (octeon) mips-ecoff: FAIL: MIPS s.d (r4000) mips-ecoff: FAIL: MIPS s.d (sb1) mips-ecoff: FAIL: MIPS s.d (vr5400) mips-ecoff: FAIL: MIPS s.d (xlr) mips-ecoff: FAIL: MIPS s.d forward (mips3) mips-ecoff: FAIL: MIPS s.d forward (mips4) mips-ecoff: FAIL: MIPS s.d forward (mips5) mips-ecoff: FAIL: MIPS s.d forward (mips64) mips-ecoff: FAIL: MIPS s.d forward (mips64r2) mips-ecoff: FAIL: MIPS s.d forward (octeon) mips-ecoff: FAIL: MIPS s.d forward (r4000) mips-ecoff: FAIL: MIPS s.d forward (sb1) mips-ecoff: FAIL: MIPS s.d forward (vr5400) mips-ecoff: FAIL: MIPS s.d forward (xlr) mips-ecoff: FAIL: MIPS sd (mips3) mips-ecoff: FAIL: MIPS sd (mips4) mips-ecoff: FAIL: MIPS sd (mips5) mips-ecoff: FAIL: MIPS sd (mips64) mips-ecoff: FAIL: MIPS sd (mips64r2) mips-ecoff: FAIL: MIPS sd (octeon) mips-ecoff: FAIL: MIPS sd (r4000) mips-ecoff: FAIL: MIPS sd (sb1) mips-ecoff: FAIL: MIPS sd (vr5400) mips-ecoff: FAIL: MIPS sd (xlr) mips-ecoff: FAIL: MIPS sd forward (mips3) mips-ecoff: FAIL: MIPS sd forward (mips4) mips-ecoff: FAIL: MIPS sd forward (mips5) mips-ecoff: FAIL: MIPS sd forward (mips64) mips-ecoff: FAIL: MIPS sd forward (mips64r2) mips-ecoff: FAIL: MIPS sd forward (octeon) mips-ecoff: FAIL: MIPS sd forward (r4000) mips-ecoff: FAIL: MIPS sd forward (sb1) mips-ecoff: FAIL: MIPS sd forward (vr5400) mips-ecoff: FAIL: MIPS sd forward (xlr) mips-ecoff: FAIL: MIPS sdc1 (mips3) mips-ecoff: FAIL: MIPS sdc1 (mips4) mips-ecoff: FAIL: MIPS sdc1 (mips5) mips-ecoff: FAIL: MIPS sdc1 (mips64) mips-ecoff: FAIL: MIPS sdc1 (mips64r2) mips-ecoff: FAIL: MIPS sdc1 (octeon) mips-ecoff: FAIL: MIPS sdc1 (r4000) mips-ecoff: FAIL: MIPS sdc1 (sb1) mips-ecoff: FAIL: MIPS sdc1 (vr5400) mips-ecoff: FAIL: MIPS sdc1 (xlr) mips-ecoff: FAIL: MIPS sdc1 forward (mips3) mips-ecoff: FAIL: MIPS sdc1 forward (mips4) mips-ecoff: FAIL: MIPS sdc1 forward (mips5) mips-ecoff: FAIL: MIPS sdc1 forward (mips64) mips-ecoff: FAIL: MIPS sdc1 forward (mips64r2) mips-ecoff: FAIL: MIPS sdc1 forward (octeon) mips-ecoff: FAIL: MIPS sdc1 forward (r4000) mips-ecoff: FAIL: MIPS sdc1 forward (sb1) mips-ecoff: FAIL: MIPS sdc1 forward (vr5400) mips-ecoff: FAIL: MIPS sdc1 forward (xlr) mips-ecoff: FAIL: MIPS1 branch relaxation with swapping mips-ecoff: FAIL: MIPS2 branch likely relaxation with swapping mips-ecoff: FAIL: MIPS2 branch relaxation with swapping mips-ecoff: FAIL: MIPS32 odd single-precision float registers (mips32) mips-ecoff: FAIL: MIPS32 odd single-precision float registers (mips32r2) mips-ecoff: FAIL: MIPS32 odd single-precision float registers (mips64) mips-ecoff: FAIL: MIPS32 odd single-precision float registers (mips64r2) mips-ecoff: FAIL: MIPS32 odd single-precision float registers (octeon) mips-ecoff: FAIL: MIPS32 odd single-precision float registers (sb1) mips-ecoff: FAIL: MIPS32 odd single-precision float registers (xlr) mips-ecoff: FAIL: ST Microelectronics Loongson-2E tests mips-ecoff: FAIL: ST Microelectronics Loongson-2F tests mips-ecoff: FAIL: ST Microelectronics Loongson-2F workarounds of Jump Instruction issue mips-ecoff: FAIL: ST Microelectronics Loongson-2F workarounds of nop issue mips-ecoff: FAIL: SmartMIPS mips-ecoff: FAIL: assembly line numbers mips-ecoff: FAIL: gas/mips/align2 mips-ecoff: FAIL: gas/mips/align2-el mips-ecoff: FAIL: gas/mips/call-nonpic-1 mips-ecoff: FAIL: gas/mips/macro-warn-1 mips-ecoff: FAIL: gas/mips/macro-warn-2 mips-ecoff: FAIL: gas/mips/mips16-vis-1 mips-ecoff: FAIL: gas/mips/vxworks1 mips-ecoff: FAIL: gas/mips/vxworks1-el mips-ecoff: FAIL: gas/mips/vxworks1-xgot mips-ecoff: FAIL: gas/mips/vxworks1-xgot-el mips-ecoff: FAIL: included file with .if 0 wrapped in APP/NO_APP, no final NO_APP, macro in main file mips-ecoff: FAIL: noreorder test mips-elf: FAIL: --localize-hidden test 1 mips-elf: FAIL: Global calls from mips16 mips-elf: FAIL: MIPS eh-frame 3 mips-elf: FAIL: MIPS eh-frame 4 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-00 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-01 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-02 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-03 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-04 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-05 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-10 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-11 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-12 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-13 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-14 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-15 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-20 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-21 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-22 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-23 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-24 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-25 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-30 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-31 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-32 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-33 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-34 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-35 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-40 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-41 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-42 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-43 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-44 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-45 mips-elf: FAIL: ld-mips-elf/attr-gnu-4-51 mips-linux: OK mips64-elf: FAIL: --localize-hidden test 1 mips64-elf: FAIL: Global calls from mips16 mips64-elf: FAIL: MIPS eh-frame 3 mips64-elf: FAIL: MIPS eh-frame 4 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-00 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-01 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-02 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-03 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-04 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-05 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-10 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-11 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-12 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-13 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-14 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-15 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-20 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-21 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-22 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-23 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-24 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-25 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-30 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-31 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-32 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-33 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-34 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-35 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-40 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-41 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-42 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-43 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-44 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-45 mips64-elf: FAIL: ld-mips-elf/attr-gnu-4-51 mmix: FAIL: gas/mmix/fb-2 mmix: FAIL: ld-mmix/sec-7m mn10200-elf: OK mn10300-elf: OK moxie-elf: OK msp430-elf: OK pdp11-dec-aout: OK pj-elf: OK powerpc-elf: OK powerpc64-elf: OK rs6000-ibm-aix6: OK rx-elf: FAIL: --set-section-flags test 1 (sections) rx-elf: FAIL: --sort-section alignment rx-elf: FAIL: --sort-section name rx-elf: FAIL: ALIGNOF rx-elf: FAIL: Compatibility with Renesas's own assembler rx-elf: FAIL: MEMORY rx-elf: FAIL: SORT_BY_ALIGNMENT rx-elf: FAIL: SORT_BY_ALIGNMENT(SORT_BY_ALIGNMENT()) rx-elf: FAIL: SORT_BY_ALIGNMENT(SORT_BY_ALIGNMENT()) --sort-section alignment rx-elf: FAIL: SORT_BY_ALIGNMENT(SORT_BY_ALIGNMENT()) --sort-section name rx-elf: FAIL: SORT_BY_ALIGNMENT(SORT_BY_NAME()) rx-elf: FAIL: SORT_BY_ALIGNMENT(SORT_BY_NAME()) --sort-section alignment rx-elf: FAIL: SORT_BY_ALIGNMENT(SORT_BY_NAME()) --sort-section name rx-elf: FAIL: SORT_BY_NAME(SORT_BY_ALIGNMENT()) rx-elf: FAIL: SORT_BY_NAME(SORT_BY_ALIGNMENT()) --sort-section alignment rx-elf: FAIL: SORT_BY_NAME(SORT_BY_ALIGNMENT()) --sort-section alignment rx-elf: FAIL: SORT_BY_NAME(SORT_BY_NAME()) rx-elf: FAIL: SORT_BY_NAME(SORT_BY_NAME()) --sort-section alignment rx-elf: FAIL: SORT_BY_NAME(SORT_BY_NAME()) --sort-section name rx-elf: FAIL: align rx-elf: FAIL: align1 rx-elf: FAIL: automatic section group a rx-elf: FAIL: check sections 2 rx-elf: FAIL: copy with setting section flags 3 rx-elf: FAIL: elf section5 list rx-elf: FAIL: elf section7 rx-elf: FAIL: gas/rx/abs rx-elf: FAIL: gas/rx/adc rx-elf: FAIL: gas/rx/add rx-elf: FAIL: gas/rx/and rx-elf: FAIL: gas/rx/bclr rx-elf: FAIL: gas/rx/bcnd rx-elf: FAIL: gas/rx/bmcnd rx-elf: FAIL: gas/rx/bnot rx-elf: FAIL: gas/rx/bra rx-elf: FAIL: gas/rx/brk rx-elf: FAIL: gas/rx/bset rx-elf: FAIL: gas/rx/bsr rx-elf: FAIL: gas/rx/btst rx-elf: FAIL: gas/rx/clrpsw rx-elf: FAIL: gas/rx/cmp rx-elf: FAIL: gas/rx/dbt rx-elf: FAIL: gas/rx/div rx-elf: FAIL: gas/rx/divu rx-elf: FAIL: gas/rx/emul rx-elf: FAIL: gas/rx/emulu rx-elf: FAIL: gas/rx/fadd rx-elf: FAIL: gas/rx/fcmp rx-elf: FAIL: gas/rx/fdiv rx-elf: FAIL: gas/rx/fmul rx-elf: FAIL: gas/rx/fsub rx-elf: FAIL: gas/rx/ftoi rx-elf: FAIL: gas/rx/gprel rx-elf: FAIL: gas/rx/int rx-elf: FAIL: gas/rx/itof rx-elf: FAIL: gas/rx/jmp rx-elf: FAIL: gas/rx/jsr rx-elf: FAIL: gas/rx/machi rx-elf: FAIL: gas/rx/maclo rx-elf: FAIL: gas/rx/max rx-elf: FAIL: gas/rx/min rx-elf: FAIL: gas/rx/mov rx-elf: FAIL: gas/rx/movu rx-elf: FAIL: gas/rx/mul rx-elf: FAIL: gas/rx/mulhi rx-elf: FAIL: gas/rx/mullo rx-elf: FAIL: gas/rx/mvfachi rx-elf: FAIL: gas/rx/mvfaclo rx-elf: FAIL: gas/rx/mvfacmi rx-elf: FAIL: gas/rx/mvfc rx-elf: FAIL: gas/rx/mvfcp rx-elf: FAIL: gas/rx/mvtachi rx-elf: FAIL: gas/rx/mvtaclo rx-elf: FAIL: gas/rx/mvtc rx-elf: FAIL: gas/rx/mvtcp rx-elf: FAIL: gas/rx/neg rx-elf: FAIL: gas/rx/nop rx-elf: FAIL: gas/rx/not rx-elf: FAIL: gas/rx/opecp rx-elf: FAIL: gas/rx/or rx-elf: FAIL: gas/rx/pop rx-elf: FAIL: gas/rx/popc rx-elf: FAIL: gas/rx/popm rx-elf: FAIL: gas/rx/push rx-elf: FAIL: gas/rx/pushc rx-elf: FAIL: gas/rx/pushm rx-elf: FAIL: gas/rx/r-bcc rx-elf: FAIL: gas/rx/r-bra rx-elf: FAIL: gas/rx/racw rx-elf: FAIL: gas/rx/revl rx-elf: FAIL: gas/rx/revw rx-elf: FAIL: gas/rx/rmpa rx-elf: FAIL: gas/rx/rolc rx-elf: FAIL: gas/rx/rorc rx-elf: FAIL: gas/rx/rotl rx-elf: FAIL: gas/rx/rotr rx-elf: FAIL: gas/rx/round rx-elf: FAIL: gas/rx/rte rx-elf: FAIL: gas/rx/rtfi rx-elf: FAIL: gas/rx/rts rx-elf: FAIL: gas/rx/rtsd rx-elf: FAIL: gas/rx/sat rx-elf: FAIL: gas/rx/satr rx-elf: FAIL: gas/rx/sbb rx-elf: FAIL: gas/rx/sccnd rx-elf: FAIL: gas/rx/scmpu rx-elf: FAIL: gas/rx/setpsw rx-elf: FAIL: gas/rx/shar rx-elf: FAIL: gas/rx/shll rx-elf: FAIL: gas/rx/shlr rx-elf: FAIL: gas/rx/smovb rx-elf: FAIL: gas/rx/smovf rx-elf: FAIL: gas/rx/smovu rx-elf: FAIL: gas/rx/sstr rx-elf: FAIL: gas/rx/stnz rx-elf: FAIL: gas/rx/stz rx-elf: FAIL: gas/rx/sub rx-elf: FAIL: gas/rx/suntil rx-elf: FAIL: gas/rx/swhile rx-elf: FAIL: gas/rx/tst rx-elf: FAIL: gas/rx/wait rx-elf: FAIL: gas/rx/xchg rx-elf: FAIL: gas/rx/xor rx-elf: FAIL: group section with multiple sections of same name rx-elf: FAIL: include-1 rx-elf: FAIL: label arithmetic with multiple same-name sections rx-elf: FAIL: ld-discard/extern rx-elf: FAIL: ld-discard/start rx-elf: FAIL: ld-discard/static rx-elf: FAIL: ld-elf/merge rx-elf: FAIL: ld-elf/merge2 rx-elf: FAIL: ld-elf/note-2 rx-elf: FAIL: ld-elf/orphan rx-elf: FAIL: ld-elf/orphan-region rx-elf: FAIL: ld-elf/orphan2 rx-elf: FAIL: ld-scripts/align2a rx-elf: FAIL: ld-scripts/align2b rx-elf: FAIL: ld-scripts/default-script1 rx-elf: FAIL: ld-scripts/default-script2 rx-elf: FAIL: ld-scripts/default-script3 rx-elf: FAIL: ld-scripts/default-script4 rx-elf: FAIL: ld-scripts/empty-aligned rx-elf: FAIL: ld-scripts/provide-1 rx-elf: FAIL: ld-scripts/size-1 rx-elf: FAIL: ld-scripts/size-2 rx-elf: FAIL: objcopy --reverse-bytes rx-elf: FAIL: objdump -h rx-elf: FAIL: objdump -r rx-elf: FAIL: objdump -s rx-elf: FAIL: readelf -S rx-elf: FAIL: readelf -p: missing: .*test_string.* rx-elf: FAIL: readelf -r rx-elf: FAIL: relocatable with script rx-elf: FAIL: rgn-over1 (map check) rx-elf: FAIL: rgn-over2 (map check) rx-elf: FAIL: rgn-over3 (map check) rx-elf: FAIL: rgn-over4 (map check) rx-elf: FAIL: rgn-over5 (map check) rx-elf: FAIL: rgn-over6 (map check) rx-elf: FAIL: rgn-over7 (map check) rx-elf: FAIL: script rx-elf: FAIL: semi rx-elf: FAIL: size -A rx-elf: FAIL: weak symbols rx-elf: FAIL: weak undefined symbols s390-linux: OK score-elf: FAIL: gas/score/branch_32 score-elf: FAIL: gas/score/branch_32-lt score-elf: FAIL: ld-elf/orphan4 sh4-elf: OK sh64-elf: OK sparc-elf: OK sparc64-elf: OK spu-elf: OK tic4x-coff: FAIL: .strings tests tic4x-coff: FAIL: bad byte directive tic4x-coff: FAIL: include-1 tic4x-coff: FAIL: ld-scripts/data tic4x-coff: FAIL: ld-scripts/size-1 tic54x-coff: FAIL: -l: test tic54x-coff: FAIL: bad byte directive tic54x-coff: FAIL: c54x cons tests tic54x-coff: FAIL: c54x cons tests, w/extended addressing tic54x-coff: FAIL: c54x field directive tic54x-coff: FAIL: c54x set/equ directive tic54x-coff: FAIL: c54x subsyms tic54x-coff: FAIL: include-1 tic54x-coff: FAIL: ld-scripts/data tic54x-coff: FAIL: ld-scripts/default-script1 tic54x-coff: FAIL: ld-scripts/default-script2 tic54x-coff: FAIL: ld-scripts/default-script3 tic54x-coff: FAIL: ld-scripts/default-script4 tic54x-coff: FAIL: ld-scripts/empty-address-1 tic54x-coff: FAIL: ld-scripts/empty-address-2a tic54x-coff: FAIL: ld-scripts/empty-address-2b tic54x-coff: FAIL: ld-scripts/provide-1 tic54x-coff: FAIL: ld-scripts/provide-2 tic54x-coff: FAIL: ld-scripts/size-1 tic6x-elf: OK tx39-elf: OK v850-elf: OK vax-netbsdelf: OK x86_64-pc-linux-gnu: OK x86_64-w64-mingw32: OK xstormy16-elf: OK xtensa-elf: OK z8k-coff: OK ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-01 15:14 ` Release 2.21 - Soon Tristan Gingold @ 2010-12-01 15:18 ` H.J. Lu 2010-12-02 15:03 ` Tristan Gingold 2010-12-03 17:43 ` Steve Ellcey 2010-12-06 17:40 ` H.J. Lu 2 siblings, 1 reply; 40+ messages in thread From: H.J. Lu @ 2010-12-01 15:18 UTC (permalink / raw) To: Tristan Gingold; +Cc: binutils On Wed, Dec 1, 2010 at 7:13 AM, Tristan Gingold <gingold@adacore.com> wrote: > Hi, > > here are my latest results from the release branch. > The most worrying issues (arm-eabi) are now fixed, and most of the targets are in a good state. > (I added a some targets compared to the previous tests results in this report). > > I plan to do the 2.21 release very soon... > Linker plugin doesn't really work: http://sourceware.org/bugzilla/show_bug.cgi?id=12248 I am working on a fix. It will require plugin API change. -- H.J. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-01 15:18 ` H.J. Lu @ 2010-12-02 15:03 ` Tristan Gingold 0 siblings, 0 replies; 40+ messages in thread From: Tristan Gingold @ 2010-12-02 15:03 UTC (permalink / raw) To: H.J. Lu; +Cc: binutils On Dec 1, 2010, at 4:18 PM, H.J. Lu wrote: > On Wed, Dec 1, 2010 at 7:13 AM, Tristan Gingold <gingold@adacore.com> wrote: >> Hi, >> >> here are my latest results from the release branch. >> The most worrying issues (arm-eabi) are now fixed, and most of the targets are in a good state. >> (I added a some targets compared to the previous tests results in this report). >> >> I plan to do the 2.21 release very soon... >> > > Linker plugin doesn't really work: > > http://sourceware.org/bugzilla/show_bug.cgi?id=12248 > > I am working on a fix. It will require plugin API change. Thanks. From the whole discussion thread, it looks like there is no obvious and agreed fix. So, I propose to do the 2.21 release soon (I plan to do it on Monday), and if necessary backport the fix when done. Tristan. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-01 15:14 ` Release 2.21 - Soon Tristan Gingold 2010-12-01 15:18 ` H.J. Lu @ 2010-12-03 17:43 ` Steve Ellcey 2010-12-03 18:08 ` Maciej W. Rozycki 2010-12-06 17:40 ` H.J. Lu 2 siblings, 1 reply; 40+ messages in thread From: Steve Ellcey @ 2010-12-03 17:43 UTC (permalink / raw) To: Tristan Gingold; +Cc: binutils, Richard Sandiford, Maciej W. Rozycki FYI: I am currently looking at a gas problem on IA64 HP-UX. I noticed that I am getting C++ failures in my GCC build/test runs and it looks like it is due to one of the changes made to the gnu assembler by Richard Sandiford or Maciej W. Rozycki on December 1 or 2. I haven't really got a good handle on the problem yet, but when running the C++ tests using the latest assembler I get a lot of messages like: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc FAIL: 20_util/allocator/8230.cc execution test The failures always involve 'terminate called after throwing....' and go away if I use an older assembler. I would like to understand what is happening and fix it before 2.21 is released. Steve Ellcey sje@cup.hp.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-03 17:43 ` Steve Ellcey @ 2010-12-03 18:08 ` Maciej W. Rozycki 2010-12-03 18:26 ` Steve Ellcey 2010-12-03 21:11 ` Steve Ellcey 0 siblings, 2 replies; 40+ messages in thread From: Maciej W. Rozycki @ 2010-12-03 18:08 UTC (permalink / raw) To: Steve Ellcey; +Cc: Tristan Gingold, binutils, Richard Sandiford On Fri, 3 Dec 2010, Steve Ellcey wrote: > FYI: I am currently looking at a gas problem on IA64 HP-UX. I noticed > that I am getting C++ failures in my GCC build/test runs and it looks > like it is due to one of the changes made to the gnu assembler by > Richard Sandiford or Maciej W. Rozycki on December 1 or 2. I haven't > really got a good handle on the problem yet, but when running the C++ > tests using the latest assembler I get a lot of messages like: > > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > FAIL: 20_util/allocator/8230.cc execution test > > The failures always involve 'terminate called after throwing....' and > go away if I use an older assembler. > > I would like to understand what is happening and fix it before 2.21 > is released. My December changes are not intended to go into 2.21 and are not on the 2.21 branch -- are you seeing the problem with the release branch too? Maciej ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-03 18:08 ` Maciej W. Rozycki @ 2010-12-03 18:26 ` Steve Ellcey 2010-12-04 0:44 ` Maciej W. Rozycki 2010-12-03 21:11 ` Steve Ellcey 1 sibling, 1 reply; 40+ messages in thread From: Steve Ellcey @ 2010-12-03 18:26 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Tristan Gingold, binutils, Richard Sandiford On Fri, 2010-12-03 at 18:08 +0000, Maciej W. Rozycki wrote: > > I would like to understand what is happening and fix it before 2.21 > > is released. > > My December changes are not intended to go into 2.21 and are not on the > 2.21 branch -- are you seeing the problem with the release branch too? > > Maciej OK, I thought 2.21 was going to be made from ToT. I haven't tried the release branch but I assume it is OK since it was only around Dec 2 that I started seeing this problem on the ToT binutils. Steve Ellcey sje@cup.hp.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-03 18:26 ` Steve Ellcey @ 2010-12-04 0:44 ` Maciej W. Rozycki 0 siblings, 0 replies; 40+ messages in thread From: Maciej W. Rozycki @ 2010-12-04 0:44 UTC (permalink / raw) To: Steve Ellcey; +Cc: Tristan Gingold, binutils, Richard Sandiford On Fri, 3 Dec 2010, Steve Ellcey wrote: > OK, I thought 2.21 was going to be made from ToT. I haven't tried the > release branch but I assume it is OK since it was only around Dec 2 that > I started seeing this problem on the ToT binutils. I have committed a fix to the problem you observed on HEAD now (this was also PR gas/12282), but please do try the release branch (binutils-2_21-branch) if you are concerned about the upcoming release -- it's about the last chance to do so. Maciej ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-03 18:08 ` Maciej W. Rozycki 2010-12-03 18:26 ` Steve Ellcey @ 2010-12-03 21:11 ` Steve Ellcey 2010-12-04 0:55 ` Maciej W. Rozycki 1 sibling, 1 reply; 40+ messages in thread From: Steve Ellcey @ 2010-12-03 21:11 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Tristan Gingold, binutils, Richard Sandiford On Fri, 2010-12-03 at 18:08 +0000, Maciej W. Rozycki wrote: > My December changes are not intended to go into 2.21 and are not on the > 2.21 branch -- are you seeing the problem with the release branch too? > > Maciej Maciej, I have submitted a binutils defect report for this problem, http://sourceware.org/bugzilla/show_bug.cgi?id=12287, and included what information I have so far. I can show the problem using a small C++ program and their are two new failures in the GAS testsuite that show up with this change. The problem definitely starts with this checkin: 2010-12-01 Maciej W. Rozycki <macro@codesourcery.com> * symbols.h (dot_symbol): New declaration. (dot_symbol_init): New prototype. * symbols.c (dot_symbol): New variable. (symbol_clone): Assert it's not dot_symbol being cloned. (dot_symbol_init): New function. (symbol_clone_if_forward_ref): Create a new temporary symbol when trying to clone dot_symbol. * expr.c (current_location): Refer to dot_symbol instead of making a new temporary symbol. * read.c (read_a_source_file): Update dot_symbol as we go. * as.c (main): Call dot_symbol_init. But I don't know what is causing the change. Steve Ellcey sje@cup.hp.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-03 21:11 ` Steve Ellcey @ 2010-12-04 0:55 ` Maciej W. Rozycki 2010-12-06 10:46 ` Chris Smith 2010-12-06 16:36 ` Steve Ellcey 0 siblings, 2 replies; 40+ messages in thread From: Maciej W. Rozycki @ 2010-12-04 0:55 UTC (permalink / raw) To: Steve Ellcey; +Cc: Tristan Gingold, binutils, Richard Sandiford Steve, > I have submitted a binutils defect report for this problem, > http://sourceware.org/bugzilla/show_bug.cgi?id=12287, and included what > information I have so far. I can show the problem using a small C++ > program and their are two new failures in the GAS testsuite that show up > with this change. The problem definitely starts with this checkin: > > 2010-12-01 Maciej W. Rozycki <macro@codesourcery.com> > > * symbols.h (dot_symbol): New declaration. > (dot_symbol_init): New prototype. > * symbols.c (dot_symbol): New variable. > (symbol_clone): Assert it's not dot_symbol being cloned. > (dot_symbol_init): New function. > (symbol_clone_if_forward_ref): Create a new temporary symbol > when trying to clone dot_symbol. > * expr.c (current_location): Refer to dot_symbol instead of > making a new temporary symbol. > * read.c (read_a_source_file): Update dot_symbol as we go. > * as.c (main): Call dot_symbol_init. > > But I don't know what is causing the change. Let me know if the problem you saw has gone now and I'll mark your report as a duplicate of PR gas/12282 if so. The change affected config/tc-arm.c, config/tc-ia64.c and cgen.c, so the platforms that suffered were ARM and IA-64 as well as those using CGEN; hopefully they all have been cured now. Sorry about the original mess-up. Maciej ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-04 0:55 ` Maciej W. Rozycki @ 2010-12-06 10:46 ` Chris Smith 2010-12-06 14:02 ` Tristan Gingold 2010-12-06 16:36 ` Steve Ellcey 1 sibling, 1 reply; 40+ messages in thread From: Chris Smith @ 2010-12-06 10:46 UTC (permalink / raw) To: binutils Can I request that Arnold Metselaar's patch for bug 12269 (coff-z80) is applied to the 2.21 branch, so that it makes the next stable release. Many thanks, Chris ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-06 10:46 ` Chris Smith @ 2010-12-06 14:02 ` Tristan Gingold 0 siblings, 0 replies; 40+ messages in thread From: Tristan Gingold @ 2010-12-06 14:02 UTC (permalink / raw) To: Chris Smith; +Cc: binutils On Dec 6, 2010, at 11:46 AM, Chris Smith wrote: > Can I request that Arnold Metselaar's patch for bug 12269 (coff-z80) is applied > to the 2.21 branch, so that it makes the next stable release. Yes, I have just acked this request. Tristan. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-04 0:55 ` Maciej W. Rozycki 2010-12-06 10:46 ` Chris Smith @ 2010-12-06 16:36 ` Steve Ellcey 2010-12-06 17:35 ` Maciej W. Rozycki 1 sibling, 1 reply; 40+ messages in thread From: Steve Ellcey @ 2010-12-06 16:36 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Tristan Gingold, binutils, Richard Sandiford On Sat, 2010-12-04 at 00:55 +0000, Maciej W. Rozycki wrote: > Steve, > > Let me know if the problem you saw has gone now and I'll mark your report > as a duplicate of PR gas/12282 if so. The change affected > config/tc-arm.c, config/tc-ia64.c and cgen.c, so the platforms that > suffered were ARM and IA-64 as well as those using CGEN; hopefully they > all have been cured now. Sorry about the original mess-up. > > Maciej Yes, the problem seems to be fixed now. Thanks for fixing the problem so promptly and feel free to close out the defect I opened. Steve Ellcey sje@cup.hp.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-06 16:36 ` Steve Ellcey @ 2010-12-06 17:35 ` Maciej W. Rozycki 0 siblings, 0 replies; 40+ messages in thread From: Maciej W. Rozycki @ 2010-12-06 17:35 UTC (permalink / raw) To: Steve Ellcey; +Cc: Tristan Gingold, binutils, Richard Sandiford On Mon, 6 Dec 2010, Steve Ellcey wrote: > Yes, the problem seems to be fixed now. Thanks for fixing the problem > so promptly and feel free to close out the defect I opened. OK, thanks and you are welcome. I have closed the bug now. Maciej ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-01 15:14 ` Release 2.21 - Soon Tristan Gingold 2010-12-01 15:18 ` H.J. Lu 2010-12-03 17:43 ` Steve Ellcey @ 2010-12-06 17:40 ` H.J. Lu 2010-12-07 8:24 ` Tristan Gingold 2 siblings, 1 reply; 40+ messages in thread From: H.J. Lu @ 2010-12-06 17:40 UTC (permalink / raw) To: Tristan Gingold; +Cc: binutils On Wed, Dec 1, 2010 at 7:13 AM, Tristan Gingold <gingold@adacore.com> wrote: > Hi, > > here are my latest results from the release branch. > The most worrying issues (arm-eabi) are now fixed, and most of the targets are in a good state. > (I added a some targets compared to the previous tests results in this report). > > I plan to do the 2.21 release very soon... I'd like to backport http://sourceware.org/ml/binutils/2010-11/msg00217.html to 2.21. Thanks. H.J. ---- ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Release 2.21 - Soon... 2010-12-06 17:40 ` H.J. Lu @ 2010-12-07 8:24 ` Tristan Gingold 0 siblings, 0 replies; 40+ messages in thread From: Tristan Gingold @ 2010-12-07 8:24 UTC (permalink / raw) To: H.J. Lu; +Cc: binutils On Dec 6, 2010, at 6:40 PM, H.J. Lu wrote: > On Wed, Dec 1, 2010 at 7:13 AM, Tristan Gingold <gingold@adacore.com> wrote: >> Hi, >> >> here are my latest results from the release branch. >> The most worrying issues (arm-eabi) are now fixed, and most of the targets are in a good state. >> (I added a some targets compared to the previous tests results in this report). >> >> I plan to do the 2.21 release very soon... > > I'd like to backport > > http://sourceware.org/ml/binutils/2010-11/msg00217.html > > to 2.21. Ok. ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2010-12-08 16:02 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-11-19 11:45 Release 2.21 (ready ?) Tristan Gingold 2010-11-19 16:11 ` Doug Kwan (關振德) 2010-11-20 0:02 ` Ian Lance Taylor 2010-11-19 17:10 ` Joel Sherrill 2010-11-23 16:32 ` Release 2.21 - Pre tests Tristan Gingold 2010-11-23 18:54 ` Matthias Klose 2010-11-24 9:28 ` Richard Sandiford 2010-11-24 14:40 ` Matthew Gretton-Dann 2010-11-25 1:40 ` Alan Modra 2010-11-25 9:49 ` Matthew Gretton-Dann 2010-11-25 9:55 ` Tristan Gingold 2010-11-25 15:16 ` Matthew Gretton-Dann 2010-11-23 21:04 ` Ian Lance Taylor 2010-11-23 21:17 ` H.J. Lu 2010-11-23 23:00 ` Ian Lance Taylor 2010-11-23 23:09 ` H.J. Lu 2010-11-24 8:23 ` Tristan Gingold 2010-12-01 0:21 ` Ian Lance Taylor 2010-12-01 11:03 ` Tristan Gingold 2010-12-01 16:53 ` Ian Lance Taylor 2010-12-08 10:47 ` Tristan Gingold 2010-12-08 15:55 ` Ian Lance Taylor 2010-12-08 16:02 ` Tristan Gingold 2010-11-24 9:53 ` Matthew Gretton-Dann 2010-11-24 9:56 ` Tristan Gingold 2010-12-01 15:14 ` Release 2.21 - Soon Tristan Gingold 2010-12-01 15:18 ` H.J. Lu 2010-12-02 15:03 ` Tristan Gingold 2010-12-03 17:43 ` Steve Ellcey 2010-12-03 18:08 ` Maciej W. Rozycki 2010-12-03 18:26 ` Steve Ellcey 2010-12-04 0:44 ` Maciej W. Rozycki 2010-12-03 21:11 ` Steve Ellcey 2010-12-04 0:55 ` Maciej W. Rozycki 2010-12-06 10:46 ` Chris Smith 2010-12-06 14:02 ` Tristan Gingold 2010-12-06 16:36 ` Steve Ellcey 2010-12-06 17:35 ` Maciej W. Rozycki 2010-12-06 17:40 ` H.J. Lu 2010-12-07 8:24 ` Tristan Gingold
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).