Re: powerpc64 bootstrap broken due to libsanitizer merge from upstream

On Fri, 2013-11-08 at 00:03 +0100, Steven Bosscher wrote: > powerpc64-linux bootstrap is broken by the libsanitizer merge: I already reported the failures here: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00312.html It seems others have reported it breaks bootstrap for them as well on other

Architecture maintainers: please define TARGET_ATOMIC_ASSIGN_EXPAND_FENV

Architecture maintainers please note: if your architecture supports floating-point exceptions, you should add a definition of the TARGET_ATOMIC_ASSIGN_EXPAND_FENV target hook so that they are handled correctly for C11 atomic compound assignments. This will normally generate inline code togethe

powerpc64 bootstrap broken due to libsanitizer merge from upstream

Hello, powerpc64-linux bootstrap is broken by the libsanitizer merge: In file included from ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:21:0: /usr/include/asm/stat.h:31:2: error: 'ino_t' does not name a type ino_t st_ino; ^ /usr/include/asm/stat.h:34:2:

Ann: MELT 1.0.1 plugin for GCC 4.7 & 4.8

Dear All, I am delighted to announce MELT 1.0.1 plugin for GCC 4.7 & 4.8 ( a bug-fixing release w.r.t MELT 1.0) Please download it from http://gcc-melt.org/melt-1.0.1-plugin-for-gcc-4.7-or-4.8.tar.bz2 It is a bzip2-ed tar source file of md5sum c7c3dbf3edd4e5747ddcf4a30dad41c4 and of 3754405 byte

Re: [RFC] Target compilation for offloading

On Thu, Nov 07, 2013 at 07:36:06PM +0400, Andrey Turetskiy wrote: > > Note, configure options should be either --with- or --enable- prefixed. > > Plus, it is probably better to use configuration triplets there. > > Do you mean smth like this: > configure --build=x86 --host=x86 --target=x86,mic,ptx

Re: [RFC] Target compilation for offloading

> Note, configure options should be either --with- or --enable- prefixed. > Plus, it is probably better to use configuration triplets there. Do you mean smth like this: configure --build=x86 --host=x86 --target=x86,mic,ptx Then "make" should build 3 gcc: x86 native and crosses for mic and ptx. -

Re: [c++11] Question about __cxa_throw_bad_array_new_length

*ping* thanks, Alexander 2013/9/23 Alexander Ivchenko : > Hi, > > When I compile the following code (modified version of > g++.dg/cpp0x/bad_array_new1.C without try/catch): > > // { dg-options -std=c++11 } > // { dg-do run } > > #include > > void * f(int i) > { > return new int[i]; > } > > in

Re: Mothballing C11 atomic work for now.

On Thu, Nov 07, 2013 at 01:23:20PM +, Joseph S. Myers wrote: > On Thu, 7 Nov 2013, Jakub Jelinek wrote: > > > On Wed, Nov 06, 2013 at 10:07:36PM +, Joseph S. Myers wrote: > > > The patch I've posted at > > > is intended to > > > b

Re: Mothballing C11 atomic work for now.

On Thu, 7 Nov 2013, Jakub Jelinek wrote: > On Wed, Nov 06, 2013 at 10:07:36PM +, Joseph S. Myers wrote: > > The patch I've posted at > > is intended to > > be mainline-ready (with the hopes that other people may pick up the ObjC > >

Dependency confusion in sched-deps

Hello, I am slightly unsure if the confusion is in the dependencies or it's my confusion. I have tracked this strange behaviour which only occurs when we need to flush pending instructions due to the pending list becoming too large (gcc 4.8, haven't tried with trunk). I have two stores: 85:

Re: Built-in testing for signaling nan?

On Nov 7 2013, FX wrote: Given how murky signaling NaNs are in practice, I think it's worth asking: why do you want to know? Because I am writing an implementation of the IEEE support modules in GNU Fortran, which are part of the Fortran 2003 standard. And the standard provides for a procedu

Re: Mothballing C11 atomic work for now.

On Wed, Nov 06, 2013 at 10:07:36PM +, Joseph S. Myers wrote: > The patch I've posted at > is intended to > be mainline-ready (with the hopes that other people may pick up the ObjC > and OpenMP issues, and floating-point handling for n