Release 2.23

Release 2.23

[Tristan Gingold]

Hi,

I was rather busy before the summer and hence I didn't take the time to create a 2.22.1 release.
I can however schedule a release for this summer.  So my plan is:

* I will create the 2.23 branch this week and creating a pre-release just after.

* I plan to do the 2.23 release at the end of August or at the beginning of September (unless there is a blocking issue).

So, if you have big or large changes, it would be nice to wait a little bit.  And as usual, do not hesitate to test your favourite platforms.

Tristan.

Re: Release 2.23

[Matthias Klose]

On 23.07.2012 14:40, Tristan Gingold wrote:
> Hi,
> 
> I was rather busy before the summer and hence I didn't take the time to create a 2.22.1 release.
> I can however schedule a release for this summer.  So my plan is:
> 
> * I will create the 2.23 branch this week and creating a pre-release just after.
> 
> * I plan to do the 2.23 release at the end of August or at the beginning of September (unless there is a blocking issue).
> 
> So, if you have big or large changes, it would be nice to wait a little bit.  And as usual, do not hesitate to test your favourite platforms.

what are the chances to get the recently submitted aarch64 target backported to
the branch once it is accepted for the trunk?

  Matthias

Re: Release 2.23

[Richard Earnshaw]

On 31/07/12 21:28, Matthias Klose wrote:
> On 23.07.2012 14:40, Tristan Gingold wrote:
>> Hi,
>>
>> I was rather busy before the summer and hence I didn't take the time to create a 2.22.1 release.
>> I can however schedule a release for this summer.  So my plan is:
>>
>> * I will create the 2.23 branch this week and creating a pre-release just after.
>>
>> * I plan to do the 2.23 release at the end of August or at the beginning of September (unless there is a blocking issue).
>>
>> So, if you have big or large changes, it would be nice to wait a little bit.  And as usual, do not hesitate to test your favourite platforms.
> 
> what are the chances to get the recently submitted aarch64 target backported to
> the branch once it is accepted for the trunk?
> 
>   Matthias
> 
> 
> 
> 

Doing this in August seems rather early.  I thought binutils was
normally released around late October.

I was certainly hoping we'd get the AArch64 code into 2.23.

R.

Re: Release 2.23

[Tristan Gingold]

On Jul 31, 2012, at 10:28 PM, Matthias Klose wrote:

> On 23.07.2012 14:40, Tristan Gingold wrote:
>> Hi,
>> 
>> I was rather busy before the summer and hence I didn't take the time to create a 2.22.1 release.
>> I can however schedule a release for this summer.  So my plan is:
>> 
>> * I will create the 2.23 branch this week and creating a pre-release just after.
>> 
>> * I plan to do the 2.23 release at the end of August or at the beginning of September (unless there is a blocking issue).
>> 
>> So, if you have big or large changes, it would be nice to wait a little bit.  And as usual, do not hesitate to test your favourite platforms.
> 
> what are the chances to get the recently submitted aarch64 target backported to
> the branch once it is accepted for the trunk?

Looks like some of you would like to have aarch64 in 2.23.
As it might change the schedule, I'd like to understand the reasons for having aarch64 in 2.23

Tristan.

Re: Release 2.23

[Richard Earnshaw]

On 01/08/12 14:58, Tristan Gingold wrote:
> 
> On Jul 31, 2012, at 10:28 PM, Matthias Klose wrote:
> 
>> On 23.07.2012 14:40, Tristan Gingold wrote:
>>> Hi,
>>>
>>> I was rather busy before the summer and hence I didn't take the time to create a 2.22.1 release.
>>> I can however schedule a release for this summer.  So my plan is:
>>>
>>> * I will create the 2.23 branch this week and creating a pre-release just after.
>>>
>>> * I plan to do the 2.23 release at the end of August or at the beginning of September (unless there is a blocking issue).
>>>
>>> So, if you have big or large changes, it would be nice to wait a little bit.  And as usual, do not hesitate to test your favourite platforms.
>>
>> what are the chances to get the recently submitted aarch64 target backported to
>> the branch once it is accepted for the trunk?
> 
> Looks like some of you would like to have aarch64 in 2.23.
> As it might change the schedule, I'd like to understand the reasons for having aarch64 in 2.23
> 
> Tristan.
> 

Because binutils is a key enabler and rolling this out into various
distros is significantly harder if it isn't in a major release.  In
particular we're targetting GCC-4.8 for the main compiler support and
that needs a binutils that supports it.

Why are we planning a binutils release so much earlier this year than we
have done for the previous 3 or 4 years (at least)?

R.

Re: Release 2.23

[Tristan Gingold]

On Aug 1, 2012, at 4:02 PM, Richard Earnshaw wrote:
>> As it might change the schedule, I'd like to understand the reasons for having aarch64 in 2.23

> Because binutils is a key enabler and rolling this out into various
> distros is significantly harder if it isn't in a major release.  In
> particular we're targetting GCC-4.8 for the main compiler support and
> that needs a binutils that supports it.

Looks like a good rational, but this opens other possibilities:

* would it be acceptable to add aarch64 only in 2.23.1 (in case the submission takes time) ?

* if aarch64 comes only with 2.24, what would be the ideal schedule for the release ?

> Why are we planning a binutils release so much earlier this year than we
> have done for the previous 3 or 4 years (at least)?

I plan a release when the trunk is relatively quiet and when I have enough time for it.

Traditionally, the major release is planed for end of summer but we often slip a while :-)

Tristan.

Re: Release 2.23

[Richard Earnshaw]

On 01/08/12 15:35, Tristan Gingold wrote:
> 
> On Aug 1, 2012, at 4:02 PM, Richard Earnshaw wrote:
>>> As it might change the schedule, I'd like to understand the reasons for having aarch64 in 2.23
> 
>> Because binutils is a key enabler and rolling this out into various
>> distros is significantly harder if it isn't in a major release.  In
>> particular we're targetting GCC-4.8 for the main compiler support and
>> that needs a binutils that supports it.
> 
> Looks like a good rational, but this opens other possibilities:
> 
> * would it be acceptable to add aarch64 only in 2.23.1 (in case the submission takes time) ?

Perhaps, if we can guarantee that it's timely enough.

> 
> * if aarch64 comes only with 2.24, what would be the ideal schedule for the release ?
> 

November :-)

>> Why are we planning a binutils release so much earlier this year than we
>> have done for the previous 3 or 4 years (at least)?
> 
> I plan a release when the trunk is relatively quiet and when I have enough time for it.
> 
> Traditionally, the major release is planed for end of summer but we often slip a while :-)

So why not this time? ;-)

Looking at the review feedback so far, there's very little that we
wouldn't expect to address before the end of August.

R.

Re: Release 2.23

[Maciej W. Rozycki]

Tristan,

 FYI, I've got quite a bunch of bug fixes I'd like to push before the 
upcoming release, some of which affect all targets.  I hope to get them 
all posted by the end of this week, but as usually with such pieces 
something may pop up unexpectedly at the last moment in final testing so 
this may slip.

  Maciej

Re: Release 2.23

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 800 bytes --]

On Wednesday 01 August 2012 10:35:11 Tristan Gingold wrote:
> On Aug 1, 2012, at 4:02 PM, Richard Earnshaw wrote:
> >> As it might change the schedule, I'd like to understand the reasons for
> >> having aarch64 in 2.23
> > 
> > Because binutils is a key enabler and rolling this out into various
> > distros is significantly harder if it isn't in a major release.  In
> > particular we're targetting GCC-4.8 for the main compiler support and
> > that needs a binutils that supports it.
> 
> Looks like a good rational, but this opens other possibilities:
> 
> * would it be acceptable to add aarch64 only in 2.23.1 (in case the
> submission takes time) ?

that'd be my preference -- let's get 2.23 now, and when aarch64 is finally done 
& merged, we can do a 2.23.1 follow up
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Release 2.23

[nick clifton]

Hi Tristan,

> Looks like some of you would like to have aarch64 in 2.23.
> As it might change the schedule, I'd like to understand the reasons for having aarch64 in 2.23

I would like to see the aarch64 port in 2.23 so that it can accompany 
the next gcc release (4.8) which is almost certain to include the gcc 
aarch64 port.

Cheers
   Nick

Re: Release 2.23

[Tristan Gingold]

On Aug 1, 2012, at 4:39 PM, Richard Earnshaw wrote:
> 
> Looking at the review feedback so far, there's very little that we
> wouldn't expect to address before the end of August.

Great.  So I still plan the 2.23 release for end of August.  If aarch64 can go in the trunk before end of August, please backport it to the release branch.  Otherwise, we will review the release plan.

I will be away until August 20, so I let maintainer decide wether any backport is appropriate or not.

Tristan.

Release 2.23: Ping

[Tristan Gingold]

Hi,

as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like to thanks for doing this timely.

Is there any patch that need to be in the 2.23 release ?  Please, reply quickly as I'd like to do the release soon.

Thanks in advance,
Tristan.

Re: Release 2.23: Ping

[Jan Beulich]

>>> On 31.08.12 at 16:34, Tristan Gingold <gingold@adacore.com> wrote:
> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like 
> to thanks for doing this timely.
> 
> Is there any patch that need to be in the 2.23 release ?  Please, reply 
> quickly as I'd like to do the release soon.

