Re: LLVM as a gcc plugin?

[Duncan Sands]

Hi,


Some time ago, there was a discussion about integrating LLVM and GCC
[1]. However, with plugin infrastructure in place, could LLVM be
plugged into GCC as an additional optimization plugin?


I plan to start working on an llvm plugin any day now.

Ciao,

Duncan.

Re: [4.3] Invalid code or invalid optimisation?

[Andrew Haley]

Dave Korn wrote:

>   Adding a "memory" clobber to the inline asm works around the problem,
> causing 4.3 series to generate the same assembly as head, but I think it's a
> sledgehammer approach.  Am I asking too much of GCC to not sink the store, or
> is 4.3 doing something wrong?  I /think/ that the fact that there's a volatile
> store in ilockcmpexch means the earlier store shouldn't be moved past it, and
> that GCC is perhaps missing that the asm's output operand effectively
> represents a volatile write through *t, but I could be misunderstanding the
> rules about volatile.  Anyone got their language lawyer's hat on at the 
> moment?

You could just look at the standard, y'know.  Volatile stores only block other
volatile stores: they don't block *all* stores.  If you really want a complete
memory barrier, which in a mutex you surely do, then you're going to have to
clobber memory.

Andrew.

Re: [4.3] Invalid code or invalid optimisation?

[Dave Korn]

Andrew Haley wrote:
> Dave Korn wrote:
> 
>>   Adding a "memory" clobber to the inline asm works around the problem,
>> causing 4.3 series to generate the same assembly as head, but I think it's a
>> sledgehammer approach.  Am I asking too much of GCC to not sink the store, or
>> is 4.3 doing something wrong?  I /think/ that the fact that there's a 
>> volatile
>> store in ilockcmpexch means the earlier store shouldn't be moved past it, and
>> that GCC is perhaps missing that the asm's output operand effectively
>> represents a volatile write through *t, but I could be misunderstanding the
>> rules about volatile.  Anyone got their language lawyer's hat on at the 
>> moment?
> 
> You could just look at the standard, y'know.

  I did but I get as far as all that stuff about "The party of the third part
shall be known herein as the party of the third part" and find it very
difficult to know whether what it looks like it says actually is what it is
trying to say.

>  Volatile stores only block other
> volatile stores: they don't block *all* stores.  If you really want a complete
> memory barrier, which in a mutex you surely do, then you're going to have to
> clobber memory.

  Ah.  That suggests that HEAD is in fact _missing_ an optimisation that 4.3
gets right.  Maybe I should file a PR after all.

cheers,
  DaveK

Re: [4.3] Invalid code or invalid optimisation?

[Dave Korn]

Dave Korn wrote:
> Andrew Haley wrote:

>>  Volatile stores only block other
>> volatile stores: they don't block *all* stores.  If you really want a 
>> complete
>> memory barrier, which in a mutex you surely do, then you're going to have to
>> clobber memory.
> 
>   Ah.  That suggests that HEAD is in fact _missing_ an optimisation that 4.3
> gets right.  Maybe I should file a PR after all.

  It also suggests that the register motion is fairly gratuitous, I think.

movl%eax, -12(%ebp)  # tmp79, ret
movl-12(%ebp), %eax  # ret, D.2120

  Given that ret is a local variable that goes immediately out of scope, I
can't see any reason to update the stack slot.  I can prevent this happening
by declaring the temporary as 'register __typeof (*t) ret __asm ("%eax");' but
doesn't this mean we're missing a trick here between some combination of
regalloc, copyprop and dead-store elimination?

cheers,
  DaveK

Re: [4.3] Invalid code or invalid optimisation?

[Andrew Haley]

Dave Korn wrote:
> Andrew Haley wrote:
>> Dave Korn wrote:
>>
>>>   Adding a "memory" clobber to the inline asm works around the problem,
>>> causing 4.3 series to generate the same assembly as head, but I think it's a
>>> sledgehammer approach.  Am I asking too much of GCC to not sink the store, 
>>> or
>>> is 4.3 doing something wrong?  I /think/ that the fact that there's a 
>>> volatile
>>> store in ilockcmpexch means the earlier store shouldn't be moved past it, 
>>> and
>>> that GCC is perhaps missing that the asm's output operand effectively
>>> represents a volatile write through *t, but I could be misunderstanding the
>>> rules about volatile.  Anyone got their language lawyer's hat on at the 
>>> moment?
>> You could just look at the standard, y'know.
>
>   I did but I get as far as all that stuff about "The party of the third part
> shall be known herein as the party of the third part" and find it very
> difficult to know whether what it looks like it says actually is what it is
> trying to say.

