Re: Dealing with compilers that pretend to be GCC

[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 macro
> for each extension.


I agree with that. And I even hope that if GCC 4.7 defined several macros, one 
for each
extensions, like e.g.
   __GCC_HAVE_INDIRECT_GOTO__  for the goto *x; feature
   __GCC_HAVE_STATEMENT_EXPR__ for statement expressions
etc then perhaps in several years other compilers would do likewise. We just 
have to
document our features and their corresponding macros...

Regards. 
   

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: Dealing with compilers that pretend to be GCC

[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 worked or not".  Therefore autoconf tests should not
just test __GNUC__, unless the only thing they're trying to be a test for is
whether __GUNC__ is defined or not.


That's very relevant for packages that are compiled and where you just 
install binaries and trivial headers. For libraries where headers contain 
non-trivial code (in C++, there may not even be a compiled part to the 
library), not so much. You can generate a config.h with autoconf, but then 
you need to install it. And if you use several compilers, or several 
versions of a compiler, or several sets of options from the same compiler, 
you get into a horrible mess. So we need to rely on preprocessor defines 
like __GNUC__ to identify what we can do.


We could also write autoconf bits for users of the library to include in 
their configure.ac, but most users don't use autoconf for their project, 
and with recursive dependencies it would quickly get out of hand.


--
Marc Glisse

Re: Dealing with compilers that pretend to be GCC

[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
supporting 100% of the GNU C extensions.  With this approach, you would
also need to add !defined for Clang, PGI, and probably others.


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).  Even more problematic IMO than testing __GNUC__ is
code that tests for particular versions of GCC.  There are versions of GCC
which have backported features from more recent GCC's (eg: GNAT from Ada Core
Technologies is like this).  I've seen this cause problems with code that
includes different header files depending on the gcc version, since the
compiler doesn't have the expected set of header files.

Ciao, Duncan.

Re: Dealing with compilers that pretend to be GCC

[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: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Dealing with compilers that pretend to be GCC

[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 time.

-Chris

On Jan 21, 2012, at 12:14 AM, Basile Starynkevitch  
wrote:

> 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 macro
>> for each extension.
> 
> 
> I agree with that. And I even hope that if GCC 4.7 defined several macros, 
> one for each
> extensions, like e.g.
>   __GCC_HAVE_INDIRECT_GOTO__  for the goto *x; feature
>   __GCC_HAVE_STATEMENT_EXPR__ for statement expressions
> etc then perhaps in several years other compilers would do likewise. We just 
> have to
> document our features and their corresponding macros...
> 
> Regards. 
> 
> 
> -- 
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes} ***

Re: Dealing with compilers that pretend to be GCC

[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's the fault of GCC, which should have defined a macro
>> for each extension.
> 
> 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?

If fact, some do:
http://clang.llvm.org/docs/LanguageExtensions.html#feature_check

-Chris

Re: Dealing with compilers that pretend to be GCC

[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 them first.

I said "whether it comes from GCC or not".  GCC didn't first implement
the extensions that don't come from GCC.

Re: Dealing with compilers that pretend to be GCC

[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

[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 compilers pretending to be GCC :)
>>>
>>> I think that's the fault of GCC, which should have defined a macro
>>> for each extension.
>>
>> 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?
>
> If fact, some do:
> http://clang.llvm.org/docs/LanguageExtensions.html#feature_check

Indeed, and it's a feature I like, well done :)

I just think bashing GCC (rather than filing enhancement requests or
contributing patches) for not doing the same is unproductive, and
saying it's GCC's fault that not all compilers do the same doesn't
even make sense.

Re: Dealing with compilers that pretend to be GCC

[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__ is code that tests for
> particular versions of GCC.  There are versions of GCC which have backported
> features from more recent GCC's (eg: GNAT from Ada Core Technologies is like
> this). 

Essentially every vendor is like this.  And not only for GCC, but for the 
kernel, etc.  But most of them do things properly and stay compatible.

-- 
Eric Botcazou

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

[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/Microsoft_Windows_SDK#64-bit_development

For the math functions, this is normally more a libc feature, so you 
might get very different results on different OS. Then again, by using 
-ffast-math, you allow the math functions to return any random value, 
so I can think of ways to make it even faster ;-)


Thanks, Marc--I added results from the 64-bit version of MS VC 10 via 
your link.

Re: Lapack tester

[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 I'm not sure.  No reply from the
Lapack guys yet.

The other failures - well, I'm not an expert on Lapack.  They
are in the range of what others report too.



Being semi-automatic, can you run the timing tests, too?  These
would obviously reveal possible performance regressions.  It
would also be interesting to see if -ftree-vectorize helps
performance.


Timing tests aren't included in Lapack 3.4.0 any more.


Against my better judgement, I'll suggest a run with
'-O3 -ffast-math'.  It seems a large number of gfortran
users use -ffast-math.


Without modifications, -funsafe-math-optimizations sends some
Lapack tests into endless loops, so -ffast-math isn't really an
option :-)

Thomas

GCCPLUGIN_VERSION and plugin-version.h

[Basile Starynkevitch]

Hello All,

I was and I am still in favor of providing macros like GCCPLUGIN_VERSION in 
plugin
header files. And in the generated and installed plugin-version.h we rightly 
have

 generated gcc/plugin-version.h ##
#include "configargs.h"

#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 devphase[] = "experimental";
static char revision[] = "[trunk revision 183369]";

/* FIXME plugins: We should make the version information more precise.
   One way to do is to add a checksum. */

static struct plugin_gcc_version gcc_version = {basever, datestamp,
devphase, revision,
configuration_arguments};
 end of gcc/plugin-version.h ##



And the generated configargs.h has (sorry for the wrong :
## generated gcc/configargs.h 
/* Generated automatically. */
static const char configuration_arguments[] = 
"/usr/src/Lang/gcc-trunk-bstarynk/configure
--program-suffix=-trunk --libdir=/usr/local/lib/gcc-trunk
--libexecdir=/usr/local/libexec/gcc-trunk
--with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ 
--enable-maintainer-mode
--enable-plugins --disable-bootstrap --enable-lto 
LIBS=-L/usr/lib/x86_64-linux-gnu/
--enable-languages=c,c++,lto CC='gcc -g' CXX='g++ -g' :
(reconfigured) /usr/src/Lang/gcc-trunk-bstarynk/configure 
--program-suffix=-trunk
--libdir=/usr/local/lib/gcc-trunk --libexecdir=/usr/local/libexec/gcc-trunk
--with-gxx-include-dir=/usr/local/lib/gcc-trunk/include/c++/ 
--enable-maintainer-mode
--enable-plugins --disable-bootstrap --enable-lto 
LIBS=-L/usr/lib/x86_64-linux-gnu/
--enable-languages=c,c++,lto CC='gcc -g' CXX='g++ -g'"; 
static const char thread_model[] = "posix";

static const struct {
  const char *name, *value;
} configure_default_options[] = { { "cpu", "generic" }, { "arch", "x86-64" } };
 end gcc/configargs.h 

(BTW, the configuration_arguments is on one big line which might have been 
broken by
copy/pasting here)


However, I find something troublesome. A plugin can obviously be made of 
several files
sharing a common plugin-specific header (which is melt-run.h for MELT). And 
that header
wants to #include "plugin-version.h" quite early to precisely get the 
GCCPLUGIN_VERSION
macro quite early (and it could do conditional preprocessing like e.g. #if
GCCPLUGIN_VERSION>4007 etc).

In that case, all the files compiled by the plugin would contain the static 
constants
configuration_arguments,  thread_model, configure_default_options, basever, 
datestamp,
devphase, revision, which I find quite bad, first because of unintended name 
clash (a
plugin would easily use the identifier revision), and because the same static 
data would
be in every object file of that plugin.

I believe it is a bug (albeit a minor one) to be improved before releasing 4.7

We could improve it 
   first, by generating constant names starting with a common prefix, perhaps 
gcc_, so we
would generate gcc_configuration_arguments, ... gcc_revision which minimize 
name clashes
with plugin code.

   second, by generating the pre-processor macros (and only them) in a separate 
file,
perhaps gcc/plugin-version-info.h, which would be #include-d from 
gcc/plugin-version.h,
and which should be documented as includable early from plugin headers, and 
containing
something like

## proposed generated gcc/plugin-version-info.h 

#ifndef GCCPLUGIN_VERSION
/* generated file for GCC plugins - DO NOT EDIT */
#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)
#endif /*GCCPLUGIN_VERSION*/
### end of gcc/plugin-version-info.h 
###

Notice that there are no static data in the above file; then we would have 

## proposed generated gcc/plugin-version.h 

#include "plugin-version-info.h"
#include "configargs.h"

static char gcc_basever[] = "4.7.0";
static char gcc_datestamp[] = "20120121";
static char gcc_devphase[] = "experimental";
static char gcc_revision[] = "[trunk revision 183369]";

/* FIXME plugins: We should make the version information more precise.
   One way to do is to add a checksum. */

static struct plugin_gcc_version gcc_version = {g

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

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


###
NEWS for 0.9.3 MELT plugin for gcc-4.6 (and future gcc-4.7)
January ??th, 2012

New features:

Language improvements
=

Ability to define a named value with the (DEFINE  ) construct

   More support notably for Gimple & Tree
   ==
Added more cmatchers etc.

   Runtime improvement
   ===

Generation of timestamping C file foo+melttime.h included from
generated descriptor file foo+meltdesc.c from foo.melt 

Numerous bug fixes

##

Bugs reports are welcome

Regards.


-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

gcc-4.7-20120121 is now available

[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 revision 183380

You'll find:

 gcc-4.7-20120121.tar.bz2 Complete GCC

  MD5=b2c4a9765fc7eca38970a8ec39ae35b9
  SHA1=76e46721ee9fd31dbb73cd77f96b7ce146056199

Diffs from 4.7-20120114 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

RTL AND Instruction

[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_rtx_SET.  I could
insert inline assembly with the ASM_OPERANDS macro, but I really want to do this
with pure RTL.  Essentially, I just want to emit:  "and %eax, $0x7"

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.  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);

Thanks for any insight into this.  On a side note, this is just for a
side-project, and I am trying to get a better grasp of RTL.  I have gone through
the internals manual for RTL and Machine Descriptions, but seems I am still
having a bit of trouble.

-Matt

Re: RTL AND Instruction

[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.  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);

Looking at the i386 port (when the 64-bit part of it is active)
it looks like you need to emit a parallel with a clobber of the
flags register for this to be recognized.

It seems an odd way to do anything (emitting raw rtl in the
middle of anything, unless it's in the prologue or epilogue),
which makes me think there's a better alternative for whatever
you're trying to accomplish.

brgds, H-P

RE: readonly register

[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 prevent
> the use of some registers during the reload pass without turning
> them into fixed register ?

I can't think of another way than to use different (narrower)
register constraints for the destination operand than the source
operands for the instructions which can take $INP as a source
operand, with the source operand register class to include the
register (sub)class for $INP, but this latter register class
must not be included in GENERAL_REGS nor of course the
destination register class.  (Though, the source register class
can be a superclass that includes GENERAL_REGS and the register
class for $INP, whatever applies.)

This wouldn't "prevent the use of some registers during the
reload pass" but that wasn't the original goal nor a reasonably
doable one AFAIK.

With reservations for possibly not understanding your problem.

> -Message d'origine-
> De : Ian Lance Taylor [mailto:i...@google.com]
> Envoyé : jeudi 19 janvier 2012 00:17
> À : BELBACHIR Selim
> Cc : gcc@gcc.gnu.org
> Objet : Re: readonly register
>
> BELBACHIR Selim  writes:
>
> > I'm trying to support an 'in' instruction which reads a value on a 
> > peripheral and writes it into a $INP register.
> > The $INP register can be used in almost every insn as input operand (add, 
> > sub, mul ...).
> > I defined a builting to access the 'in' instruction.
> >
> > How should I express to gcc that the $INP register can only be 'read' and 
> > must never be written?
> >
> > For the moment, I encounter a problem during IRA pass where some of my 
> > 'classic' registers are reloaded into $INP (apparently because I have no 
> > register left).
>
> If you have a builtin to access the value, then you should be able to
> make it a fixed register.  The register allocator will never try to
> allocate a fixed register.

brgds, H-P

RE: readonly register

[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
> > will prevent me from doing this. Is there another way to prevent
> > the use of some registers during the reload pass without turning
> > them into fixed register ?
>
> I can't think of another way than to use different (narrower)
> register constraints for the destination operand than the source
> operands for the instructions which can take $INP as a source
> operand, with the source operand register class to include the
> register (sub)class for $INP, but this latter register class
> must not be included in GENERAL_REGS nor of course the
> destination register class.

And to clarify, the $INP register class would (only) be valid as
a destination in the insns generated by the builtins that Ian
suggested; but their expanders would not generate fixed
registers.  (You might trip some reload bugs, but those should
just be bugs at least if you keep the move-cost for classes with
those $INP registers greater than 2 and greater than other
classes and possibly moves to/from memory.  There, that should
cover it.)

brgds, H-P

Re: RTL AND Instruction

[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 do.  If you know that your target
has a DImode and instruction, then you normally want to call gen_anddi3.
If you don't know whether it does, then you generally want to call
expand_binop.

Ian