Re: More __comp_ctor () woes

2006-10-25 Thread Brendon Costa
I have been looking at the source in class.c: clone_function_decl() clone_constructors_and_destructors() pt.c: check_explicit_specialization() In pt.c: check_explicit_specialization() it specifically requests that the clone function of a specialised constructor NOT add the new clone t

Re: LOOP_HEADER tree code?

2006-10-25 Thread Richard Sandiford
Zdenek Dvorak <[EMAIL PROTECTED]> writes: > for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering > introducing a tree LOOP_HEADER with single argument N (number of > iterations of the loop), that would be present in IL at the beginning of > header of each loop. I have following mo

Re: Abt -fpic, -fPIC Option

2006-10-25 Thread Richard Sandiford
Ian Lance Taylor <[EMAIL PROTECTED]> writes: > "Rohit Arul Raj" <[EMAIL PROTECTED]> writes: > >> I have built a cross-compiler for m68k-elf with GCC 4.1.1. >> I need to know the difference in implementations of -fpic and -fPIC >> for this particular target. > > -fpic uses a 16-bit offset when acces

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread Andrew Haley
Roger Sayle writes: > > Hi David, > > On Sun, 22 Oct 2006, David Daney wrote: > > 2006-10-22 Richard Sandiford <[EMAIL PROTECTED]> > > David Daney <[EMAIL PROTECTED]> > > > > PR middle-end/29519 > > * rtlanal.c (nonzero_address_p): Remove check for values

Re: LOOP_HEADER tree code?

2006-10-25 Thread Sebastian Pop
> > quite a lot at the moment). To keep the information valid, we need > > to prevent optimizations from destroying it (e.g., if the number > > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want > > DCE to remove it); this is easy to achieve if n_1 would be the > > argume

Re: LOOP_HEADER tree code?

2006-10-25 Thread Zdenek Dvorak
Hello, > >> > quite a lot at the moment). To keep the information valid, we need > >> > to prevent optimizations from destroying it (e.g., if the number > >> > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want > >> > DCE to remove it); this is easy to achieve if n_1 would

Re: LOOP_HEADER tree code?

2006-10-25 Thread Sebastian Pop
> You are proposing to complete the ssa representation such that > foreach_ssa_uses also iterates over the niter information (a bit like vrp > modifies the ssa chains with its extra assert information). Wouldn't it > be possible to not insert this niter information in the representation of > the

Re: LOOP_HEADER tree code?

2006-10-25 Thread Zdenek Dvorak
Hello, > >> You are proposing to complete the ssa representation such that > >> foreach_ssa_uses also iterates over the niter information (a bit like vrp > >> modifies the ssa chains with its extra assert information). Wouldn't it > >> be possible to not insert this niter information in the repre

fdump-tree explanation