It's just a matter of learning the language in which it's written, and
that's like learning a programming language.  If you look at 6.7.3
Para 6 it says

"... An object that has volatile-qualified type may be modified in ways
unknown to the implementation or have other unknown side effects.
Therefore any expression referring to such an object shall be
evaluated strictly according to the rules of the abstract machine, as
described in 5.1.2.3.  Furthermore, at every sequence point the value
last stored in the object shall agree with that prescribed by the
abstract machine, except as modified by the unknown factors mentioned
previously..."

Now, this is admittedly gobbledygook, but it's important to note that
it only says that volatile stores may not be moved across sequence
points.  It does *not* say that other stores may not be moved across
volatile stores, which is what you were hoping for.

We already discussed this subject before: see
http://gcc.gnu.org/ml/gcc/2007-10/msg00477.html
and the very long thread that followed.

>> Volatile stores only block other volatile stores: they don't block
>> *all* stores.  If you really want a complete memory barrier, which
>> in a mutex you surely do, then you're going to have to clobber
>> memory.
>
>   Ah.  That suggests that HEAD is in fact _missing_ an optimisation
> that 4.3 gets right.  Maybe I should file a PR after all.

Maybe.

Andrew.

Re: LLVM as a gcc plugin?

[Rafael Espindola]

> I'd love to see this, but I can't contribute to it directly.  I think the
> plugin interfaces would need small extensions, but there are no specific
> technical issues preventing it from happening.  LLVM has certainly
> progressed a lot since that (really old) email went out :)

I can help a bit.

There was some talk about it on #gcc. A plugin should be able to see
all the GCC IL, so it should be able to convert it to LLVM. Keeping
the current llvm-gcc interface would require some hacks

*) The plugin will have to call exit to keep gcc's code generation from running.
*) It will have to remove and recreate the .s file that is being
output. Not sure if this will work.
*) Gcc always produces .o files by calling the assembler, so "-c
-emit-llvm" will not work.
*) The plugis options will be of the form -fplugin-arg-llvm-emit-llvm

One way to avoid these problems is to make llvm-gcc a gcc wrapper that
runs gcc with the llvm plugin, converts command line options and in
the case of -c -emit-llvm calls llvm-as.

Another source of problem will be the early transformations that gcc
does and that are normally disabled in llvm-gcc. The one that I
remember right now is c++ thunk generation.

> -Chris
>

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Re: LLVM as a gcc plugin?

[Steven Bosscher]

On Thu, Jun 4, 2009 at 12:14 PM, Rafael Espindola  wrote:
>> I'd love to see this, but I can't contribute to it directly.  I think the
>> plugin interfaces would need small extensions, but there are no specific
>> technical issues preventing it from happening.  LLVM has certainly
>> progressed a lot since that (really old) email went out :)
>
> I can help a bit.

Excuse me if this is a stupid question, but eh -- why would you want
to make an LLVM plugin?  Aren't LLVM and GCC doing just fine as
competing compilers?

Ciao!
Steven

Re: LLVM as a gcc plugin?

[Rafael Espindola]

> Excuse me if this is a stupid question, but eh -- why would you want
> to make an LLVM plugin?  Aren't LLVM and GCC doing just fine as
> competing compilers?

LLVM is a toolkit. There is a patched version of GCC that uses LLVM
(llvm-gcc). This is particularly important for fortran and ada since
clang supports only c like languages.

The hope is that a plugin will be easier to maintain than llvm-gcc.

> Ciao!
> Steven
>

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

GCC 4.5.0 Status Report (2009-06-04)

[Richard Guenther]

Status
==

The trunk is in Stage 1.  As previously stated, we expect that Stage 1
will last through at least July.

There are still large pending merges we are aware of, specifically
the VTA and LTO branches will be considered when deciding when to
go to Stage 3.

We hope to see you all at this years GCC Summit.

Quality Data


Priority  # Change from Last Report
--- ---
P1   15 - 1
P2   92 + 9
P30 - 1   
--- ---
Total   107 + 7


Previous Report
===

http://gcc.gnu.org/ml/gcc/2009-05/msg00092.html

The next report for 4.5.0 will be sent by Jakub.

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: LLVM as a gcc plugin?

[Chris Lattner]