I would generally have hoped for some or all of the x86 gas
fixes I committed lately to make it in there, but that's clearly
a decision to be taken between you and H.J.

The one that I'd consider most important (and least obvious,
since not under gas/) is this one:

2012-07-31  Jan Beulich <jbeulich@suse.com>

	* i386-opc.tbl (vmovntdqa): Move up into 256-bit integer AVX2
	instruction group. Mark as requiring AVX2.
	* i386-tbl.h: Re-generate.

Jan

Re: Release 2.23: Ping

[Tristan Gingold]

On Aug 31, 2012, at 4:43 PM, Jan Beulich wrote:

>>>> On 31.08.12 at 16:34, Tristan Gingold <gingold@adacore.com> wrote:
>> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like 
>> to thanks for doing this timely.
>> 
>> Is there any patch that need to be in the 2.23 release ?  Please, reply 
>> quickly as I'd like to do the release soon.
> 
> I would generally have hoped for some or all of the x86 gas
> fixes I committed lately to make it in there, but that's clearly
> a decision to be taken between you and H.J.

I let H.J. decides.

> The one that I'd consider most important (and least obvious,
> since not under gas/) is this one:
> 
> 2012-07-31  Jan Beulich <jbeulich@suse.com>
> 
> 	* i386-opc.tbl (vmovntdqa): Move up into 256-bit integer AVX2
> 	instruction group. Mark as requiring AVX2.
> 	* i386-tbl.h: Re-generate.

Thank you for the quick reply,
Tristan.

Re: Release 2.23: Ping

[Mike Frysinger]

On Fri, Aug 31, 2012 at 10:34 AM, Tristan Gingold wrote:
> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like to thanks for doing this timely.
>
> Is there any patch that need to be in the 2.23 release ?  Please, reply quickly as I'd like to do the release soon.

can we get this merged to the branch (it's already in gcc and HEAD):
PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes
-mike

Re: Release 2.23: Ping

[Tristan Gingold]

On Sep 1, 2012, at 12:00 AM, Maciej W. Rozycki wrote:

> Tristan,
> 
>> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd
>> like to thanks for doing this timely.
> 
> Has the 2.23 branch been already created?

Yes.

>  Did I miss anything?

At least the snapshot announcement:

> 
> I have just created the 2.23 branch and uploded prerelease 2.22.90 at:
> ftp://sourceware.org/pub/binutils/snapshots/binutils-2.22.90.tar.bz2


>  I'm 
> asking seriously -- the list server seems to be playing tricks with me, I 
> only received one of the replies to your e-mail in this thread and I had 
> to poke at the server to send me the rest as a digest, hmm...
> 
>> Is there any patch that need to be in the 2.23 release ?  Please, reply
>> quickly as I'd like to do the release soon.
> 
> Well, if the branch was created before last Tuesday, then I'd like my 
> export class bug fixes to be included, specifically these:
> 
> http://sourceware.org/ml/binutils/2012-08/msg00159.html
> http://sourceware.org/ml/binutils/2012-08/msg00160.html
> http://sourceware.org/ml/binutils/2012-08/msg00161.html
> 
> If it was even before Aug 13th, then I'd like to see all the bug fixes I 
> pushed recently between the time the branch was created and now.  This 
> trivial documentation fix:
> 
> 2012-08-31  Maciej W. Rozycki  <macro@codesourcery.com>
> 
> 	* doc/c-mips.texi (MIPS Opts): Correct a typo in the -mips5
> 	option.
> 
> would then be the icing on the cake ;) -- we want our user documentation 
> to be always perfectly accurate, don't we?

The branch was created in July, so you need to backport all these patches.
I can take care of that, providing you sent me the url of the binutils-cvs@ messages.

Thanks,
Tristan.

Re: Release 2.23: Ping

[Tristan Gingold]

On Aug 31, 2012, at 7:44 PM, Mike Frysinger wrote:

