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

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

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

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

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

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:

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

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