Re: Dealing with compilers that pretend to be GCC

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 ea

Re: Dealing with compilers that pretend to be GCC

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. -- Vincent Lefèvre - Web:

Re: Dealing with compilers that pretend to be GCC

On 20/01/2012 23:28, Jonathan Wakely wrote: > 2012/1/20 Ludovic Courtès: >> 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. > > May I pol

Re: Dealing with compilers that pretend to be GCC

Hi, Cary Coutant skribis: >> 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. > > Having worked on the other side for a while -- for a v

Re: Dealing with compilers that pretend to be GCC

Hi, James Dennett skribis: > If there were a defined way to test for extensions from within C (or > C++), then this problem would be much reduced. Clang has something of > a framework to query support for different features, and I drafted a > proposal for something similar that would work across

Re: Dealing with compilers that pretend to be GCC

2012/1/20 Ludovic Courtès: > > 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. May I politely suggest that this is the wrong place to compl

gcc-4.6-20120120 is now available

Snapshot gcc-4.6-20120120 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120120/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: Dealing with compilers that pretend to be GCC

On Fri, Jan 20, 2012 at 2:41 PM, Cary Coutant wrote: >> 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. > > Having worked on the other si

Re: Dealing with compilers that pretend to be GCC

> 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. Having worked on the other side for a while -- for a vendor whose compiler supported many

Re: Getting rid of duplicate .debug_ranges

>> Is there a way to detect that basic blocks have the same range even >> though they have different block numbers? Or am I not looking/thinking >> about this issue correctly? I may be oversimplifying this, but it seems that gen_inlined_subroutine_die generates a DW_AT_ranges list, then calls decl

Re: Dealing with compilers that pretend to be GCC

Hi Vincent, Vincent Lefevre skribis: > 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

Re: Access to source code from an analyser

> "Manuel" == Manuel López-Ibáñez writes: Manuel> However, to be honest, even if you implement your own source-location Manuel> manager in your own plugin code, I don't think it will be very precise Manuel> because the internal representation of GCC C/C++ FE is not very close Manuel> to the a

Re: gfortran 4.6 incompatible with previous?

Sewell, Granville wrote: I know that gfortran 4.3 was not compatible with earlier versions (can't mix object code), but now a user is telling me that 4.6 is not compatible with 4.3, is that true? The library .so version number of GCC 4.3 to 4.7 is the same and no symbol was deleted from libgf

gfortran 4.6 incompatible with previous?

I know that gfortran 4.3 was not compatible with earlier versions (can't mix object code), but now a user is telling me that 4.6 is not compatible with 4.3, is that true? Thanks, Granville Sewell Mathematics dept. UTEP

Re: Access to source code from an analyser

> On Thu, 2012-01-19 at 14:06 +0100, Alberto Lozano Alelu wrote: >> Hello. >> >> Thanks for your fast response. >> >> With expand_location I get struct expanded_location which has these fields: >> type = struct { >> const char *file; >> int line; >> int column; >> unsigned char sysp

Re: Dealing with compilers that pretend to be GCC

On 20/01/2012 11:19, Peter Rosin wrote: > Dave Korn skrev 2012-01-20 01:15: > > *snip* > >>That could be tricky because I guess you won't be able to use >> libtool at configure time. > > *snip* > > It's possible to use libtool at configure time, but you need to invoke > LT_OUTPUT be

Re: Interface Method Table

Matt Davis writes: > For a Go program being compiled in gcc, from the middle end, is there a way to > figure-out which routines make up the interface-method-table? I could check > the > mangled name of the method table, but is there another way to deduce what > methods compose it from the middl

How to define a built-in 24-bit type?

Hi. avr-gcc implements a 24-bit scalar integer types __int24 and __uint24 in avr.c:TARGET_INIT_BUILTINS like so: tree int24_type = make_signed_type (GET_MODE_BITSIZE (PSImode)); tree uint24_type = make_unsigned_type (GET_MODE_BITSIZE (PSImode)); (*lang_hooks.types.register_builtin_type) (

const_int vs. const_double on 64-bit vs. 32-bit build platform

Hi, in avr.md there is (define_insn "map_bitsqi" [(set (match_operand:QI 0 "register_operand" "=d") (unspec:QI [(match_operand:SI 1 "const_int_operand" "n") (match_operand:QI 2 "register_operand" "r")] UNSPEC_MAP_BITS))] "" { re

Re: Dealing with compilers that pretend to be GCC

Dave Korn skrev 2012-01-20 01:15: *snip* >That could be tricky because I guess you won't be able to use > libtool at configure time. *snip* It's possible to use libtool at configure time, but you need to invoke LT_OUTPUT before you do so. Or is there a reason for that not to work i

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

On Fri, Jan 20, 2012 at 3:43 AM, willus.com wrote: > On 1/19/2012 6:29 AM, Richard Guenther wrote: >> >> On Thu, Jan 19, 2012 at 3:27 PM, willus.com  wrote: >>> >>> On 1/19/2012 2:59 AM, Richard Guenther wrote: On Thu, Jan 19, 2012 at 7:37 AM, Marc Glisse  wrote: > > On Wed,