> On Fri, Aug 31, 2012 at 10:34 AM, Tristan Gingold wrote:
>> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like to thanks for doing this timely.
>> 
>> Is there any patch that need to be in the 2.23 release ?  Please, reply quickly as I'd like to do the release soon.
> 
> can we get this merged to the branch (it's already in gcc and HEAD):
> PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes

Can you send me the url of the commit mail ?  That would help me.

Thanks,
Tristan.

> -mike

Re: Release 2.23: Ping

[Maciej W. Rozycki]

On Mon, 3 Sep 2012, Tristan Gingold wrote:

> >  Did I miss anything?
> 
> At least the snapshot announcement:
> 
> > 
> > I have just created the 2.23 branch and uploded prerelease 2.22.90 at:
> > ftp://sourceware.org/pub/binutils/snapshots/binutils-2.22.90.tar.bz2

 Umm...

> The branch was created in July, so you need to backport all these patches.
> I can take care of that, providing you sent me the url of the 
> binutils-cvs@ messages.

 Hmm, I would like to get included at least these:

http://sourceware.org/ml/binutils-cvs/2012-07/msg00139.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00002.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00006.html

(I suggest combining the above three into one; non-MIPS clean-ups from the 
second can be discarded as far as I'm concerned)

http://sourceware.org/ml/binutils-cvs/2012-08/msg00027.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00028.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00029.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00030.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00044.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00049.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00050.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00084.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00085.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00091.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00092.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00190.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00191.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00209.html

and these would be good to have too:

http://sourceware.org/ml/binutils-cvs/2012-08/msg00045.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00046.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00047.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00051.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00052.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00069.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00086.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00093.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00106.html
http://sourceware.org/ml/binutils-cvs/2012-08/msg00192.html

the latters including in particular test suite coverage for some of the 
changes from the first set (unfortunately the dependencies require pulling 
much more than the minimal required set).  I've dropped some minor updates 
that I made in that period.  Overall I worked on the submissions in the 
first half of August with the explicit intent to have them included in 
2.23, sigh...

 Thanks for your offer WRT applying these -- do you have any way to 
process these messages automatically?  Otherwise it might perhaps be 
easier if I replayed the original commits on binutils-2_23-branch from the 
original patches.  WDYT?

  Maciej

Re: Release 2.23: Ping

[Maciej W. Rozycki]

Tristan,

> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd 
> like to thanks for doing this timely.
> 
> Is there any patch that need to be in the 2.23 release ?  Please, reply 
> quickly as I'd like to do the release soon.

 Here's a critical VAX fix I'd like to see in the release:

http://sourceware.org/ml/binutils-cvs/2012-08/msg00036.html

  Maciej

Re: Release 2.23: Ping

[Tristan Gingold]

On Sep 3, 2012, at 5:06 PM, Maciej W. Rozycki wrote:

> On Mon, 3 Sep 2012, Tristan Gingold wrote:
> 
>>> Did I miss anything?
>> 
>> At least the snapshot announcement:
>> 
>>> 
>>> I have just created the 2.23 branch and uploded prerelease 2.22.90 at:
>>> ftp://sourceware.org/pub/binutils/snapshots/binutils-2.22.90.tar.bz2
> 
> Umm...
> 
>> The branch was created in July, so you need to backport all these patches.
>> I can take care of that, providing you sent me the url of the 
>> binutils-cvs@ messages.
> 
> Hmm, I would like to get included at least these:
> 
> http://sourceware.org/ml/binutils-cvs/2012-07/msg00139.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00002.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00006.html
> 
> (I suggest combining the above three into one; non-MIPS clean-ups from the 
> second can be discarded as far as I'm concerned)
> 
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00027.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00028.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00029.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00030.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00044.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00049.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00050.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00084.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00085.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00091.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00092.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00190.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00191.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00209.html
> 
> and these would be good to have too:
> 
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00045.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00046.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00047.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00051.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00052.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00069.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00086.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00093.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00106.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00192.html
> 
> the latters including in particular test suite coverage for some of the 
> changes from the first set (unfortunately the dependencies require pulling 
> much more than the minimal required set).  I've dropped some minor updates 
> that I made in that period.  Overall I worked on the submissions in the 
> first half of August with the explicit intent to have them included in 
> 2.23, sigh...
> 
> Thanks for your offer WRT applying these -- do you have any way to 
> process these messages automatically?  Otherwise it might perhaps be 
> easier if I replayed the original commits on binutils-2_23-branch from the 
> original patches.  WDYT?

Wow, that's a long set.  I can process them automatically.

Thanks,
Tristan.

Re: Release 2.23: Ping

[Mike Frysinger]

On Mon, Sep 3, 2012 at 3:51 AM, Tristan Gingold wrote:
> On Aug 31, 2012, at 7:44 PM, Mike Frysinger wrote:
>> On Fri, Aug 31, 2012 at 10:34 AM, Tristan Gingold wrote:
>>> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like to thanks for doing this timely.
>>>
>>> Is there any patch that need to be in the 2.23 release ?  Please, reply quickly as I'd like to do the release soon.
>>
>> can we get this merged to the branch (it's already in gcc and HEAD):
>> PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes
>
> Can you send me the url of the commit mail ?  That would help me.

sorry; here you go:
http://sourceware.org/ml/binutils/2012-08/msg00451.html
-mike (resent to all)

Re: Release 2.23: Ping

[Tristan Gingold]

On Sep 4, 2012, at 5:53 AM, Mike Frysinger wrote:

> On Mon, Sep 3, 2012 at 3:51 AM, Tristan Gingold wrote:
>> On Aug 31, 2012, at 7:44 PM, Mike Frysinger wrote:
>>> On Fri, Aug 31, 2012 at 10:34 AM, Tristan Gingold wrote:
>>>> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like to thanks for doing this timely.
>>>> 
>>>> Is there any patch that need to be in the 2.23 release ?  Please, reply quickly as I'd like to do the release soon.
>>> 
>>> can we get this merged to the branch (it's already in gcc and HEAD):
>>> PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes
>> 
>> Can you send me the url of the commit mail ?  That would help me.
> 
> sorry; here you go:
> http://sourceware.org/ml/binutils/2012-08/msg00451.html
> -mike (resent to all)

Done.

Re: Release 2.23: Ping

[Tristan Gingold]

On Sep 3, 2012, at 5:09 PM, Maciej W. Rozycki wrote:

> Tristan,
> 
>> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd 
>> like to thanks for doing this timely.
>> 
>> Is there any patch that need to be in the 2.23 release ?  Please, reply 
>> quickly as I'd like to do the release soon.
> 
> Here's a critical VAX fix I'd like to see in the release:
> 
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00036.html

Done.

Tristan.

Re: Release 2.23: Ping

[H.J. Lu]

On Fri, Aug 31, 2012 at 7:34 AM, Tristan Gingold <gingold@adacore.com> wrote:
> Hi,
>
> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like to thanks for doing this timely.
>
> Is there any patch that need to be in the 2.23 release ?  Please, reply quickly as I'd like to do the release soon.
>
> Thanks in advance,
> Tristan.
>

We'd like to backport PSN support:

http://sourceware.org/ml/binutils/2012-08/msg00137.html

which is approved today for mainline.

Thanks.


-- 
H.J.

Re: Release 2.23: Ping

[Tristan Gingold]

On Sep 4, 2012, at 3:41 PM, H.J. Lu wrote:

> On Fri, Aug 31, 2012 at 7:34 AM, Tristan Gingold <gingold@adacore.com> wrote:
>> Hi,
>> 
>> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like to thanks for doing this timely.
>> 
>> Is there any patch that need to be in the 2.23 release ?  Please, reply quickly as I'd like to do the release soon.
>> 
>> Thanks in advance,
>> Tristan.
>> 
> 
> We'd like to backport PSN support:
> 
> http://sourceware.org/ml/binutils/2012-08/msg00137.html
> 
> which is approved today for mainline.

Sure. I will take care of it.

Tristan.

Re: Release 2.23: Ping

[Tristan Gingold]

On Sep 4, 2012, at 3:41 PM, H.J. Lu wrote:

> On Fri, Aug 31, 2012 at 7:34 AM, Tristan Gingold <gingold@adacore.com> wrote:
>> Hi,
>> 
>> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like to thanks for doing this timely.
>> 
>> Is there any patch that need to be in the 2.23 release ?  Please, reply quickly as I'd like to do the release soon.
>> 
>> Thanks in advance,
>> Tristan.
>> 
> 
> We'd like to backport PSN support:
> 
> http://sourceware.org/ml/binutils/2012-08/msg00137.html
> 
> which is approved today for mainline.

Done.

Re: Release 2.23: Ping

[H.J. Lu]

On Tue, Sep 4, 2012 at 6:31 AM, Tristan Gingold <gingold@adacore.com> wrote:
>
> On Sep 4, 2012, at 5:53 AM, Mike Frysinger wrote:
>
>> On Mon, Sep 3, 2012 at 3:51 AM, Tristan Gingold wrote:
>>> On Aug 31, 2012, at 7:44 PM, Mike Frysinger wrote:
>>>> On Fri, Aug 31, 2012 at 10:34 AM, Tristan Gingold wrote:
>>>>> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like to thanks for doing this timely.
>>>>>
>>>>> Is there any patch that need to be in the 2.23 release ?  Please, reply quickly as I'd like to do the release soon.
>>>>
>>>> can we get this merged to the branch (it's already in gcc and HEAD):
>>>> PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes
>>>
>>> Can you send me the url of the commit mail ?  That would help me.
>>
>> sorry; here you go:
>> http://sourceware.org/ml/binutils/2012-08/msg00451.html
>> -mike (resent to all)
>
> Done.
>

I didn't see it on 2.23 branch.


-- 
H.J.

Re: Release 2.23: Ping

[H.J. Lu]

On Tue, Sep 4, 2012 at 7:19 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Sep 4, 2012 at 6:31 AM, Tristan Gingold <gingold@adacore.com> wrote:
>>
>> On Sep 4, 2012, at 5:53 AM, Mike Frysinger wrote:
>>
>>> On Mon, Sep 3, 2012 at 3:51 AM, Tristan Gingold wrote:
>>>> On Aug 31, 2012, at 7:44 PM, Mike Frysinger wrote:
>>>>> On Fri, Aug 31, 2012 at 10:34 AM, Tristan Gingold wrote:
>>>>>> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like to thanks for doing this timely.
>>>>>>
>>>>>> Is there any patch that need to be in the 2.23 release ?  Please, reply quickly as I'd like to do the release soon.
>>>>>
>>>>> can we get this merged to the branch (it's already in gcc and HEAD):
>>>>> PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes
>>>>
>>>> Can you send me the url of the commit mail ?  That would help me.
>>>
>>> sorry; here you go:
>>> http://sourceware.org/ml/binutils/2012-08/msg00451.html
>>> -mike (resent to all)
>>
>> Done.
>>
>
> I didn't see it on 2.23 branch.
>

Commit didn't show up at

http://sourceware.org/ml/binutils-cvs/2012-09/

since it doesn't have a commit message.


-- 
H.J.

Re: Release 2.23: Ping

[Tristan Gingold]

On Sep 4, 2012, at 4:31 PM, H.J. Lu wrote:

> On Tue, Sep 4, 2012 at 7:19 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Tue, Sep 4, 2012 at 6:31 AM, Tristan Gingold <gingold@adacore.com> wrote:
>>> 
>>> On Sep 4, 2012, at 5:53 AM, Mike Frysinger wrote:
>>> 
>>>> On Mon, Sep 3, 2012 at 3:51 AM, Tristan Gingold wrote:
>>>>> On Aug 31, 2012, at 7:44 PM, Mike Frysinger wrote:
>>>>>> On Fri, Aug 31, 2012 at 10:34 AM, Tristan Gingold wrote:
>>>>>>> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like to thanks for doing this timely.
>>>>>>> 
>>>>>>> Is there any patch that need to be in the 2.23 release ?  Please, reply quickly as I'd like to do the release soon.
>>>>>> 
>>>>>> can we get this merged to the branch (it's already in gcc and HEAD):
>>>>>> PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes
>>>>> 
>>>>> Can you send me the url of the commit mail ?  That would help me.
>>>> 
>>>> sorry; here you go:
>>>> http://sourceware.org/ml/binutils/2012-08/msg00451.html
>>>> -mike (resent to all)
>>> 
>>> Done.
>>> 
>> 
>> I didn't see it on 2.23 branch.
>> 
> 
> Commit didn't show up at
> 
> http://sourceware.org/ml/binutils-cvs/2012-09/
> 
> since it doesn't have a commit message.

Not sure why.  I was able to find the commit message for the original commit, so I think commits that doesn't affect ld/bfd/opcodes/gas/gold/... aren't send to binutils-cvs.

Tristan.

Re: Release 2.23: Ping

[H.J. Lu]

On Tue, Sep 4, 2012 at 7:36 AM, Tristan Gingold <gingold@adacore.com> wrote:
>
> On Sep 4, 2012, at 4:31 PM, H.J. Lu wrote:
>
>> On Tue, Sep 4, 2012 at 7:19 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Tue, Sep 4, 2012 at 6:31 AM, Tristan Gingold <gingold@adacore.com> wrote:
>>>>
>>>> On Sep 4, 2012, at 5:53 AM, Mike Frysinger wrote:
>>>>
>>>>> On Mon, Sep 3, 2012 at 3:51 AM, Tristan Gingold wrote:
>>>>>> On Aug 31, 2012, at 7:44 PM, Mike Frysinger wrote:
>>>>>>> On Fri, Aug 31, 2012 at 10:34 AM, Tristan Gingold wrote:
>>>>>>>> as far as I understand, aarch64 was committed in the 2.23 branch.  I'd like to thanks for doing this timely.
>>>>>>>>
>>>>>>>> Is there any patch that need to be in the 2.23 release ?  Please, reply quickly as I'd like to do the release soon.
>>>>>>>
>>>>>>> can we get this merged to the branch (it's already in gcc and HEAD):
>>>>>>> PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes
>>>>>>
>>>>>> Can you send me the url of the commit mail ?  That would help me.
>>>>>
>>>>> sorry; here you go:
>>>>> http://sourceware.org/ml/binutils/2012-08/msg00451.html
>>>>> -mike (resent to all)
>>>>
>>>> Done.
>>>>
>>>
>>> I didn't see it on 2.23 branch.
>>>
>>
>> Commit didn't show up at
>>
>> http://sourceware.org/ml/binutils-cvs/2012-09/
>>
>> since it doesn't have a commit message.
>
> Not sure why.  I was able to find the commit message for the original commit, so I think commits that doesn't affect ld/bfd/opcodes/gas/gold/... aren't send to binutils-cvs.
>

That explains it.

Thanks.

-- 
H.J.

Re: Release 2.23: Ping

[Tristan Gingold]

On Sep 3, 2012, at 5:06 PM, Maciej W. Rozycki wrote:

> On Mon, 3 Sep 2012, Tristan Gingold wrote:
> 
>>> Did I miss anything?
>> 
>> At least the snapshot announcement:
>> 
>>> 
>>> I have just created the 2.23 branch and uploded prerelease 2.22.90 at:
>>> ftp://sourceware.org/pub/binutils/snapshots/binutils-2.22.90.tar.bz2
> 
> Umm...
> 
>> The branch was created in July, so you need to backport all these patches.
>> I can take care of that, providing you sent me the url of the 
>> binutils-cvs@ messages.
> 
> Hmm, I would like to get included at least these:
> 
> http://sourceware.org/ml/binutils-cvs/2012-07/msg00139.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00002.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00006.html
> 
> (I suggest combining the above three into one; non-MIPS clean-ups from the 
> second can be discarded as far as I'm concerned)
> 
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00027.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00028.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00029.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00030.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00044.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00049.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00050.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00084.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00085.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00091.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00092.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00190.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00191.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00209.html
> 
> and these would be good to have too:
> 
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00045.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00046.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00047.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00051.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00052.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00069.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00086.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00093.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00106.html
> http://sourceware.org/ml/binutils-cvs/2012-08/msg00192.html

The whole set has been backported.  Feel free to check if I missed something :-)

Tristan.

Re: Release 2.23: Ping

[Maciej W. Rozycki]

On Tue, 4 Sep 2012, Tristan Gingold wrote:

> > Hmm, I would like to get included at least these:
> > 
> > http://sourceware.org/ml/binutils-cvs/2012-07/msg00139.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00002.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00006.html
> > 
> > (I suggest combining the above three into one; non-MIPS clean-ups from the 
> > second can be discarded as far as I'm concerned)
> > 
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00027.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00028.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00029.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00030.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00044.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00049.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00050.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00084.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00085.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00091.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00092.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00190.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00191.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00209.html
> > 
> > and these would be good to have too:
> > 
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00045.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00046.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00047.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00051.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00052.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00069.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00086.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00093.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00106.html
> > http://sourceware.org/ml/binutils-cvs/2012-08/msg00192.html
> 
> The whole set has been backported.  Feel free to check if I missed 
> something :-)

 Thanks a lot indeed!  I'll just regression-test it against my latest 
trunk results and see if anything pops up.  I'll let you know the outcome 
by tomorrow.

  Maciej

Re: Release 2.23: Ping

[Maciej W. Rozycki]

On Tue, 4 Sep 2012, Maciej W. Rozycki wrote:

>  Thanks a lot indeed!  I'll just regression-test it against my latest 
> trunk results and see if anything pops up.  I'll let you know the outcome 
> by tomorrow.

 Here's the resulting list of regressions:

arc-elf  +FAIL: ld-elf/pr14156c
arm-aout  +FAIL: Valid v8-a+cryptov1
arm-aout  +FAIL: Valid v8-a+fp
arm-aout  +FAIL: Valid v8-a+simdv3
arm-aout  +FAIL: Valid v8-A barrier (ARM)
arm-aout  +FAIL: Valid v8-A barrier (Thumb)
arm-aout  +FAIL: Valid v8-a
arm-coff  +FAIL: Valid v8-a+cryptov1
arm-coff  +FAIL: Valid v8-a+fp
arm-coff  +FAIL: Valid v8-a+simdv3
arm-coff  +FAIL: Valid v8-A barrier (Thumb)
arm-epoc-pe  +FAIL: Valid v8-a+cryptov1
arm-epoc-pe  +FAIL: Valid v8-a+fp
arm-epoc-pe  +FAIL: Valid v8-a+simdv3
arm-epoc-pe  +FAIL: Valid v8-A barrier (Thumb)
arm-pe  +FAIL: Valid v8-a+cryptov1
arm-pe  +FAIL: Valid v8-a+fp
arm-pe  +FAIL: Valid v8-a+simdv3
arm-pe  +FAIL: Valid v8-A barrier (Thumb)
arm-wince-pe  +FAIL: Valid v8-a+cryptov1
arm-wince-pe  +FAIL: Valid v8-a+fp
arm-wince-pe  +FAIL: Valid v8-a+simdv3
arm-wince-pe  +FAIL: Valid v8-A barrier (Thumb)
d30v-elf  +FAIL: d30v bittest
d30v-elf  +FAIL: ld-elf/pr14156c
dlx-elf  +FAIL: ld-elf/pr14156c
hppa64-hp-hpux11.23  +FAIL: ld-elf/pr14156a
hppa64-hp-hpux11.23  +FAIL: ld-elf/pr14156b
hppa64-hp-hpux11.23  +FAIL: ld-elf/pr14156c
i386-linuxaout  +FAIL: i386 RdSeed (Intel disassembly)
i586-aout  +FAIL: i386 RdSeed (Intel disassembly)
i586-coff  +FAIL: i386 RdSeed (Intel disassembly)
i686-pe  +FAIL: i386 RdSeed (Intel disassembly)
i960-elf  +FAIL: ld-elf/pr14156c
ia64-hpux  +FAIL: ia64 psn
or32-elf  +FAIL: ld-elf/pr14156c
pj-elf  +FAIL: ld-elf/pr14156c
x86_64-mingw32  +FAIL: i386 RdSeed (Intel disassembly)

None of these appears related to my changes.  I have also diffed 2.23 
against current trunk and everything looks in order, so the release is 
free to go as far as I am concerned (of course someone else might want to 
look into these regressions above).

 Thanks for your assistance and your effort with making the release.

  Maciej

Re: Release 2.23: Ping

[Matthew Gretton-Dann]

On 5 September 2012 01:56, Maciej W. Rozycki <macro@codesourcery.com> wrote:
> On Tue, 4 Sep 2012, Maciej W. Rozycki wrote:
>
>  Here's the resulting list of regressions:
>
> arm-aout  +FAIL: Valid v8-a+cryptov1
> arm-aout  +FAIL: Valid v8-a+fp
> arm-aout  +FAIL: Valid v8-a+simdv3
> arm-aout  +FAIL: Valid v8-A barrier (ARM)
> arm-aout  +FAIL: Valid v8-A barrier (Thumb)
> arm-aout  +FAIL: Valid v8-a
> arm-coff  +FAIL: Valid v8-a+cryptov1
> arm-coff  +FAIL: Valid v8-a+fp
> arm-coff  +FAIL: Valid v8-a+simdv3
> arm-coff  +FAIL: Valid v8-A barrier (Thumb)
> arm-epoc-pe  +FAIL: Valid v8-a+cryptov1
> arm-epoc-pe  +FAIL: Valid v8-a+fp
> arm-epoc-pe  +FAIL: Valid v8-a+simdv3
> arm-epoc-pe  +FAIL: Valid v8-A barrier (Thumb)
> arm-pe  +FAIL: Valid v8-a+cryptov1
> arm-pe  +FAIL: Valid v8-a+fp
> arm-pe  +FAIL: Valid v8-a+simdv3
> arm-pe  +FAIL: Valid v8-A barrier (Thumb)
> arm-wince-pe  +FAIL: Valid v8-a+cryptov1
> arm-wince-pe  +FAIL: Valid v8-a+fp
> arm-wince-pe  +FAIL: Valid v8-a+simdv3
> arm-wince-pe  +FAIL: Valid v8-A barrier (Thumb)

I'll take a look at these.

I don't think they should necessarily hold up the release though as
the EABI targets (arm-none-eabi, arm-none-linux-gnueabi) all pass
these tests for me.

Maciej, Did you run any ARM EABI variants?

Thanks,

Matt

-- 
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann@linaro.org

Release 2.23: Ping #2

[Tristan Gingold]

I think all the patches that were requested have been backported to the 2.23 branch.  If I missed a patch, please tell me ASAP.
If you have a new backport request, please tell us ASAP too.

Ideally, I'd like to be in a state where I can do the release at anytime before Friday.

Thanks,
Tristan.

Re: Release 2.23: Ping

[Tristan Gingold]

On Sep 5, 2012, at 10:54 AM, Matthew Gretton-Dann wrote:

> On 5 September 2012 01:56, Maciej W. Rozycki <macro@codesourcery.com> wrote:
>> On Tue, 4 Sep 2012, Maciej W. Rozycki wrote:
>> 
>> Here's the resulting list of regressions:
>> 
>> arm-aout  +FAIL: Valid v8-a+cryptov1
>> arm-aout  +FAIL: Valid v8-a+fp
>> arm-aout  +FAIL: Valid v8-a+simdv3
>> arm-aout  +FAIL: Valid v8-A barrier (ARM)
>> arm-aout  +FAIL: Valid v8-A barrier (Thumb)
>> arm-aout  +FAIL: Valid v8-a
>> arm-coff  +FAIL: Valid v8-a+cryptov1
>> arm-coff  +FAIL: Valid v8-a+fp
>> arm-coff  +FAIL: Valid v8-a+simdv3
>> arm-coff  +FAIL: Valid v8-A barrier (Thumb)
>> arm-epoc-pe  +FAIL: Valid v8-a+cryptov1
>> arm-epoc-pe  +FAIL: Valid v8-a+fp
>> arm-epoc-pe  +FAIL: Valid v8-a+simdv3
>> arm-epoc-pe  +FAIL: Valid v8-A barrier (Thumb)
>> arm-pe  +FAIL: Valid v8-a+cryptov1
>> arm-pe  +FAIL: Valid v8-a+fp
>> arm-pe  +FAIL: Valid v8-a+simdv3
>> arm-pe  +FAIL: Valid v8-A barrier (Thumb)
>> arm-wince-pe  +FAIL: Valid v8-a+cryptov1
>> arm-wince-pe  +FAIL: Valid v8-a+fp
>> arm-wince-pe  +FAIL: Valid v8-a+simdv3
>> arm-wince-pe  +FAIL: Valid v8-A barrier (Thumb)
> 
> I'll take a look at these.
> 
> I don't think they should necessarily hold up the release though as
> the EABI targets (arm-none-eabi, arm-none-linux-gnueabi) all pass
> these tests for me.

Fine.

As always, it would be nice to have clean regression output.  Thank you for working to that!

OTOH, these regressions look to be aarch64/armv8 specific, so aren't real regression compared to 2.22 IIUC.

Tristan.

Re: Release 2.23: Ping

[Matthew Gretton-Dann]

On 5 September 2012 10:04, Tristan Gingold <gingold@adacore.com> wrote:
>
> On Sep 5, 2012, at 10:54 AM, Matthew Gretton-Dann wrote:
>
>> On 5 September 2012 01:56, Maciej W. Rozycki <macro@codesourcery.com> wrote:
>>> On Tue, 4 Sep 2012, Maciej W. Rozycki wrote:
>>>
>>> Here's the resulting list of regressions:
>>>
>>> arm-aout  +FAIL: Valid v8-a+cryptov1
>>> arm-aout  +FAIL: Valid v8-a+fp
>>> arm-aout  +FAIL: Valid v8-a+simdv3
>>> arm-aout  +FAIL: Valid v8-A barrier (ARM)
>>> arm-aout  +FAIL: Valid v8-A barrier (Thumb)
>>> arm-aout  +FAIL: Valid v8-a
>>> arm-coff  +FAIL: Valid v8-a+cryptov1
>>> arm-coff  +FAIL: Valid v8-a+fp
>>> arm-coff  +FAIL: Valid v8-a+simdv3
>>> arm-coff  +FAIL: Valid v8-A barrier (Thumb)
>>> arm-epoc-pe  +FAIL: Valid v8-a+cryptov1
>>> arm-epoc-pe  +FAIL: Valid v8-a+fp
>>> arm-epoc-pe  +FAIL: Valid v8-a+simdv3
>>> arm-epoc-pe  +FAIL: Valid v8-A barrier (Thumb)
>>> arm-pe  +FAIL: Valid v8-a+cryptov1
>>> arm-pe  +FAIL: Valid v8-a+fp
>>> arm-pe  +FAIL: Valid v8-a+simdv3
>>> arm-pe  +FAIL: Valid v8-A barrier (Thumb)
>>> arm-wince-pe  +FAIL: Valid v8-a+cryptov1
>>> arm-wince-pe  +FAIL: Valid v8-a+fp
>>> arm-wince-pe  +FAIL: Valid v8-a+simdv3
>>> arm-wince-pe  +FAIL: Valid v8-A barrier (Thumb)
>>
>> I'll take a look at these.
>>
>> I don't think they should necessarily hold up the release though as
>> the EABI targets (arm-none-eabi, arm-none-linux-gnueabi) all pass
>> these tests for me.
>
> Fine.
>
> As always, it would be nice to have clean regression output.  Thank you for working to that!
>
> OTOH, these regressions look to be aarch64/armv8 specific, so aren't real regression compared to 2.22 IIUC.

You are correct - these are not new regressions as these are new tests
in 2.23.

Substantial numbers of arm*-*-* tests fail already for non-EABI
targets, for what looks like similar reasons to why this new crop of
tests fail.  Which is that the testcases make implicit assumptions
that are true for EABI targets but aren't necessarily true for other
targets.

Whilst the simple solution would be to mark the tests unsupported for
non-EABI targets this strikes me as being the easy way out, and wrong
as I think these tests should be valid on all arm*-*-* targets.

I will put this on my list of things to look at further, but it is not
going to be high priority - and it certainly shouldn't (in my opinion)
block the binutils 2.23 release.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann@linaro.org

Re: Release 2.23: Ping

[Maciej W. Rozycki]

On Wed, 5 Sep 2012, Matthew Gretton-Dann wrote:

> I don't think they should necessarily hold up the release though as
> the EABI targets (arm-none-eabi, arm-none-linux-gnueabi) all pass
> these tests for me.
> 
> Maciej, Did you run any ARM EABI variants?

 Here's the exact list of ARM targets included in my testing:

arm-aout arm-coff arm-epoc-pe arm-linuxeabi arm-netbsdelf arm-nto arm-pe 
arm-symbianelf arm-vxworks arm-wince-pe

-- I took it from Alan's selection and did not add anything myself.  I 
hope this helps.

  Maciej

Re: Release 2.23: Ping

[Richard Earnshaw]

On 05/09/12 13:02, Maciej W. Rozycki wrote:
> On Wed, 5 Sep 2012, Matthew Gretton-Dann wrote:
> 
>> I don't think they should necessarily hold up the release though as
>> the EABI targets (arm-none-eabi, arm-none-linux-gnueabi) all pass
>> these tests for me.
>>
>> Maciej, Did you run any ARM EABI variants?
> 
>  Here's the exact list of ARM targets included in my testing:
> 
> arm-aout arm-coff arm-epoc-pe arm-linuxeabi arm-netbsdelf arm-nto arm-pe 
> arm-symbianelf arm-vxworks arm-wince-pe
> 
> -- I took it from Alan's selection and did not add anything myself.  I 
> hope this helps.
> 
>   Maciej
> 
> 
> 


We should just kill arm-aout.  Surely nothing in the last 10 years has
used it :-)

R.

Re: Release 2.23: Ping

[Maciej W. Rozycki]

On Wed, 5 Sep 2012, Maciej W. Rozycki wrote:

> None of these appears related to my changes.  I have also diffed 2.23 
> against current trunk and everything looks in order, so the release is 
> free to go as far as I am concerned (of course someone else might want to 
> look into these regressions above).

 I have to take it back unfortunately, an incorrect encoding of a 
microMIPS instruction has just been found in the opcode table -- which I 
consider a serious problem.

 The fix will be a one-liner plus a corresponding test suite update and 
will apply both to trunk and 2.23.  I'll push it through testing now and 
will have it ready tomorrow.  I hope this is going to be acceptable.

  Maciej

Re: Release 2.23: Ping

[Tristan Gingold]

On Sep 5, 2012, at 10:48 PM, Maciej W. Rozycki wrote:

> On Wed, 5 Sep 2012, Maciej W. Rozycki wrote:
> 
>> None of these appears related to my changes.  I have also diffed 2.23 
>> against current trunk and everything looks in order, so the release is 
>> free to go as far as I am concerned (of course someone else might want to 
>> look into these regressions above).
> 
> I have to take it back unfortunately, an incorrect encoding of a 
> microMIPS instruction has just been found in the opcode table -- which I 
> consider a serious problem.

Understood.

> The fix will be a one-liner plus a corresponding test suite update and 
> will apply both to trunk and 2.23.  I'll push it through testing now and 
> will have it ready tomorrow.  I hope this is going to be acceptable.

Sure.  Can you please do the backport ?

Tristan.

Re: Release 2.23: Ping #2

[Alan Modra]

On Wed, Sep 05, 2012 at 11:01:49AM +0200, Tristan Gingold wrote:
> I think all the patches that were requested have been backported to the 2.23 branch.  If I missed a patch, please tell me ASAP.
> If you have a new backport request, please tell us ASAP too.

I decided to put my pr14464 fix for ppc64 onto the branch.  It's one
of those bugs that probably doesn't affect too many people so I hadn't
bothered to commit the fix there.  OTOH, the fix ought to be quite
safe.  If you have already begun the release process, I'm not fussed
if this fix didn't make it into the release.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Release 2.23

[Matthias Klose]

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

one more change which should go the trunk and the branch. currently the builds
on kfreebsd are broken,

In file included from ../../bfd/sysdep.h:30:0,
                 from ../../bfd/archures.c:24:
./config.h:7:4: error: #error config.h must be #included before system headers
make[5]: *** [archive.lo] Error 1

this is because gcc for kfreebsd defines the __GLIBC__ macro in
gcc/config/kfreebsd-gnu.h:

#define GNU_USER_TARGET_OS_CPP_BUILTINS()               \
  do                                            \
    {                                           \
        builtin_define ("__FreeBSD_kernel__");  \
        builtin_define ("__GLIBC__");           \
        builtin_define_std ("unix");            \
        builtin_assert ("system=unix");         \
        builtin_assert ("system=posix");        \
    }                                           \
  while (0)


a quick fix for this is to disable this safety check on kfreebsd by checking
that the __FreeBSD_kernel__ macro isn't defined.

  Matthias


[-- Attachment #2: kfreebsd-buildfix.diff --]
[-- Type: text/plain, Size: 2687 bytes --]

--- binutils-2.22.90.20120907.orig/bfd/config.in
+++ binutils-2.22.90.20120907/bfd/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
     (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/gas/config.in
+++ binutils-2.22.90.20120907/gas/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/ld/config.in
+++ binutils-2.22.90.20120907/ld/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/gold/config.in
+++ binutils-2.22.90.20120907/gold/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/opcodes/config.in
+++ binutils-2.22.90.20120907/opcodes/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/binutils/config.in
+++ binutils-2.22.90.20120907/binutils/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__)
 #  error config.h must be #included before system headers
 #endif
 

Re: Release 2.23

[Alan Modra]

On Sun, Sep 09, 2012 at 04:11:44PM +0200, Matthias Klose wrote:
> a quick fix for this is to disable this safety check on kfreebsd by checking
> that the __FreeBSD_kernel__ macro isn't defined.

The patch is OK with suitable ChangeLog entries.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Release 2.23: Ping #2

[Hans-Peter Nilsson]

On Wed, 5 Sep 2012, Tristan Gingold wrote:
> If you have a new backport request, please tell us ASAP too.

In <http://sourceware.org/ml/binutils/2012-09/msg00101.html> I
mentioned
<http://sourceware.org/ml/binutils/2012-09/msg00008.html> but
got the description wrong; that was for a SEGV on a .section
directive.  The "FAIL: gas/mmix/fb-2" patch is in
<http://sourceware.org/ml/binutils/2012-08/msg00243.html>.

Ok for 2.23?

> Ideally, I'd like to be in a state where I can do the release
> at anytime before Friday.

Oops.  But it hasn't happened yet AFAICT, so here we go.

brgds, H-P

Re: Release 2.23

[Tristan Gingold]

On Sep 9, 2012, at 4:11 PM, Matthias Klose wrote:

> one more change which should go the trunk and the branch. currently the builds
> on kfreebsd are broken,

Ok for the branch too.

> 
> In file included from ../../bfd/sysdep.h:30:0,
>                 from ../../bfd/archures.c:24:
> ./config.h:7:4: error: #error config.h must be #included before system headers
> make[5]: *** [archive.lo] Error 1
> 
> this is because gcc for kfreebsd defines the __GLIBC__ macro in
> gcc/config/kfreebsd-gnu.h:
> 
> #define GNU_USER_TARGET_OS_CPP_BUILTINS()               \
>  do                                            \
>    {                                           \
>        builtin_define ("__FreeBSD_kernel__");  \
>        builtin_define ("__GLIBC__");           \
>        builtin_define_std ("unix");            \
>        builtin_assert ("system=unix");         \
>        builtin_assert ("system=posix");        \
>    }                                           \
>  while (0)
> 
> 
> a quick fix for this is to disable this safety check on kfreebsd by checking
> that the __FreeBSD_kernel__ macro isn't defined.
> 
>  Matthias
> 
> <kfreebsd-buildfix.diff>

Re: Release 2.23

[Matthias Klose]

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

On 09.09.2012 16:48, Alan Modra wrote:
> On Sun, Sep 09, 2012 at 04:11:44PM +0200, Matthias Klose wrote:
>> a quick fix for this is to disable this safety check on kfreebsd by checking
>> that the __FreeBSD_kernel__ macro isn't defined.
> 
> The patch is OK with suitable ChangeLog entries.

attached (this time with the diff for ChangeLog's as well). please check it in.

  Matthias



[-- Attachment #2: 2.23.diff --]
[-- Type: text/plain, Size: 4723 bytes --]

diff --git a/bfd/ChangeLog b/bfd/ChangeLog
index 7fd344b..75254b4 100644
--- a/bfd/ChangeLog
+++ b/bfd/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-10  Matthias Klose  <doko@ubuntu.com>
+
+	* config.in: Disable sanity check for kfreebsd.
+
 2012-09-07  Alan Modra  <amodra@gmail.com>
 
 	PR ld/14464
diff --git a/binutils/ChangeLog b/binutils/ChangeLog
index 86d0995..4ca9aac 100644
--- a/binutils/ChangeLog
+++ b/binutils/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-10  Matthias Klose  <doko@ubuntu.com>
+
+	* config.in: Disable sanity check for kfreebsd.
+
 2012-08-16  Ian Bolton  <ian.bolton@arm.com>
             Laurent Desnogues  <laurent.desnogues@arm.com>
             Jim MacArthur  <jim.macarthur@arm.com>
diff --git a/gas/ChangeLog b/gas/ChangeLog
index f2a949c..7a8e167 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-10  Matthias Klose  <doko@ubuntu.com>
+
+	* config.in: Disable sanity check for kfreebsd.
+
 2012-09-10  Hans-Peter Nilsson  <hp@bitrange.com>
 
 	PR gas/14521
diff --git a/gold/ChangeLog b/gold/ChangeLog
index 0b6bf49..122107d 100644
--- a/gold/ChangeLog
+++ b/gold/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-10  Matthias Klose  <doko@ubuntu.com>
+
+	* config.in: Disable sanity check for kfreebsd.
+
 2012-08-09  Nick Clifton  <nickc@redhat.com>
 
 	* po/vi.po: Updated Vietnamese translation.
diff --git a/ld/ChangeLog b/ld/ChangeLog
index 71f3ddd..a4c300a 100644
--- a/ld/ChangeLog
+++ b/ld/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-10  Matthias Klose  <doko@ubuntu.com>
+
+	* config.in: Disable sanity check for kfreebsd.
+
 2012-09-10  Hans-Peter Nilsson  <hp@bitrange.com>
 
 	* emultempl/mmo.em (mmo_place_orphan): Rewrite to also attach
diff --git a/opcodes/ChangeLog b/opcodes/ChangeLog
index 384de9b..e8e6789 100644
--- a/opcodes/ChangeLog
+++ b/opcodes/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-10  Matthias Klose  <doko@ubuntu.com>
+
+	* config.in: Disable sanity check for kfreebsd.
+
 2012-08-14  Maciej W. Rozycki  <macro@codesourcery.com>
 
 	* mips-dis.c (print_insn_args): Add GET_OP and GET_OP_S local
--- binutils-2.22.90.20120907.orig/bfd/config.in
+++ binutils-2.22.90.20120907/bfd/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
     (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/gas/config.in
+++ binutils-2.22.90.20120907/gas/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/ld/config.in
+++ binutils-2.22.90.20120907/ld/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/gold/config.in
+++ binutils-2.22.90.20120907/gold/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/opcodes/config.in
+++ binutils-2.22.90.20120907/opcodes/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/binutils/config.in
+++ binutils-2.22.90.20120907/binutils/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__)
 #  error config.h must be #included before system headers
 #endif
 

[-- Attachment #3: trunk.diff --]
[-- Type: text/plain, Size: 4790 bytes --]

diff --git a/bfd/ChangeLog b/bfd/ChangeLog
index ff0c5c2..51e2562 100644
--- a/bfd/ChangeLog
+++ b/bfd/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-10  Matthias Klose  <doko@ubuntu.com>
+
+	* config.in: Disable sanity check for kfreebsd.
+
 2012-09-04  Sergey A. Guriev <sergey.a.guriev@intel.com>
 
 	* cpu-ia64-opc.c (ins_cnt6a): New function.
diff --git a/binutils/ChangeLog b/binutils/ChangeLog
index 7bc8a09..26932dd 100644
--- a/binutils/ChangeLog
+++ b/binutils/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-10  Matthias Klose  <doko@ubuntu.com>
+
+	* config.in: Disable sanity check for kfreebsd.
+
 2012-09-06  Cary Coutant  <ccoutant@google.com>
 
 	* dwarf.c (decode_location_expression): Add
diff --git a/gas/ChangeLog b/gas/ChangeLog
index c2446e8..b5302d6 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-10  Matthias Klose  <doko@ubuntu.com>
+
+	* config.in: Disable sanity check for kfreebsd.
+
 2012-09-07  Anthony Green  <green@moxielogic.com>
 
 	* config/tc-moxie.c (md_pcrel_from): Branches are now relative
diff --git a/gold/ChangeLog b/gold/ChangeLog
index 7c16d7b..dcb6a8d 100644
--- a/gold/ChangeLog
+++ b/gold/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-10  Matthias Klose  <doko@ubuntu.com>
+
+	* config.in: Disable sanity check for kfreebsd.
+
 2012-09-09  Alan Modra  <amodra@gmail.com>
 
 	* target.h (Target::gc_mark_symbol, do_gc_mark_symbol): New functions.
diff --git a/ld/ChangeLog b/ld/ChangeLog
index 32503b7..0f91ed5 100644
--- a/ld/ChangeLog
+++ b/ld/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-10  Matthias Klose  <doko@ubuntu.com>
+
+	* config.in: Disable sanity check for kfreebsd.
+
 2012-09-10  Iain Sandoe  <iain@codesourcery.com>
 
 	* configure.tgt (powerpc-*-elf, et al): Define targ64_extra_emuls
diff --git a/opcodes/ChangeLog b/opcodes/ChangeLog
index 1cfb715..e6db29e 100644
--- a/opcodes/ChangeLog
+++ b/opcodes/ChangeLog
@@ -1,3 +1,7 @@
+2012-09-10  Matthias Klose  <doko@ubuntu.com>
+
+	* config.in: Disable sanity check for kfreebsd.
+
 2012-09-04  Sergey A. Guriev <sergey.a.guriev@intel.com>
 
 	* ia64-asmtab.h (completer_index): Extend bitfield to full uint.
--- binutils-2.22.90.20120907.orig/bfd/config.in
+++ binutils-2.22.90.20120907/bfd/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
     (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/gas/config.in
+++ binutils-2.22.90.20120907/gas/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/ld/config.in
+++ binutils-2.22.90.20120907/ld/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/gold/config.in
+++ binutils-2.22.90.20120907/gold/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/opcodes/config.in
+++ binutils-2.22.90.20120907/opcodes/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1
--- binutils-2.22.90.20120907.orig/binutils/config.in
+++ binutils-2.22.90.20120907/binutils/config.in
@@ -2,7 +2,7 @@
 
 /* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__)
 #  error config.h must be #included before system headers
 #endif
 

Re: Release 2.23

[Alan Modra]

On Mon, Sep 10, 2012 at 05:12:50PM +0200, Matthias Klose wrote:
> On 09.09.2012 16:48, Alan Modra wrote:
> > On Sun, Sep 09, 2012 at 04:11:44PM +0200, Matthias Klose wrote:
> >> a quick fix for this is to disable this safety check on kfreebsd by checking
> >> that the __FreeBSD_kernel__ macro isn't defined.
> > 
> > The patch is OK with suitable ChangeLog entries.
> 
> attached (this time with the diff for ChangeLog's as well). please check it in.

Applied.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Release 2.23: Ping

[Matthias Klose]

On 04.09.2012 18:31, Maciej W. Rozycki wrote:
> On Tue, 4 Sep 2012, Tristan Gingold wrote:
>  Thanks a lot indeed!  I'll just regression-test it against my latest 
> trunk results and see if anything pops up.  I'll let you know the outcome 
> by tomorrow.

this did break linux kernel builds (at least in 3.5.0), on x86_64-linux-gnu.
Reverting Tristan's checkin (git 754bb8efffca0d3006e417ba56b92bec9990753d) of
the mips backports to the 2.23 branch solves the issue. The patch touches
generic files in bfd and ld. I didn't check, if it's a binutils issue or a
kernel issue exposed by this change.

  Matthias

From https://launchpad.net/bugs/1049650

"""
$ readelf -s setup.elf | grep video_card
   138: 00003660 0 NOTYPE GLOBAL DEFAULT 12 video_cards
   151: 00003660 0 NOTYPE GLOBAL DEFAULT 12 video_cards_end

We should see some space between video_cards and video_cards_end, and the fact
that we don't means the kernel isn't going to find any options for video.
"""

Re: Release 2.23: Ping

[Maciej W. Rozycki]

On Thu, 13 Sep 2012, Matthias Klose wrote:

> >  Thanks a lot indeed!  I'll just regression-test it against my latest 
> > trunk results and see if anything pops up.  I'll let you know the outcome 
> > by tomorrow.
> 
> this did break linux kernel builds (at least in 3.5.0), on x86_64-linux-gnu.
> Reverting Tristan's checkin (git 754bb8efffca0d3006e417ba56b92bec9990753d) of
> the mips backports to the 2.23 branch solves the issue. The patch touches
> generic files in bfd and ld. I didn't check, if it's a binutils issue or a
> kernel issue exposed by this change.

 Some changes were indeed generic, specifically the symbol export class 
BFD bug fix.  The bug affected all targets, however Linux shouldn't care 
as export classes are used in dynamic linking only.

 There were also non-MIPS changes to ld that were supposed to be 
transparent; they mainly affected symbols defined by linker scripts and 
caused no test suite regressions -- but then that's a feature used quite 
heavily by Linux.  If anything was indeed missed, then it would be a 
worthwhile addition to the test suite alongside the fix.

> From https://launchpad.net/bugs/1049650
> 
> """
> $ readelf -s setup.elf | grep video_card
>    138: 00003660 0 NOTYPE GLOBAL DEFAULT 12 video_cards
>    151: 00003660 0 NOTYPE GLOBAL DEFAULT 12 video_cards_end
> 
> We should see some space between video_cards and video_cards_end, and the fact
> that we don't means the kernel isn't going to find any options for video.
> """

 Thanks for the reference.  Can you please give me some instructions as to 
how to build a kernel that has this problem, e.g. will some defconfig and 
a kernel.org tree be enough to reproduce that?  I'll have a look into it, 
but please forgive my lack of knowledge on the recipes Ubuntu developers 
use.  Thanks.

 Also would you per any chance be willing to help and try binutils trunk 
to track down the specific change that caused this problem?  The backport 
was made in bulk while on trunk self-contained changes were applied 
individually.  That would make tracking down the culprit much much easier.

  Maciej

Re: Release 2.23: Ping

[Alan Modra]

On Thu, Sep 13, 2012 at 07:13:18PM +0100, Maciej W. Rozycki wrote:
> On Thu, 13 Sep 2012, Matthias Klose wrote:
> > From https://launchpad.net/bugs/1049650
> > 
> > """
> > $ readelf -s setup.elf | grep video_card
> >    138: 00003660 0 NOTYPE GLOBAL DEFAULT 12 video_cards
> >    151: 00003660 0 NOTYPE GLOBAL DEFAULT 12 video_cards_end

I doubt that Maciej's changes have anything to do with this problem.
If you link setup.elf with "-Map somefile" does the map show any input
sections being linked between the script lines setting these symbols?
Something like the following should be there:

.videocards     0x0000000000003bc4       0x54
                0x0000000000003bc4                video_cards = .
 *(.videocards)
 .videocards    0x0000000000003bc4       0x1c arch/x86/boot/video-vga.o
 .videocards    0x0000000000003be0       0x1c arch/x86/boot/video-vesa.o
 .videocards    0x0000000000003bfc       0x1c arch/x86/boot/video-bios.o
                0x0000000000003c18                video_cards_end = .
                0x0000000000003c20                . = ALIGN (0x10)


-- 
Alan Modra
Australia Development Lab, IBM

Re: Release 2.23: Ping

[Tristan Gingold]

On Sep 13, 2012, at 7:32 PM, Matthias Klose wrote:

> On 04.09.2012 18:31, Maciej W. Rozycki wrote:
>> On Tue, 4 Sep 2012, Tristan Gingold wrote:
>> Thanks a lot indeed!  I'll just regression-test it against my latest 
>> trunk results and see if anything pops up.  I'll let you know the outcome 
>> by tomorrow.
> 
> this did break linux kernel builds (at least in 3.5.0), on x86_64-linux-gnu.
> Reverting Tristan's checkin (git 754bb8efffca0d3006e417ba56b92bec9990753d) of
> the mips backports to the 2.23 branch solves the issue. The patch touches
> generic files in bfd and ld. I didn't check, if it's a binutils issue or a
> kernel issue exposed by this change.

That's certainly a blocking issue.  Is this regression only on the 2.23 branch and not in the trunk ?

Tristan.

Re: Release 2.23: Ping

[Matthias Klose]

On 14.09.2012 10:21, Tristan Gingold wrote:
> 
> On Sep 13, 2012, at 7:32 PM, Matthias Klose wrote:
> 
>> On 04.09.2012 18:31, Maciej W. Rozycki wrote:
>>> On Tue, 4 Sep 2012, Tristan Gingold wrote:
>>> Thanks a lot indeed!  I'll just regression-test it against my latest 
>>> trunk results and see if anything pops up.  I'll let you know the outcome 
>>> by tomorrow.
>>
>> this did break linux kernel builds (at least in 3.5.0), on x86_64-linux-gnu.
>> Reverting Tristan's checkin (git 754bb8efffca0d3006e417ba56b92bec9990753d) of
>> the mips backports to the 2.23 branch solves the issue. The patch touches
>> generic files in bfd and ld. I didn't check, if it's a binutils issue or a
>> kernel issue exposed by this change.
> 
> That's certainly a blocking issue.  Is this regression only on the 2.23 branch and not in the trunk ?

this turned out as an unrelated issue. Now afk, will follow-up tomorrow.

  Matthias

Re: Release 2.23: Ping

[Maciej W. Rozycki]

On Fri, 14 Sep 2012, Matthias Klose wrote:

> > That's certainly a blocking issue.  Is this regression only on the 
> > 2.23 branch and not in the trunk ?
> 
> this turned out as an unrelated issue. Now afk, will follow-up tomorrow.

 OK, thanks, I saw you'd found the culprit in your bug tracker.

  Maciej

Re: Release 2.23: Ping

[Maciej W. Rozycki]

On Thu, 6 Sep 2012, Tristan Gingold wrote:

> > The fix will be a one-liner plus a corresponding test suite update and 
> > will apply both to trunk and 2.23.  I'll push it through testing now and 
> > will have it ready tomorrow.  I hope this is going to be acceptable.
> 
> Sure.  Can you please do the backport ?

 FAOD I did that now.  I have now more MIPS bug-fixing stuff coming along, 
but none I consider critical enough for 2.23, so the release is clear to 
go as far as I am concerned.  Thanks for your patience.

  Maciej

Release 2.23: Ping #3

[Tristan Gingold]

Quick status: I think that backport requests have been applied, and there is no pending issue.

So, this is the last ping.

Ideally I'd like to make the release soon (even if the August deadline is well over :-)

Tristan.

Re: Release 2.23: Ping #3

[H.J. Lu]

On Tue, Sep 18, 2012 at 8:51 AM, Tristan Gingold <gingold@adacore.com> wrote:
> Quick status: I think that backport requests have been applied, and there is no pending issue.
>
> So, this is the last ping.
>
> Ideally I'd like to make the release soon (even if the August deadline is well over :-)
>

This is an old bug:

http://www.sourceware.org/bugzilla/show_bug.cgi?id=14591

I'd like to get it fixed on mainline and backport it to 2.23.


-- 
H.J.

Re: Release 2.23: Ping #3

[H.J. Lu]

On Tue, Sep 18, 2012 at 8:53 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Sep 18, 2012 at 8:51 AM, Tristan Gingold <gingold@adacore.com> wrote:
>> Quick status: I think that backport requests have been applied, and there is no pending issue.
>>
>> So, this is the last ping.
>>
>> Ideally I'd like to make the release soon (even if the August deadline is well over :-)
>>
>
> This is an old bug:
>
> http://www.sourceware.org/bugzilla/show_bug.cgi?id=14591
>
> I'd like to get it fixed on mainline and backport it to 2.23.
>

Here is the cvs url:

http://sourceware.org/ml/binutils-cvs/2012-09/msg00122.html

Thanks.

-- 
H.J.

Re: Release 2.23: Ping #3

[Tristan Gingold]

On Sep 19, 2012, at 5:43 PM, H.J. Lu wrote:

> On Tue, Sep 18, 2012 at 8:53 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Tue, Sep 18, 2012 at 8:51 AM, Tristan Gingold <gingold@adacore.com> wrote:
>>> Quick status: I think that backport requests have been applied, and there is no pending issue.
>>> 
>>> So, this is the last ping.
>>> 
>>> Ideally I'd like to make the release soon (even if the August deadline is well over :-)
>>> 
>> 
>> This is an old bug:
>> 
>> http://www.sourceware.org/bugzilla/show_bug.cgi?id=14591
>> 
>> I'd like to get it fixed on mainline and backport it to 2.23.
>> 
> 
> Here is the cvs url:
> 
> http://sourceware.org/ml/binutils-cvs/2012-09/msg00122.html

Committed.

Tristan.

Re: Release 2.23

[Alan Modra]

On Tue, Sep 11, 2012 at 08:03:31AM +0930, Alan Modra wrote:
> On Mon, Sep 10, 2012 at 05:12:50PM +0200, Matthias Klose wrote:
> > On 09.09.2012 16:48, Alan Modra wrote:
> > > On Sun, Sep 09, 2012 at 04:11:44PM +0200, Matthias Klose wrote:
> > >> a quick fix for this is to disable this safety check on kfreebsd by checking
> > >> that the __FreeBSD_kernel__ macro isn't defined.
> > > 
> > > The patch is OK with suitable ChangeLog entries.
> > 
> > attached (this time with the diff for ChangeLog's as well). please check it in.
> 
> Applied.

Oops.  config.in is a generated file..

	* configure.in: Apply 2012-09-10 change to config.in here.

Index: bfd/configure.in
===================================================================
RCS file: /cvs/src/src/bfd/configure.in,v
retrieving revision 1.322
diff -u -p -r1.322 configure.in
--- bfd/configure.in	30 Oct 2012 13:30:15 -0000	1.322
+++ bfd/configure.in	5 Nov 2012 10:31:27 -0000
@@ -121,7 +121,7 @@ AC_CONFIG_HEADERS(config.h:config.in)
 AH_VERBATIM([00_CONFIG_H_CHECK],
 [/* Check that config.h is #included before system headers
     (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1])
Index: gas/configure.in
===================================================================
RCS file: /cvs/src/src/gas/configure.in,v
retrieving revision 1.233
diff -u -p -r1.233 configure.in
--- gas/configure.in	27 Jul 2012 16:30:54 -0000	1.233
+++ gas/configure.in	5 Nov 2012 10:31:30 -0000
@@ -62,7 +62,7 @@ AC_CONFIG_HEADERS(config.h:config.in)
 AH_VERBATIM([00_CONFIG_H_CHECK],
 [/* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1])
Index: ld/configure.in
===================================================================
RCS file: /cvs/src/src/ld/configure.in,v
retrieving revision 1.78
diff -u -p -r1.78 configure.in
--- ld/configure.in	14 Aug 2012 11:59:04 -0000	1.78
+++ ld/configure.in	5 Nov 2012 10:31:33 -0000
@@ -128,7 +128,7 @@ AC_CONFIG_HEADERS([config.h:config.in])
 AH_VERBATIM([00_CONFIG_H_CHECK],
 [/* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1])
Index: opcodes/configure.in
===================================================================
RCS file: /cvs/src/src/opcodes/configure.in,v
retrieving revision 1.112
diff -u -p -r1.112 configure.in
--- opcodes/configure.in	17 Aug 2012 14:33:23 -0000	1.112
+++ opcodes/configure.in	5 Nov 2012 10:31:34 -0000
@@ -51,7 +51,7 @@ AC_CONFIG_HEADERS(config.h:config.in)
 AH_VERBATIM([00_CONFIG_H_CHECK],
 [/* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1])


-- 
Alan Modra
Australia Development Lab, IBM

Re: Release 2.23

[Alan Modra]

On Mon, Nov 05, 2012 at 09:18:01PM +1030, Alan Modra wrote:
> On Tue, Sep 11, 2012 at 08:03:31AM +0930, Alan Modra wrote:
> > On Mon, Sep 10, 2012 at 05:12:50PM +0200, Matthias Klose wrote:
> > > On 09.09.2012 16:48, Alan Modra wrote:
> > > > On Sun, Sep 09, 2012 at 04:11:44PM +0200, Matthias Klose wrote:
> > > >> a quick fix for this is to disable this safety check on kfreebsd by checking
> > > >> that the __FreeBSD_kernel__ macro isn't defined.
> > > > 
> > > > The patch is OK with suitable ChangeLog entries.
> > > 
> > > attached (this time with the diff for ChangeLog's as well). please check it in.
> > 
> > Applied.
> 
> Oops.  config.in is a generated file..

Sigh, and I missed binutils/configure.in and gold/configure.ac
because config.in had already been regenerated in binutils and I
wasn't building gold.  I also don't see why the binutils directory
should have a different test (not allowing multiple inclusion of
config.h) to the others.

binutils/
	* configure.in: Apply 2012-09-10 change to config.in here.  Add
	__CONFIG_H__ check.
	* config.in: Regenerate.
gold/
	* configure.ac: Apply 2012-09-10 change to config.in here.
	* configure: Regenerate.

Index: binutils/configure.in
===================================================================
RCS file: /cvs/src/src/binutils/configure.in,v
retrieving revision 1.114
diff -u -p -r1.114 configure.in
--- binutils/configure.in	30 Oct 2012 12:44:54 -0000	1.114
+++ binutils/configure.in	5 Nov 2012 12:09:53 -0000
@@ -47,9 +47,10 @@ AC_CONFIG_HEADERS(config.h:config.in)
 AH_VERBATIM([00_CONFIG_H_CHECK],
 [/* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
-#endif])
+#endif
+#define __CONFIG_H__ 1])
 
 if test -z "$target" ; then
     AC_MSG_ERROR(Unrecognized target system type; please check config.sub.)
Index: gold/configure.ac
===================================================================
RCS file: /cvs/src/src/gold/configure.ac,v
retrieving revision 1.78
diff -u -p -r1.78 configure.ac
--- gold/configure.ac	15 Sep 2012 17:11:28 -0000	1.78
+++ gold/configure.ac	5 Nov 2012 12:09:56 -0000
@@ -15,7 +15,7 @@ AM_CONFIG_HEADER(config.h:config.in)
 AH_VERBATIM([00_CONFIG_H_CHECK],
 [/* Check that config.h is #included before system headers
    (this works only for glibc, but that should be enough).  */
-#if defined(__GLIBC__) && !defined(__CONFIG_H__)
+#if defined(__GLIBC__) && !defined(__FreeBSD_kernel__) && !defined(__CONFIG_H__)
 #  error config.h must be #included before system headers
 #endif
 #define __CONFIG_H__ 1])

-- 
Alan Modra
Australia Development Lab, IBM