2006-10-25 Thread Dino Puller
Hi all, i want to make a statistic(i haven't found one) over linux source code, and i want to know how many times expressions are simplified by gcc. I've found that "-O -ftree-dominator-opts -fdump-tree-optimized" writes a file optimized, now if i can compare it with a not optimized one i win, "u

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread David Daney
Andrew Haley wrote: Roger Sayle writes: > > Hi David, > > On Sun, 22 Oct 2006, David Daney wrote: > > 2006-10-22 Richard Sandiford <[EMAIL PROTECTED]> > > David Daney <[EMAIL PROTECTED]> > > > > PR middle-end/29519 > > * rtlanal.c (nonzero_address_p): R

Maintainer(s) for loop optimizer(s)

2006-10-25 Thread Zdenek Dvorak
Hello, at the moment, RTL level loop optimizers and most of the tree-level loop optimizers do not have assigned specific maintainers. I think this clearly starts to become a significant problem -- many of the loop-optimizer related patches in 4.2 timeframe remained unreviewed (the vectorizer impr

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread Roger Sayle
Hi Andrew, On Wed, 25 Oct 2006, Andrew Haley wrote: > I must admit to being a little perplexed by this. > > We have an unsafe optimization that causes bad code to be generated on > at least one platform. However, we want to continue to perform this > unsafe optimization on our release branch unt

Re: fdump-tree explanation

2006-10-25 Thread Ian Lance Taylor
"Dino Puller" <[EMAIL PROTECTED]> writes: > i want to make a statistic(i haven't found one) over linux source > code, and i want to know how many times expressions are simplified by > gcc. I don't think any of us know what you mean by "how many times expressions are simplified." Can you be mor

Re: LOOP_HEADER tree code?

2006-10-25 Thread Devang Patel
Hello, for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering introducing a tree LOOP_HEADER with single argument N (number of iterations of the loop), that would be present in IL at the beginning of header of each loop. I have following motivations: 1) One of the goals of the pr

Re: LOOP_HEADER tree code?

2006-10-25 Thread Jeffrey Law
On Wed, 2006-10-25 at 10:31 -0700, Devang Patel wrote: > > Hello, > > > > for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering > > introducing a tree LOOP_HEADER with single argument N (number of > > iterations of the loop), that would be present in IL at the beginning of > > heade

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread Richard Sandiford
Roger Sayle <[EMAIL PROTECTED]> writes: > Once explained, I'd expect most maintainers would make precisely the > same call? I suppose the counter-argument is that we shouldn't ship 4.2 in its current state. We should either back out the patch that made REG_POINTER more prominent or go with the fi

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread Eric Botcazou
> Lots of people seem to test release branches -- probably more than mainline > -- and I would hope that using the fix from this PR is by far the strongest > contender. Definitely. People report bugs against released versions and expect fixes for these versions, not for versions that will be re

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread Richard Sandiford
Eric Botcazou <[EMAIL PROTECTED]> writes: >> Also, having patches on mainline and not a release branch can cause >> quite a bit of confusion. Witness what happend with PR 28243, where I >> fixed something on mainline, but it was not directly approved for a >> release branch. Then Eric B. worked a

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread David Daney
Eric Botcazou wrote: Lots of people seem to test release branches -- probably more than mainline -- and I would hope that using the fix from this PR is by far the strongest contender. Definitely. People report bugs against released versions and expect fixes for these versions, not for versi

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread David Daney
David Daney wrote: Eric Botcazou wrote: Lots of people seem to test release branches -- probably more than mainline -- and I would hope that using the fix from this PR is by far the strongest contender. Definitely. People report bugs against released versions and expect fixes for these v

Re: LOOP_HEADER tree code?

2006-10-25 Thread Zdenek Dvorak
Hello, > >for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering > >introducing a tree LOOP_HEADER with single argument N (number of > >iterations of the loop), that would be present in IL at the beginning of > >header of each loop. I have following motivations: > > > >1) One of th

Re: LOOP_HEADER tree code?

2006-10-25 Thread Zdenek Dvorak
Hello, > > > for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering > > > introducing a tree LOOP_HEADER with single argument N (number of > > > iterations of the loop), that would be present in IL at the beginning of > > > header of each loop. I have following motivations: > > > >

A public discussion group for IA32 psABI

2006-10-25 Thread H. J. Lu
On Tue, Oct 10, 2006 at 11:21:41AM -0500, Menezes, Evandro wrote: > > H.J., do you have the i386 psABI in source form somewhere I could get > > it, to make the corresponding changes? > > Actually, it's about an extension to the i386 psABI and it's an idea still in > its infancy: http://sourcewar

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread Roger Sayle
On Wed, 25 Oct 2006, Richard Sandiford wrote: > Roger Sayle <[EMAIL PROTECTED]> writes: > > Once explained, I'd expect most maintainers would make precisely the > > same call? > > I suppose the counter-argument is that we shouldn't ship 4.2 in its > current state. We should either back out the pa

Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Devang Patel
> However, various optimizer needs to know about this special tree node. not really (not any more than they know about other tree codes that are not interesting for them). If we take an example of Jump Threading pass then it needs to know about this tree node and update it properly. So, the p

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread Roger Sayle
On Wed, 25 Oct 2006, David Daney wrote: > The patch is fully tested and ready to go for the 4.2 branch. The last thing I want is for this fix to get delayed whilst we argue over patch testing/approval policy. This fix addresses the known wrong-code issue, and at worst may replace it with missed

Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Steven Bosscher
On 10/25/06, Devang Patel <[EMAIL PROTECTED]> wrote: > > However, various optimizer needs to know about this special tree node. > > not really (not any more than they know about other tree codes that are > not interesting for them). If we take an example of Jump Threading pass then it needs to

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread Eric Botcazou
> Finally before I finish the retrospective part of this e-mail, I'll > point out this isn't a sudden recent unilateral policy decision, but > purely a crystallization of the prescribed GCC work-flow outlined in > contributing.html that has been refined over many years. I disagree. I've been work

Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Zdenek Dvorak
Hello, > >So, the passes that maniuplate loop structure need to know about > >LOOP_HEADER and others do not need to worry about LOOP_HEADER. > > More acurately, the passes that manipulate the cfg. Right now most of > these passes don't even know they modify the loop structure. > > >Now, focusing

Re: Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Devang Patel
On 10/25/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: Hello, > >So, the passes that maniuplate loop structure need to know about > >LOOP_HEADER and others do not need to worry about LOOP_HEADER. > > More acurately, the passes that manipulate the cfg. Right now most of > these passes don't even k

Re: Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Andrew Pinski
> > > and seeing the reaction of people, > > I probably won't use it. The main reason for considering to use > > the tree node for me was the possibility to make the number of iterations > > of the loop as its operand, so that I would not need to worry about > > keeping it alive through dce, copy

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread Mark Mitchell
Eric Botcazou wrote: Finally before I finish the retrospective part of this e-mail, I'll point out this isn't a sudden recent unilateral policy decision, but purely a crystallization of the prescribed GCC work-flow outlined in contributing.html that has been refined over many years. I've review

Re: Re: Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Devang Patel
On 10/25/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > > and seeing the reaction of people, > > I probably won't use it. The main reason for considering to use > > the tree node for me was the possibility to make the number of iterations > > of the loop as its operand, so that I would not nee

Re: Re: Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Steven Bosscher
On 10/25/06, Devang Patel <[EMAIL PROTECTED]> wrote: > > One way to achieve this is to mark n_1 (in your example) as > > "do not dead strip because I know it is used" , kind of attribute((used)). > > This is what as I understand LOOP_HEADER is used for. Big difference. New tree vs TREE_USED or D

Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Steven Bosscher
On 10/25/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: it definitely is not the only way, and seeing the reaction of people, I probably won't use it. The main reason for considering to use the tree node for me was the possibility to make the number of iterations of the loop as its operand, so tha

Re: Re: Re: Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Devang Patel
On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote: You could use TREE_USED, but your suggestion implies that dead code should be retained in the program, May be I misunderstood, but it is not dead code. Here is what Zdenek said, " ... To keep the information valid, we need > to preve

Re: Re: Re: Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Steven Bosscher
On 10/26/06, Devang Patel <[EMAIL PROTECTED]> wrote: On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote: > You could use TREE_USED, but your suggestion implies that dead code > should be retained in the program, May be I misunderstood, but it is not dead code. Here is what Zdenek said, "

Re: Re: Re: Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Andrew Pinski
> > On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote: > > > You could use TREE_USED, but your suggestion implies that dead code > > should be retained in the program, > > May be I misunderstood, but it is not dead code. Here is what Zdenek said, The question now has come to the following

Re: Re: Re: Re: Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Devang Patel
On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote: So you would mark n_1 with TREE_USED, and never let it be removed? What would happen if e.g. the entire loop turns out to be dead code? Or if the loop is rewritten (e.g. vectorized) in a way that changes the number of iterations of the loop

Large memory requirements for 4.2 and 4.3

2006-10-25 Thread Bradley Lucier
For many years, the default gcc compile options for C code generated by Gambit, the Scheme->C compiler, were very simple (-O1 -fschedule- insns2 -fno-math-errno -fno-trapping-math) and I didn't have problems with gcc's space requirements to compile those files. (I often ran into complexity

Re: Re: Re: Re: Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Zdenek Dvorak
Hello, > On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote: > > > >So you would mark n_1 with TREE_USED, and never let it be removed? > >What would happen if e.g. the entire loop turns out to be dead code? > >Or if the loop is rewritten (e.g. vectorized) in a way that changes > >the number of

Re: [PATCH] Fix PR29519 Bad code on MIPS with -fnon-call-exceptions

2006-10-25 Thread David Daney
Roger Sayle wrote: On Wed, 25 Oct 2006, David Daney wrote: The patch is fully tested and ready to go for the 4.2 branch. The last thing I want is for this fix to get delayed whilst we argue over patch testing/approval policy. This fix addresses the known wrong-code issue, and at worst may r

Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Jeffrey Law
On Wed, 2006-10-25 at 13:01 -0700, Devang Patel wrote: > > > However, various optimizer needs to know about this special tree node. > > > > not really (not any more than they know about other tree codes that are > > not interesting for them). > > If we take an example of Jump Threading pass then i

Re: Re: Re: Re: Re: Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Devang Patel
On 10/25/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: Many optimizers would need to be taught to know about TREE_USED (or any other bit you would use for that). We do not have this type of restriction for any other ssa names, so this would be brand new functionality (on the other hand, most opt

Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Zdenek Dvorak
Hello, > On Wed, 2006-10-25 at 13:01 -0700, Devang Patel wrote: > > > > However, various optimizer needs to know about this special tree node. > > > > > > not really (not any more than they know about other tree codes that are > > > not interesting for them). > > > > If we take an example of Jump

Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Jeffrey Law
On Thu, 2006-10-26 at 00:45 +0200, Zdenek Dvorak wrote: > actually, that will be trivial once jump threading updates loop properly > (I have a patch for that). I'd like to see that. I recall poking at having threading update things like loop exit points and gave up. The problem is you could thre

Re: More __comp_ctor () woes

2006-10-25 Thread Brendon Costa
Hi all, Well after trying numerous different approaches to find the FUNCTION_DECL node for a constructor like MyClass::MyClass(int) from a FUNCTION_DECL node for one of the constructors: MyClass::__comp_ctor (int) or similar, I have found that there is a VERY simple way to do this using DECL_

Re: Re: LOOP_HEADER tree code?

2006-10-25 Thread Zdenek Dvorak
Hello, > On Thu, 2006-10-26 at 00:45 +0200, Zdenek Dvorak wrote: > > > actually, that will be trivial once jump threading updates loop properly > > (I have a patch for that). > I'd like to see that. > > I recall poking at having threading update things like loop exit > points and gave up. The p

au sujet de gcc

2006-10-25 Thread Centre d'appels JL
Bonjour Est ce que votre organisation (gcc) utilise ou prévoit utiliser le télémarketing à court ou moyen terme ? Nous pouvons vous aider. Visiter le http://www.telemarketing.ca.cx/ Agence de télémarketing JL, est une entreprise qui se spécialise depuis plus de 20 ans dans l'exécution de manda