On Jun 3, 2009, at 11:59 PM, Miles Bader wrote:


Chris Lattner  writes:

Some time ago, there was a discussion about integrating LLVM and GCC
[1]. However, with plugin infrastructure in place, could LLVM be
plugged into GCC as an additional optimization plugin?


I'd love to see this, but I can't contribute to it directly.  I think
the plugin interfaces would need small extensions, but there are no
specific technical issues preventing it from happening.  LLVM has
certainly progressed a lot since that (really old) email went out :)


Is there a description somewhere of areas where llvm is thought to do
well compared to gcc, and maybe future plans for improvement?

In the (limited) tests I've done, gcc [4.4, but 4.2 yields similar
results] seems to do a lot better than llvm [2.5], but those were C++
code and I wonder if llvm is currently concentrating on C?


LLVM has many capabilities and advantages that GCC doesn't (and is  
also missing some features and capabilities that GCC has), but it is  
also common to misconfigure it so that it isn't optimizing like it  
should.  It is pretty off topic for this list though, please ask on  
the llvmdev mailing list for more information.  Please send  
information about how you built llvm and what your machine  
configuration is,


Thanks,

-Chris

Re: LLVM as a gcc plugin?

[Chris Lattner]

On Jun 4, 2009, at 3:20 AM, Steven Bosscher wrote:

On Thu, Jun 4, 2009 at 12:14 PM, Rafael Espindola > wrote:
I'd love to see this, but I can't contribute to it directly.  I  
think the
plugin interfaces would need small extensions, but there are no  
specific

technical issues preventing it from happening.  LLVM has certainly
progressed a lot since that (really old) email went out :)


I can help a bit.



Aren't LLVM and GCC doing just fine as
competing compilers?


I'm not sure what you mean, LLVM and GCC are two completely different  
things.  LLVM is an infrastructure for building compilers, GCC is an  
instance of a compiler.  Combining LLVM with GCC gives LLVM-GCC  
(another instance of a compiler), which adds new capabilities to GCC  
that many users find useful.  These include things such as cross- 
language LTO support (for C, c++, fortran, etc), JIT compilation,  
better performance in some scenarios, etc.



Excuse me if this is a stupid question, but eh -- why would you want
to make an LLVM plugin?


There are multiple answers to this question.  The most obvious one is  
that the current version of llvm-gcc is stuck on GCC 4.2, and 4.2  
lacks a number of improvements the fortran and ada front-ends and  
runtimes.  It would be straight-forward to forward port the patches to  
gcc mainline, but presumably implementing llvm-gcc in terms of plugins  
would result in something that has easier maintenance (this remains to  
be seen of course).


-Chris

GCC Summit 2010 topic (potentially).

[Toon Moene]

L.S.,

This year I'm unable to attend the GCC Summit (both due to time and 
money constraints).


In 2008, I pondered to talk about the effect of link time optimization 
on typical Fortran programs -


That is, until my attention got hijacked by the geo-politically more 
pressing question of Coarrays in Fortran.


However, the issue still stands.  So I'm thinking ahead of next year 
(assuming LTO will work by that time for most front-end languages):


What will LTO bring for Fortran ?

Here's a run-of-the-mill example from our code:

  SUBROUTINE VERINT (
 I   KLON   , KLAT   , KLEV   , KINT  , KHALO
 I , KLON1  , KLON2  , KLAT1  , KLAT2
 I , KP , KQ , KR
 R , PARG   , PRES
 R , PALFH  , PBETH
 R , PALFA  , PBETA  , PGAMA   )
...
  DO JY = KLAT1,KLAT2
  DO JX = KLON1,KLON2
 IDX  = KP(JX,JY)
 IDY  = KQ(JX,JY)
 ILEV = KR(JX,JY)
C
 PRES(JX,JY) = PGAMA(JX,JY,1)*(
C
 +   PBETA(JX,JY,1)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY-1,ILEV-1)
 +  + PALFA(JX,JY,2)*PARG(IDX  ,IDY-1,ILEV-1) )
 + + PBETA(JX,JY,2)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY  ,ILEV-1)
 +  + PALFA(JX,JY,2)*PARG(IDX  ,IDY  ,ILEV-1) ) )
