> Note that TREE_INVARIANT is not going to be useful in an IPA world
> anyway for these users, if it really means that different calls to the
> function could produce different results.
We could test TREE_CONSTANT instead and this would be enough to restore Ada
bootstrap. But of course the under
On 7/4/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Also, we need to update the GIMPLE grammar so that ARRAY_REF and
> ARRAY_RANGE_REF take the appropriate values:
A minor comment is that operand 2 of COMPONENT_REF needs the same handling.
Can you please, again, explain why we even have th
On Jul 4, 2007, David Edelsohn <[EMAIL PROTECTED]> wrote:
>> Alexandre Oliva writes:
Alexandre> It's as mechanical as the change you proposed, except that yours
Alexandre> potentially loses information that would enable someone to recover
Alexandre> !BEFORE_RELOAD_P() out of the expanded ver
> Alexandre> It's as mechanical as the change you proposed, except that yours
> Alexandre> potentially loses information that would enable someone to recover
> Alexandre> !BEFORE_RELOAD_P() out of the expanded version of no_new_pseudos.
>
> Except that no_new_pseudos was not used consistent
> Also, we need to update the GIMPLE grammar so that ARRAY_REF and
> ARRAY_RANGE_REF take the appropriate values:
A minor comment is that operand 2 of COMPONENT_REF needs the same handling.
Alexandre Oliva wrote:
> On Jul 4, 2007, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
>
enum { BEFORE_RELOAD = -1, DURING_RELOAD = 0, AFTER_RELOAD = 1 }
reload_status;
>
>
#define BEFORE_RELOAD_P() (reload_status < DURING_RELOAD)
#define DURING_RELOAD_P() (r
On 7/4/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
On 7/4/07 6:24 PM, Eric Botcazou wrote:
>> The problem is that in GIMPLE we only allow TREE_INVARIANT as a gimple
>> value for ADDR_EXPRs. We still require a TREE_CONSTANT as an array
>> index. So, ARRAY[TREE_INVARIANT] is not valid GIMPLE.
>
> Alexandre Oliva writes:
Alexandre> It's as mechanical as the change you proposed, except that yours
Alexandre> potentially loses information that would enable someone to recover
Alexandre> !BEFORE_RELOAD_P() out of the expanded version of no_new_pseudos.
Except that no_new_pseudos
On Jul 4, 2007, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>>> enum { BEFORE_RELOAD = -1, DURING_RELOAD = 0, AFTER_RELOAD = 1 }
>>> reload_status;
>>> #define BEFORE_RELOAD_P() (reload_status < DURING_RELOAD)
>>> #define DURING_RELOAD_P() (reload_status == DURING_RELOAD)
>>> #define AFTER_RELOAD
On 7/4/07 6:24 PM, Eric Botcazou wrote:
>> The problem is that in GIMPLE we only allow TREE_INVARIANT as a gimple
>> value for ADDR_EXPRs. We still require a TREE_CONSTANT as an array
>> index. So, ARRAY[TREE_INVARIANT] is not valid GIMPLE.
>
> OK, my understanding is that is_gimple_min_invaria
Dave Korn wrote:
> On 04 July 2007 19:25, Alexandre Oliva wrote:
>
>
>> Actually, how about replacing the three variables with a single
>> tri-state variable that indicates the progress into reload:
>>
>> enum { BEFORE_RELOAD = -1, DURING_RELOAD = 0, AFTER_RELOAD = 1 }
>> reload_status;
>>
>> #
Hi,
On Fri, 29 Jun 2007, Andrew Pinski wrote:
> > I'm not sure that's related, what's happening in my example is that the
> > call to fold_plusminus_mult_expr() defeats the optimization attempted in
> > pointer_int_sum(). If I use the patch below to restrict the condition, my
> > problem is fixed
On 7/4/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> Ok. So either we want to disallow invariant addresses as gimple value
> altogether or
> do more elaborate checks, to rule out such bogus cases. At least the
> transformation
> PRE is doing doesn't make sense -- and I know other optimization
> The problem is that in GIMPLE we only allow TREE_INVARIANT as a gimple
> value for ADDR_EXPRs. We still require a TREE_CONSTANT as an array
> index. So, ARRAY[TREE_INVARIANT] is not valid GIMPLE.
OK, my understanding is that is_gimple_min_invariant as currently written is
correct as "non-rec
> It is a formal predicate of the GIMPLE grammar. But there is an
> inconsistency now. I don't think we want to allow min-invariant as
> ARRAY_REF indexes because this would allow things like
>
> &a[&b[3]]
>
> which is too gross for words. So, the grammar should be updated to
> include inv
GCC 4.2.1 RC1 is now available from:
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2.1-RC-20070703
It may be too bold to call this a "release candidate" in that I expect
more changes to 4.2.1 before we release. However, it is certainly still
a good idea to test these packages in your environment.
As al
On 04 July 2007 19:25, Alexandre Oliva wrote:
> Actually, how about replacing the three variables with a single
> tri-state variable that indicates the progress into reload:
>
> enum { BEFORE_RELOAD = -1, DURING_RELOAD = 0, AFTER_RELOAD = 1 }
> reload_status;
>
> #define BEFORE_RELOAD_P() (relo
On Jul 4, 2007, Richard Sandiford <[EMAIL PROTECTED]> wrote:
> What about the earlier idea of keeping no_new_pseudos and making it
> equivalent to "reload_in_progress || reload_completed", either by being
> a macro or by being a variable?
Actually, how about replacing the three variables with a
Richard Sandiford wrote:
> David Edelsohn <[EMAIL PROTECTED]> writes:
>
>> I think the proposal is to get the semantics right first and then
>> fix the syntax, not just leave the long, cumbersome flag.
>>
>> Creating a macro or alias could lead to confusion and creates an
>> opportunit
David Edelsohn <[EMAIL PROTECTED]> writes:
> I think the proposal is to get the semantics right first and then
> fix the syntax, not just leave the long, cumbersome flag.
>
> Creating a macro or alias could lead to confusion and creates an
> opportunity for divergence.
I don't understa
> Richard Sandiford writes:
Richard> So which of (1) and (2) from my message do think is best? Replace
backend
Richard> uses with "reload_completed" when doing so is safe, or consistently
replace
Richard> it with "reload_in_progress || reload_completed" throughout the
backends?
Richard,
> #define BEFORE_RELOAD_P (!reload_in_progress && !reload_completed)
I'd personally vote for something like this.
--
Eric Botcazou
On 04 July 2007 18:03, Ian Lance Taylor wrote:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>
>> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>>> Richard Sandiford <[EMAIL PROTECTED]> writes:
What about the earlier idea of keeping no_new_pseudos and making it
equivalent to "reload_in
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > Richard Sandiford <[EMAIL PROTECTED]> writes:
> >> What about the earlier idea of keeping no_new_pseudos and making it
> >> equivalent to "reload_in_progress || reload_completed", either by being
> >>
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>> What about the earlier idea of keeping no_new_pseudos and making it
>> equivalent to "reload_in_progress || reload_completed", either by being
>> a macro or by being a variable?
>
> I would prefer to get
On 04 July 2007 17:41, Ian Lance Taylor wrote:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>
>> What about the earlier idea of keeping no_new_pseudos and making it
>> equivalent to "reload_in_progress || reload_completed", either by being
>> a macro or by being a variable?
>
> I would prefer
Richard Sandiford <[EMAIL PROTECTED]> writes:
> What about the earlier idea of keeping no_new_pseudos and making it
> equivalent to "reload_in_progress || reload_completed", either by being
> a macro or by being a variable?
I would prefer to get rid of it and clean up afterward.
Ian
Hello Ian,
Tuesday, July 3, 2007, 6:23:02 PM, you wrote:
> Adding a new field to mem_attrs could be a problem. You'll have to
> measure to see how much the memory usage changes.
We have tested that previously with alias-export patch, which uses the
same mechanism for saving original exprs for r
On 7/4/07 5:29 AM, Eric Botcazou wrote:
> /* Make sure result is not a complex expression consiting
> of operators of operators (IE (a + b) + (a + c))
> Otherwise, we will end up with unbounded expressions if
> fold does anything at all. */
> if (result)
> {
> if (is_
> Sure, but CONST isn't specified.
OK, but if it's a formal predicate you cannot do what you want because of the
rest of the grammar that is "implemented" by the GIMPLE verifier.
For example &A[C + 1] and &A[C], where A is static and C is a constant
identifier, have the same degree of constness
On 7/4/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> Ok. So either we want to disallow invariant addresses as gimple value
> altogether or
> do more elaborate checks, to rule out such bogus cases. At least the
> transformation
> PRE is doing doesn't make sense -- and I know other optimization
> Ok. So either we want to disallow invariant addresses as gimple value
> altogether or
> do more elaborate checks, to rule out such bogus cases. At least the
> transformation
> PRE is doing doesn't make sense -- and I know other optimization passes
> that treat is_gimple_min_invariant() values a
On 7/4/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> This is invalid gimple.
Right, but nevertheless is_gimple_val.
> Can you figure our why we don't gimplify this to
>
> tmp_1 = MAX_EXPR ;
> tmp_2 = ()tmp_1;
> tmp_3 = tmp_2 + 1;
> &p_name_buffer[tmp3]
Because there is no code to do it. If I
> This is invalid gimple.
Right, but nevertheless is_gimple_val.
> Can you figure our why we don't gimplify this to
>
> tmp_1 = MAX_EXPR ;
> tmp_2 = ()tmp_1;
> tmp_3 = tmp_2 + 1;
> &p_name_buffer[tmp3]
Because there is no code to do it. If I add it:
Index: tree-ssa-pre.c
=
On 7/4/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
Ada bootstrap has been broken by the SCC value numbering patch too (this is PR
tree-optimization/32589) but this might be due to a latent problem.
In the FRE dump:
RHS &p__name_buffer[1]{lb: 1 sz: 1} + n_32 simplified to
&p__name_buffer[() MAX
On Tue, Jul 03, 2007 at 05:14:21PM -0400, Kenneth Zadeck wrote:
> David Edelsohn points out that some of the expanders could have all of
> this code removed since expanders only run before reload. I do not know
> how to figure this out.
The movM and addM3 expanders are used by reload. The prolo
Ada bootstrap has been broken by the SCC value numbering patch too (this is PR
tree-optimization/32589) but this might be due to a latent problem.
In the FRE dump:
RHS &p__name_buffer[1]{lb: 1 sz: 1} + n_32 simplified to
&p__name_buffer[() MAX_EXPR + 1]{lb: 1 sz:
1} has constants 0
and the l
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> Alexandre Oliva wrote:
>> On Jul 2, 2007, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
>>
>>
>>> On Mon, 2007-07-02 at 12:10 -0400, Kenneth Zadeck wrote:
>>>
I do not remember if it was stevenb or bonzini that observed that
because of c
Brian Dessent wrote:
Angelo Graziosi wrote:
./configure --prefix=${prefix_dir} \
According to the documentation you should not do this (build in the same
dir as the source.)
This is just less tested, not unsupported. If people report bugs
related to "./configure" builds, we'll
On Wed, 4 Jul 2007, Brian Dessent wrote:
> Angelo Graziosi wrote:
>
> > ./configure --prefix=${prefix_dir} \
>
> According to the documentation you should not do this (build in the same
> dir as the source.)
Obviously I forgot to say:
cd ${build_dir}
${gcc_dir}/configur
Angelo Graziosi wrote:
> ./configure --prefix=${prefix_dir} \
According to the documentation you should not do this (build in the same
dir as the source.)
> A few months ago this did not happen (same building procedure).
The warning is correct because libdecnumber is only supported
Angelo Graziosi
Wednesday, 4 July 2007 7:19 p.m.
>
>
>
> I have build GFortran under Cygwin configuring with:
>
> ./configure --prefix=${prefix_dir} \
> --enable-languages=c,fortran \
>--enable-bootstrap \
>-
I have build GFortran under Cygwin configuring with:
./configure --prefix=${prefix_dir} \
--enable-languages=c,fortran \
--enable-bootstrap \
--enable-libgomp \
--enable-threads \
43 matches
Mail list logo
