Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Basile Starynkevitch
On Sat, 21 Jan 2012 01:32:29 +0100 Vincent Lefevre wrote: > On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: > > May I politely suggest that this is the wrong place to complain about > > other compilers pretending to be GCC :) > > I think that's the fault of GCC, which should have defined a

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Marc Glisse
On Fri, 20 Jan 2012, Dave Korn wrote: OTOH the entire point of autotools is that any toolchain (even GCC itself) sometimes has bugs or unimplemented features, and you just can't argue with the principle that the definitive test is always going to be "try and use the feature and verify if it wor

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Duncan Sands
Hi Ludo, For ICC, one can test __ICC. For instance, here's what we have in mpfr.h (for the use of __builtin_constant_p and __extension__ ({ ... })): #if defined (__GNUC__)&& !defined(__ICC)&& !defined(__cplusplus) Yeah, but it’s a shame that those compilers define __GNUC__ without supportin

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Vincent Lefevre
On 2012-01-21 01:24:19 +, Jonathan Wakely wrote: > And what about the fact other compilers haven't defined such a macro > for each extension they implement, whether it comes from GCC or not, > is that GCC's fault too? But GCC implemented them first. -- Vincent Lefèvre - Web:

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Chris Lattner
Why not just implement the clang feature checking macros? http://clang.llvm.org/docs/LanguageExtensions.html#feature_check Besides fixing the whole problem that this thread identifies, it doesn't require cramming tons of macros into the initial preprocessor state, speeding up compiler startup ti

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Chris Lattner
On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote: > On 21 January 2012 00:32, Vincent Lefevre wrote: >> On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: >>> May I politely suggest that this is the wrong place to complain about >>> other compilers pretending to be GCC :) >> >> I think that'

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Jonathan Wakely
On 21 January 2012 13:42, Vincent Lefevre wrote: > On 2012-01-21 01:24:19 +, Jonathan Wakely wrote: >> And what about the fact other compilers haven't defined such a macro >> for each extension they implement, whether it comes from GCC or not, >> is that GCC's fault too? > > But GCC implemented

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Miles Bader
Chris Lattner writes: > Why not just implement the clang feature checking macros? > http://clang.llvm.org/docs/LanguageExtensions.html#feature_check Yes, please. [Hopefully with a smidgen of cooperation regarding the actual feature names...] -miles -- Dawn, n. When men of reason go to bed.

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Jonathan Wakely
On 21 January 2012 13:55, Chris Lattner wrote: > On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote: > >> On 21 January 2012 00:32, Vincent Lefevre wrote: >>> On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: May I politely suggest that this is the wrong place to complain about other

Re: Dealing with compilers that pretend to be GCC

2012-01-21 Thread Eric Botcazou
> even GCC may not support 100% of the GCC extensions! For example, you can > find hacked GCC's out there which disable nested function support by > default (I think Apple did this). I'd think that such hacked versions aren't really GCC anymore. > Even more problematic IMO than testing __GNUC__

Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others

2012-01-21 Thread willus.com
On 1/18/2012 10:37 PM, Marc Glisse wrote: On Wed, 18 Jan 2012, willus.com wrote: For those who might be interested, I've recently benchmarked gcc 4.6.3 (and 3.4.2) vs. Intel v11 and Microsoft (in Windows 7) here: http://willus.com/ccomp_benchmark2.shtml http://en.wikipedia.org/wiki/Microsof

Re: Lapack tester

2012-01-21 Thread Thomas Koenig
Hi Steve, PR 51751 seems to concern only complex*16 failures. Have you had a chance to look at the real and double precision errors? That PR is in a different category, because input values to a BLAS routine are wrong. I suspect an error in the testing (relying on uninitialized memory), but

GCCPLUGIN_VERSION and plugin-version.h

2012-01-21 Thread Basile Starynkevitch
; #define GCCPLUGIN_VERSION_MAJOR 4 #define GCCPLUGIN_VERSION_MINOR 7 #define GCCPLUGIN_VERSION_PATCHLEVEL 0 #define GCCPLUGIN_VERSION (GCCPLUGIN_VERSION_MAJOR*1000 + GCCPLUGIN_VERSION_MINOR) static char basever[] = "4.7.0"; static char datestamp[] = "20120121"; static char devph

ANNOUNCE: MELT plugin 0.9.3 release candidate 1 for GCC 4.6 (& probably 4.7)

2012-01-21 Thread Basile Starynkevitch
Hello All, It is my pleasure to announce the release candidate 1 of MELT plugin 0.9.3 for GCC 4.6 (& 4.7 when available) Please download the gzipped tar archive from http://gcc-melt.org/melt-0.9.3rc1-plugin-for-gcc-4.6.tgz (file of 4229953 bytes of md5sum 37bea610218835f747f78b1a6c5d5604)

gcc-4.7-20120121 is now available

2012-01-21 Thread gccadmin
Snapshot gcc-4.7-20120121 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120121/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk

RTL AND Instruction

2012-01-21 Thread Matt Davis
Hello (again), I have a case where I need to emit an AND operation on a register and a const_int value. The machine architecture I am looking at, for the .md, is an i386. Anyways, after matching things up with the rtl.def and what is in the .md, I use the gen_rtx_AND macro and wrap that in a gen

Re: RTL AND Instruction

2012-01-21 Thread Hans-Peter Nilsson
On Sun, 22 Jan 2012, Matt Davis wrote: > Once I emit my rtx into the list of insns, GCC gives me an "unrecognized insn" > error. I can trace the code through the first part of the condition, > specified > in i386.md, "ix86_binary_operator_ok," and that passes fine from the > "anddi_1" define_insn

RE: readonly register

2012-01-21 Thread Hans-Peter Nilsson
On Thu, 19 Jan 2012, BELBACHIR Selim wrote: > In fact my final purpose is to replace $INP by a register bank > in order to be able to read several inputs using pipelined > instructions (and instruction scheduler). The fixed reg solution > will prevent me from doing this. Is there another way to pr

RE: readonly register

2012-01-21 Thread Hans-Peter Nilsson
On Sun, 22 Jan 2012, Hans-Peter Nilsson wrote: > On Thu, 19 Jan 2012, BELBACHIR Selim wrote: > > > In fact my final purpose is to replace $INP by a register bank > > in order to be able to read several inputs using pipelined > > instructions (and instruction scheduler). The fixed reg solution > > w

Re: RTL AND Instruction

2012-01-21 Thread Ian Lance Taylor
Matt Davis writes: > What I have in my source is the following: > > rtx eax = gen_rtx_REG(DImode, 0); > rtx and = gen_rtx_AND(DImode, eax, gen_rtx_CONST_INT(VOIDmode, 7)); > and = gen_rtx_SET(DImode, eax, and); > emit_insn_before(and, insn); This is normally not what you want to