C+
 +   + PGAMA(JX,JY,2)*(
C+
 +   PBETA(JX,JY,1)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY-1,ILEV  )
 +  + PALFA(JX,JY,2)*PARG(IDX  ,IDY-1,ILEV  ) )
 + + PBETA(JX,JY,2)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY  ,ILEV  )
 +  + PALFA(JX,JY,2)*PARG(IDX  ,IDY  ,ILEV  ) ) )
  ENDDO
  ENDDO
...
  RETURN
  END

There are several issues a link time optimization pass could determine:

1. Whether or not the arrays PALFA, PARG, ... are suitably aligned for
   vectorization (forgoing a run time check for that).

2. Wheter KLON{1,2}, KLAT{1,2} are actually invariant throughout an
   invocation of the execuatable (as they are in our case)
   (CSE of vectorization criteria).

However, with a little bit of extra effort (instrumentation outside the 
program), the following can be determined:


3. KLON{1,2}, KLAT{1,2} are in fact known constants, which only happen
   to be variables because the executable is built to accommodate
   arbitrary grid sizes.

Would it help to provide GCC with knowledge about KLON, KLAT (and 
thereby, KLON{1,2}, KLAT{1,2}) ?


Note that this question is less academic than it seems.  We often run on 
the same grid for years without changing an executable, so this 
optimization makes sense.


Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.4/changes.html

"plugin"-ifying the MELT branch.

[Basile STARYNKEVITCH]

Hello All,

To make MELT more interesting & more easy to use, I want to make it 
become a (big & meta *) plugin. I also need to document & illustrate it 
much more. I actually did start to work on the pluginification of MELT: 
I mean making MELT a real GCC plugin, not needing any core GCC patch 
anymore. The current snapshot (rev148175 of the MELT branch) already 
have some call to register_callback (with PLUGIN_GGC_MARK, so I don"t 
need to hack the GGC collector anymore.), even if MELT is not yet a real 
plugin.


I think that would be doable once gengtype is able to work in plugin 
mode, i.e. once the 
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00410.html patch is 
accepted into the trunk (or an equivalent way of doing it). AFAIK, once 
such a facility is provided, I could make MELT a plugin quite easily (by 
dropping some minor MELT functionalities, probably the compiler probe 
and the libtool support - ie using dlopen instead of the lt_dlopenext 
wrapper.



This brings some questions.

Can a branch be simply a plugin, or should I close (soon) the 
melt-branch and start a melt-plugin-branch on the SVN. If I do that, do 
I need some authorization? from whom?


Will there be a list of FSF-owned plugins (outside of the trivial ones 
for testing)? MELT could be an example of a non-trivial FSF plugin.


Perhaps we need on the SVN an additional class of sub-repositories. Not 
only branches and the trunk (and old releases) but also plugins




I won't be able to attend the summit this year.

Regards.

Note *: MELT is a meta plugin in the sense that it generate C code, 
compile it, and dynamically load it. However, the MELT generated plugins 
do not follow the plugin API; they have their own ones!


--
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 mines, sont seulement les miennes} ***

Re: LLVM as a gcc plugin?

[Duncan Sands]

Hi Rafael,


There was some talk about it on #gcc. A plugin should be able to see
all the GCC IL, so it should be able to convert it to LLVM. Keeping
the current llvm-gcc interface would require some hacks

*) The plugin will have to call exit to keep gcc's code generation from running.


this would work when doing unit-at-a-time, but not when doing
function-at-a-time.  Does gcc still do function-at-a-time?


Another source of problem will be the early transformations that gcc
does and that are normally disabled in llvm-gcc. The one that I
remember right now is c++ thunk generation.


Good point.

Ciao,

Duncan.

STRIP_NOPS and lower-precision/bit-field types

[Adam Nemet]

In this testcase:

  struct s
  {
unsigned long a:2;
unsigned long b:40;
unsigned long c:22;
  };
  
  f (struct s s)
  {
g (((unsigned long) (s.b-8)) + 8);
  }

fold breaks the code.  Specifically, after a few transformations we're asked
to fold this.  (I changed the big constant to be in symbolic form for better
understanding):

 D.40719;
   (uint64_t) (D.40719 + ((1<<40) - 8)) + 8

The cast is removed by STRIP_NOPS so with explicit precision and signedness on
the operations we have (the constants are of types of the corresponding
operation):

   (D.40719 +:u40 ((1<<40) - 8)) +:u64 8

split_trees/associate_trees code combines the two constant resulting in:

  (uint64_t) D.40719 +:64 1<<40

Ouch.

The problem is obviously that we remove a zero-extension that would ensure the
modulo-2^40 nature of the addition (remove the overflow).

