Re: Dealing with compilers that pretend to be GCC

2012-01-22 Thread Vincent Lefevre
On 2012-01-21 13:58:53 +, Jonathan Wakely wrote:
> 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.

I thought they were all coming from GCC (an impression partly given
by the fact that ICC defines __GNUC__).

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

2012-01-22 Thread Jonathan Wakely
On 22 January 2012 11:34, Vincent Lefevre wrote:
> On 2012-01-21 13:58:53 +, Jonathan Wakely wrote:
>> 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.
>
> I thought they were all coming from GCC (an impression partly given
> by the fact that ICC defines __GNUC__).

I now have no idea what this discussion is about so will leave it there.


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

2012-01-22 Thread Basile Starynkevitch
Hello All,

It is my pleasure to announce the release candidate 2 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.3rc2-plugin-for-gcc-4.6.tgz
(file of 4231496 bytes of md5sum 970024b88e82357fe1440eb767c6f07a)
This is extracted from MELT bra,nch svn rev 183390

(with respect to 0.9.3rc1 announced yesterday I corrected a few bugs)


###
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 to gcc-m...@googlegroups.com & to me.

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: trouble emilinating redundant compares

2012-01-22 Thread Paul S

Thanks Dave,

I would never have guessed from gccinternals.pdf that it is possible to 
use mode iterators to select predicates & constraints ... I think I have 
a use for this today :-)


Cheers, Paul.

On 20/01/12 10:26, Dave Korn wrote:

On 17/01/2012 21:16, Paul S wrote:

   

For example the i386 seems to use predicates and constraints of the form
<*_operand>  and  for the reload versions of these instructions -
and I haven't been able to find definitions of these or a mention in
gcc_internals.pdf of any special meaning assigned to the<>  notation.
 

   See http://gcc.gnu.org/onlinedocs/gccint/Substitutions.html, and take a look
for the define_[code/mode]_[attr/iterator] definitions around line ~650ish of
i386.md

 cheers,
   DaveK




   




[GCC Steering Committee] Interix OS maintainer

2012-01-22 Thread Douglas Rupp


If it please the Committee: I volunteer as the Interix maintainer.

--Douglas Rupp



Re: trouble emilinating redundant compares

2012-01-22 Thread Richard Henderson
On 01/18/2012 08:16 AM, Paul S wrote:
> Thanks H-P,
> 
> That worked first time !
> 
> For a few days I had been searching the non cc0 ports for hints. Two
> of the ports don't bother using the set CC side effect to avoid
> compares and the others are obfuscated by the fact that they
> (understandably) use custom CC modes and the reload conditions aren't
> obvious - even when I inspected the .c file CCmode tests.

Don't look at i386 -- it doesn't use compare-elim.c.
Look at the mn10300 and rx ports instead.


r~


Re: x86_64 -mcmodel=smallhigh, cont'd

2012-01-22 Thread Richard Henderson
On 01/18/2012 08:20 AM, Jed Davis wrote:
> But my other question is: is there interest in having this change
> contributed?  It's not inherently vendor-specific, but I'm having trouble
> thinking of anyone else who'd want to use it, and I don't know what GCC's
> policy is on features like that.

It would be useful in certain other conditions as well, such as
userspace emulators that want the low 4g free for use by the
emulated address space.


r~


Re: [GCC Steering Committee] Interix OS maintainer

2012-01-22 Thread Gerald Pfeifer
On Sun, 22 Jan 2012, Douglas Rupp wrote:
> If it please the Committee: I volunteer as the Interix maintainer.

You forgot to attach two passport photos and your credit card
information for the processing fee, Douglas, but we can attend
to that later. :-)

On a more serious note, I'm taking care of raising this.

Gerald


Re: trouble emilinating redundant compares

2012-01-22 Thread Hans-Peter Nilsson
On Mon, 23 Jan 2012, Paul S wrote:
> Thanks Dave,
>
> I would never have guessed from gccinternals.pdf that it is possible to use
> mode iterators to select predicates & constraints ...

Really?  If you but if you have suggestions for improving the
documentation, that'd be welcome.

> I think I have a use for
> this today :-)
>
> Cheers, Paul.
>
> On 20/01/12 10:26, Dave Korn wrote:
> > On 17/01/2012 21:16, Paul S wrote:
> >
> >
> > > For example the i386 seems to use predicates and constraints of the form
> > > <*_operand>  and  for the reload versions of these instructions -
> > > and I haven't been able to find definitions of these or a mention in
> > > gcc_internals.pdf of any special meaning assigned to the<>  notation.
> > >
> >See http://gcc.gnu.org/onlinedocs/gccint/Substitutions.html, and take a
> > look
> > for the define_[code/mode]_[attr/iterator] definitions around line ~650ish
> > of
> > i386.md
> >
> >  cheers,
> >DaveK
> >
> >
> >
> >
> >