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
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
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
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
> > 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
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
> 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
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
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
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
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
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
"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
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
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
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
> 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
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
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
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
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
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:
> > >
>
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
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
> 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
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
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
> 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
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
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
>
> > 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
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
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
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
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
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
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,
"
>
> 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
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
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
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
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
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
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
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
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
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_
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
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
49 matches
Mail list logo