I see two ways to fix this:

1. Change STRIP_NOPS not to remove the cast if it's changing the precision
(not just when it changes machine modes).  And then audit code quality where
we need to and are allowed to look through these casts.

The above case does not qualify because the first operation may not overflow
into the >40 bits whereas the second may.  For example with 2 as s.b the
substraction should yield 0xff,,fffa and the addition 0x100,,0002.
(Note that there in *no* default integer promotion on bitfield types wider
than int [1].)

2. Just fix this particular case of folding (split_trees/associate_trees) and
hope everything else works ;).

I am for 1, FWIW, but I know this issue has some history [2], so I'd like to
hear others' opinion before I started working on a patch.

Adam

[1] http://gcc.gnu.org/ml/gcc/2008-01/msg00215.html
[2] http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01478.html

Re: STRIP_NOPS and lower-precision/bit-field types

[Joseph S. Myers]

On Thu, 4 Jun 2009, Adam Nemet wrote:

> 1. Change STRIP_NOPS not to remove the cast if it's changing the precision
> (not just when it changes machine modes).  And then audit code quality where
> we need to and are allowed to look through these casts.

As I said in  and 
, I think such references 
to the mode are as a proxy for precision and machine modes are an 
inappropriate level of abstraction for the tree optimizers.  So I favour 
checking for precision here - but I also favour having a good look at 
anything using STRIP_NOPS etc. and considering whether it should use some 
better defined function for removing redundant conversions instead.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC Summit 2010 topic (potentially).

[Richard Guenther]

On Thu, Jun 4, 2009 at 7:33 PM, Toon Moene  wrote:
> L.S.,
>
> This year I'm unable to attend the GCC Summit (both due to time and money
> constraints).
>
> In 2008, I pondered to talk about the effect of link time optimization on
> typical Fortran programs -
>
> That is, until my attention got hijacked by the geo-politically more
> pressing question of Coarrays in Fortran.
>
> However, the issue still stands.  So I'm thinking ahead of next year
> (assuming LTO will work by that time for most front-end languages):
>
> What will LTO bring for Fortran ?
>
> Here's a run-of-the-mill example from our code:
>
>      SUBROUTINE VERINT (
>     I   KLON   , KLAT   , KLEV   , KINT  , KHALO
>     I , KLON1  , KLON2  , KLAT1  , KLAT2
>     I , KP     , KQ     , KR
>     R , PARG   , PRES
>     R , PALFH  , PBETH
>     R , PALFA  , PBETA  , PGAMA   )
> ...
>      DO JY = KLAT1,KLAT2
>      DO JX = KLON1,KLON2
>         IDX  = KP(JX,JY)
>         IDY  = KQ(JX,JY)
>         ILEV = KR(JX,JY)
> C
>         PRES(JX,JY) = PGAMA(JX,JY,1)*(
> C
>     +   PBETA(JX,JY,1)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY-1,ILEV-1)
>     +                  + PALFA(JX,JY,2)*PARG(IDX  ,IDY-1,ILEV-1) )
>     + + PBETA(JX,JY,2)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY  ,ILEV-1)
>     +                  + PALFA(JX,JY,2)*PARG(IDX  ,IDY  ,ILEV-1) ) )
> C    +
>     +               + PGAMA(JX,JY,2)*(
> C    +
>     +   PBETA(JX,JY,1)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY-1,ILEV  )
>     +                  + PALFA(JX,JY,2)*PARG(IDX  ,IDY-1,ILEV  ) )
>     + + PBETA(JX,JY,2)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY  ,ILEV  )
>     +                  + PALFA(JX,JY,2)*PARG(IDX  ,IDY  ,ILEV  ) ) )
>      ENDDO
>      ENDDO
> ...
>      RETURN
>      END
>
> There are several issues a link time optimization pass could determine:
>
> 1. Whether or not the arrays PALFA, PARG, ... are suitably aligned for
>   vectorization (forgoing a run time check for that).
>
> 2. Wheter KLON{1,2}, KLAT{1,2} are actually invariant throughout an
>   invocation of the execuatable (as they are in our case)
>   (CSE of vectorization criteria).
>
> However, with a little bit of extra effort (instrumentation outside the
> program), the following can be determined:
>
> 3. KLON{1,2}, KLAT{1,2} are in fact known constants, which only happen
>   to be variables because the executable is built to accommodate
>   arbitrary grid sizes.
>
> Would it help to provide GCC with knowledge about KLON, KLAT (and thereby,
> KLON{1,2}, KLAT{1,2}) ?
>
> Note that this question is less academic than it seems.  We often run on the
> same grid for years without changing an executable, so this optimization
> makes sense.

