Re: [PATCH, libbacktrace] Don't call __sync_lock_test_and_set if we don't have sync functions

2013-01-01 Thread Ian Lance Taylor
On Sun, Dec 9, 2012 at 11:08 AM, John David Anglin d...@hiauly1.hia.nrc.ca wrote: On hppa*-*-hpux*, we don't have sync functions. However, __sync_lock_test_and_set is called in backtrace_alloc and backtrace_free. This causes an abort before ICE proccessing is fully complete. hppa64 is an

libbacktrace patch committed: Don't use -I ../gcc/include

2013-01-01 Thread Ian Lance Taylor
There is no reason for libbacktrace to try to include files from ../gcc/include. All the required header files can now be found in libgcc. I'm not sure why I added the -I ../gcc/include in the first place; perhaps I was thinking of code from before the libgcc migration. Using -I ../gcc/include

[PATCH] libiberty simple object XCOFF support

2013-01-01 Thread David Edelsohn
The attached patch is a start at libiberty simple object support for AIX XCOFF file format. With this patch, the simple object API can read and write XCOFF files. I need to investigate a little more about the proper attributes for XCOFF sections written using sobj. There are open questions about

Re: [PATCH] libiberty simple object XCOFF support

2013-01-01 Thread Steven Bosscher
On Tue, Jan 1, 2013 at 6:04 PM, David Edelsohn wrote: There are open questions about how to wedge GCC LTO support into the AIX XCOFF file format. I am unsure if LTO can be an additional section in the XCOFF file or should be new CSECTs in an existing section. Maybe CSECTs in the XCOFF comment

Re: [PATCH] libiberty simple object XCOFF support

2013-01-01 Thread Ian Lance Taylor
On Tue, Jan 1, 2013 at 9:10 AM, Steven Bosscher stevenb@gmail.com wrote: Does XCOFF differ a lot from COFF? In a word, yes. While COFF and XCOFF share a distant ancestor, they are in effect completely different object file formats. Ian

[Patch, Darwin, ppc] constrain processor usage for m32.

2013-01-01 Thread Tobias Netzel
Hi Iain, Mike and Andrew, I have been having issues compiling WebKit with mcpu=970 (or mcpu=G5) without afterwards passing mno-powerpc64 or m32 in to explicitly turn 64 bit instructions off. That was using Apple gcc 5666.3, which is Apples last published version and based on 4.2.1 . I also

[patch, Fortran] PR 55806 - Inefficient ANY with array constructors

2013-01-01 Thread Thomas Koenig
Hello world, the attached patch replaces ANY(a, b, c) with a .or. b .or c, leading to reduced execution time. It also handles ALL, PRODUCT and SUM. This fixes a bug noted by Michael Metcalf. Regression-tested. OK for trunk? Thomas 2013-01-01 Thomas Koenig tkoe...@gcc.gnu.org

Re: [patch] std::unique_ptrT[], D improvements

2013-01-01 Thread Lawrence Crowl
On 12/28/12, Jonathan Wakely jwakely@gmail.com wrote: On 28 December 2012 01:51, Lawrence Crowl wrote: I'm not getting errors when converting from derived to base. E.g. the following compiles, when it should not. std::unique_ptrconst base [] acb_ad(new derived[3]); I get an error:

Re: [Patch, Darwin, ppc] constrain processor usage for m32.

2013-01-01 Thread Mike Stump
On Jan 1, 2013, at 10:03 AM, Tobias Netzel tobias.net...@googlemail.com wrote: Or do you have any other ideas? I don't. I'd grab the .s files (compile with -save-temps) and start stripping things out til it loads, then then last thing stripped was the thing that broke it.

Re: [patch] std::unique_ptrT[], D improvements

2013-01-01 Thread Jonathan Wakely
On 1 January 2013 20:40, Lawrence Crowl wrote: That was pilot error on my part. However, I've been having trouble when the argument to the constructor or reset has a conversion operator. The code does distinquish between a safe conversion to base and an unsafe conversion to derived. Here

Re: [patch] std::unique_ptrT[], D improvements

2013-01-01 Thread Lawrence Crowl
On 1/1/13, Jonathan Wakely jwakely@gmail.com wrote: On 1 January 2013 20:40, Lawrence Crowl wrote: That was pilot error on my part. However, I've been having trouble when the argument to the constructor or reset has a conversion operator. The code does distinquish between a safe

Re: [PATCH] libiberty simple object XCOFF support

2013-01-01 Thread David Edelsohn
On Tue, Jan 1, 2013 at 12:31 PM, Ian Lance Taylor i...@google.com wrote: On Tue, Jan 1, 2013 at 9:10 AM, Steven Bosscher stevenb@gmail.com wrote: Does XCOFF differ a lot from COFF? In a word, yes. While COFF and XCOFF share a distant ancestor, they are in effect completely different

Re: [PATCH] libiberty simple object XCOFF support

2013-01-01 Thread Ian Lance Taylor
On Tue, Jan 1, 2013 at 9:04 AM, David Edelsohn dje@gmail.com wrote: The attached patch is a start at libiberty simple object support for AIX XCOFF file format. With this patch, the simple object API can read and write XCOFF files. I need to investigate a little more about the proper

Re: [patch, libgfortran] PR55818 Reading a REAL from a file which doesn't end in a new line fails

2013-01-01 Thread Jerry DeLisle
This updated patch addresses the issues with infinities, nans, characters, and valid reals. OK for trunk? Test case attached. Regards, Jerry Index: list_read.c === --- list_read.c (revision 194731) +++ list_read.c (working copy)

[PATCH, committed] Update MAINTAINERS

2013-01-01 Thread Maxim Kuvyrkov
I've checked in the following patch to update my email address in MAINTAINERS. -- Maxim Kuvyrkov MAINTAINERS-Update-my-email.ChangeLog Description: Binary data MAINTAINERS-Update-my-email.patch Description: Binary data