Release 2.21 (ready ?)

Release 2.21 (ready ?)

[Tristan Gingold]

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.

Re: Release 2.21 (ready ?)

[Doug Kwan (關振德)]

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

Re: Release 2.21 (ready ?)

[Joel Sherrill]

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

Re: Release 2.21 (ready ?)

[Ian Lance Taylor]

"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

Release 2.21 - Pre tests

[Tristan Gingold]

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

Re: Release 2.21 - Pre tests

[Matthias Klose]

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

Re: Release 2.21 - Pre tests

[Ian Lance Taylor]

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

Re: Release 2.21 - Pre tests

[H.J. Lu]

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.

Re: Release 2.21 - Pre tests

[Ian Lance Taylor]

"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

Re: Release 2.21 - Pre tests

[H.J. Lu]

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.

Re: Release 2.21 - Pre tests

[Tristan Gingold]

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.

Re: Release 2.21 - Pre tests

[Richard Sandiford]

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}}

Re: Release 2.21 - Pre tests

[Matthew Gretton-Dann]

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

Re: Release 2.21 - Pre tests

[Tristan Gingold]

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.

Re: Release 2.21 - Pre tests

[Matthew Gretton-Dann]

[-- 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}}

Re: Release 2.21 - Pre tests

[Alan Modra]

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

Re: Release 2.21 - Pre tests

[Matthew Gretton-Dann]

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

Re: Release 2.21 - Pre tests

[Tristan Gingold]

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.

Re: Release 2.21 - Pre tests

[Matthew Gretton-Dann]

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

Re: Release 2.21 - Pre tests

[Ian Lance Taylor]

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

Re: Release 2.21 - Pre tests

[Tristan Gingold]

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.

Release 2.21 - Soon...

[Tristan Gingold]

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

Re: Release 2.21 - Soon...

[H.J. Lu]

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.

Re: Release 2.21 - Pre tests

[Ian Lance Taylor]

[-- 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

Re: Release 2.21 - Soon...

[Tristan Gingold]

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.

Re: Release 2.21 - Soon...

[Steve Ellcey]

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

Re: Release 2.21 - Soon...

[Maciej W. Rozycki]

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

Re: Release 2.21 - Soon...

[Steve Ellcey]

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

Re: Release 2.21 - Soon...

[Steve Ellcey]

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

Re: Release 2.21 - Soon...

[Maciej W. Rozycki]

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

Re: Release 2.21 - Soon...

[Maciej W. Rozycki]

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

Re: Release 2.21 - Soon...

[Chris Smith]

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

Re: Release 2.21 - Soon...

[Tristan Gingold]

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.

Re: Release 2.21 - Soon...

[Steve Ellcey]

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

Re: Release 2.21 - Soon...

[Maciej W. Rozycki]

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

Re: Release 2.21 - Soon...

[H.J. Lu]

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

Re: Release 2.21 - Soon...

[Tristan Gingold]

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.

Re: Release 2.21 - Pre tests

[Tristan Gingold]

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.

Re: Release 2.21 - Pre tests

[Ian Lance Taylor]

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

Re: Release 2.21 - Pre tests

[Tristan Gingold]

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.