IPA-CP would be the candidate to propagate that information.  But if
they are both sufficiently large the performance improvement form knowning
them is likely minimal.

Richard.

> Kind regards,
>
> --
> Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> At home: http://moene.org/~toon/
> Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.4/changes.html
>

Re: LLVM as a gcc plugin?

[Ian Lance Taylor]

Duncan Sands  writes:

> this would work when doing unit-at-a-time, but not when doing
> function-at-a-time.  Does gcc still do function-at-a-time?

No.

Ian

Re: STRIP_NOPS and lower-precision/bit-field types

[Richard Guenther]

On Thu, Jun 4, 2009 at 10:49 PM, Joseph S. Myers
 wrote:
> On Thu, 4 Jun 2009, Adam Nemet wrote:
>
>> 1. Change STRIP_NOPS not to remove the cast if it's changing the precision
>> (not just when it changes machine modes).  And then audit code quality where
>> we need to and are allowed to look through these casts.
>
> As I said in  and
> , I think such references
> to the mode are as a proxy for precision and machine modes are an
> inappropriate level of abstraction for the tree optimizers.  So I favour
> checking for precision here - but I also favour having a good look at
> anything using STRIP_NOPS etc. and considering whether it should use some
> better defined function for removing redundant conversions instead.

FWIW I agree.  STRIP_NOPS should not change the precision - we came
to this conclusion multiple times but never got around to do the change.

Richard.

> --
> Joseph S. Myers
> jos...@codesourcery.com
>

Re: From regno to pseudo?

[Jeff Law]

Steven Bosscher wrote:

Hello,

Is there a way to get the REG for a given regno?  I am building a
register renumbering map that is just a pair of unsigned int
, but I can't figure out how to get the REG for
new_regno without remembering a pointer to it myself. Is there an
easier/better way?

Ciao!
Steven
  

regno_reg_rtx[pseudo]

If you're dealing with a hard register, try ORIGINAL_REGNO

Jeff

gcc-4.5-20090604 is now available

[gccadmin]

Snapshot gcc-4.5-20090604 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090604/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 148190

You'll find:

gcc-4.5-20090604.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20090604.tar.bz2 C front end and core compiler

gcc-ada-4.5-20090604.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20090604.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20090604.tar.bz2  C++ front end and runtime

gcc-java-4.5-20090604.tar.bz2 Java front end and runtime

gcc-objc-4.5-20090604.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20090604.tar.bz2The GCC testsuite

Diffs from 4.5-20090528 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
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.

Re: [RFC] enabling -fshow-column by default

[Jonathan Wakely]

2009/5/20 Aldy Hernandez:
>>
>> My only worry is that the testsuite may confuse column and line
>> numbers and pass/fail tests because of it.
>
> Janis has a patch for the testsuite to handle all this.

I'm seeing exactly this in the libstdc++ testsuite with some new tests
I've written - is a fix on the way soon?

I have something like:

/*33*/  foo p1;// { dg-error "no match" }
/*34*/  foo p2;   // { dg-error "no match" }

and the error for p2 has line:column as 34:33: which matches the first
dg-error, so I get a FAIL on line 34

Jonathan

Re: Using MPC Library with GCC

[Allan McRae]

Kaveh R. GHAZI wrote:

On Wed, 13 May 2009, Mark Mitchell wrote:

  

Kaveh R. GHAZI wrote:



1.  Consider MPC as an optional library now, install all the code and make
it hard-required only when all the complex math functions are made
available in a future released version of the library or sometime in
stage3, whichever is first.
  

I think this is the best option.

Please make sure to open a P1 PR for 4.5.0 indicating that we should
throw the hard-requirement switch.



The last patch to enable use of MPC in GCC was reviewed today and
installed.  I'm sure other updates will come, but the base functionality
is now there.

I've opened PR 40302 as you requested (and assigned myself).
  


I have noticed that mpc is not automatically detected even when 
installed in the standard library path (with gcc-4.5-20090604). This 
means that building with mpc always requires using the 
--with-mpc-lib=/usr/lib flag.

This is fixed by adjusting configure{.ac} to have:
mpclibs="-lmpc"

Allan