On 06/15/12 06:40, Eric Botcazou wrote:
Whoops, I forgot to commit that last patch. Check now.
The warning is there on the 4.7 branch now.
Arghhh, that's the second time. I wonder why the warning doesn't show
up on my bootstraps.
Anyway, committed the attached patch to branch.
B
> Whoops, I forgot to commit that last patch. Check now.
The warning is there on the 4.7 branch now.
--
Eric Botcazou
On 06/01/12 10:11, Aldy Hernandez wrote:
On 06/01/12 01:22, Tobias Burnus wrote:
gcc/gimple.h: In function 'block_in_transaction':
gcc/gimple.h:1596:20: warning: overflow in implicit constant conversion
[-Woverflow]
return bb->flags & BB_IN_TRANSACTION;
^
Is this still the case with the code
On 06/01/12 01:22, Tobias Burnus wrote:
gcc/gimple.h: In function 'block_in_transaction':
gcc/gimple.h:1596:20: warning: overflow in implicit constant conversion
[-Woverflow]
return bb->flags & BB_IN_TRANSACTION;
^
Is this still the case with the code currently in mainline:
return flag_tm &
Aldy Hernandez wrote:
PR tree-optimization/52558
* cfg.c (alloc_aux_for_edge): Fix comment.
(alloc_aux_for_edge): Remove static.
* basic-block.h (alloc_aux_for_edge): Protoize.
* tree-ssa-loop-im.c (execute_sm_if_changed): New.
(execute_sm_if_change
On 05/29/12 06:13, Richard Guenther wrote:
On Mon, 21 May 2012, Aldy Hernandez wrote:
On 05/16/12 07:53, Richard Guenther wrote:
On Mon, 7 May 2012, Aldy Hernandez wrote:
(flag_tm&& loop_preheader_edge (loop)->src->flags& BB_IN_TRANSACTION)
can you encapsulate this into a predicate? Li
On Mon, 21 May 2012, Aldy Hernandez wrote:
> On 05/16/12 07:53, Richard Guenther wrote:
> > On Mon, 7 May 2012, Aldy Hernandez wrote:
>
> [Sorry for the delay; I was on vacation.]
>
> I am forgoing the load avoidance code altogether to simplify things. Thanks.
>
> > + /* Emit the load code int
On 05/16/12 07:53, Richard Guenther wrote:
On Mon, 7 May 2012, Aldy Hernandez wrote:
[Sorry for the delay; I was on vacation.]
I am forgoing the load avoidance code altogether to simplify things.
Thanks.
+ /* Emit the load code into the latch, so that we are sure it will
+ be processe
On Mon, 7 May 2012, Aldy Hernandez wrote:
> Hi. Sorry for the delay. There were various tricky hiccups along the way to
> bootstrappability and regression cleanliness...
>
> On 04/26/12 04:51, Richard Guenther wrote:
> > On Wed, 25 Apr 2012, Aldy Hernandez wrote:
> >
> > > On 04/25/12 06:45, Ri
PING.
Hi. Sorry for the delay. There were various tricky hiccups along the way
to bootstrappability and regression cleanliness...
On 04/26/12 04:51, Richard Guenther wrote:
On Wed, 25 Apr 2012, Aldy Hernandez wrote:
On 04/25/12 06:45, Richard Guenther wrote:
On Tue, Apr 24, 2012 at 7:43 PM,
On 05/07/12 19:11, Andrew MacLeod wrote:
On 05/07/2012 07:04 PM, Aldy Hernandez wrote:
Andrew suggested the correct fix was to add a new pass that was able
to do some ?? flow sensitive data flow analysis ?? that could discover
these unreachable paths and insert the 0 phis at the start of the
b
On 05/07/2012 07:04 PM, Aldy Hernandez wrote:
Andrew suggested the correct fix was to add a new pass that was able
to do some ?? flow sensitive data flow analysis ?? that could discover
these unreachable paths and insert the 0 phis at the start of the
blocks automatically. But that seemed l
Hi. Sorry for the delay. There were various tricky hiccups along the
way to bootstrappability and regression cleanliness...
On 04/26/12 04:51, Richard Guenther wrote:
On Wed, 25 Apr 2012, Aldy Hernandez wrote:
On 04/25/12 06:45, Richard Guenther wrote:
On Tue, Apr 24, 2012 at 7:43 PM, Aldy
On Wed, 25 Apr 2012, Aldy Hernandez wrote:
> On 04/25/12 06:45, Richard Guenther wrote:
> > On Tue, Apr 24, 2012 at 7:43 PM, Aldy Hernandez wrote:
> > > On 04/13/12 03:46, Richard Guenther wrote:
> > > >
> > > > On Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandez
> > > > wrote:
>
> > + /* ?? Perha
On 04/25/12 06:45, Richard Guenther wrote:
On Tue, Apr 24, 2012 at 7:43 PM, Aldy Hernandez wrote:
On 04/13/12 03:46, Richard Guenther wrote:
On Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandezwrote:
+ /* ?? Perhaps we should cache this somewhere in the BB, or are
+ multiple levels of
On Tue, Apr 24, 2012 at 7:43 PM, Aldy Hernandez wrote:
> On 04/13/12 03:46, Richard Guenther wrote:
>>
>> On Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandez wrote:
>
>
> Richard. Thanks so much for reviewing and providing an alternative
> approach, which AFAICT provides superior results.
>
>
>> A
On 04/13/12 03:46, Richard Guenther wrote:
On Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandez wrote:
Richard. Thanks so much for reviewing and providing an alternative
approach, which AFAICT provides superior results.
A similar effect could be obtained by keeping a flag whether we entered t
On 04/13/12 18:22, Boehm, Hans wrote:
-Original Message-
From: Aldy Hernandez [mailto:al...@redhat.com]
Sent: Thursday, April 12, 2012 3:12 PM
To: Richard Guenther
Cc: Andrew MacLeod; Boehm, Hans; gcc-patches; Torvald Riegel
Subject: [PR tree-optimization/52558]: RFC: questions on
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Can we _remove_ a store we percieve as redundant (with a single-threaded
> view) with the memory model?
Generally yes, so long as synchronization operations either conservatively
treated as completely opaque, or are treated correctly i
> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Thursday, April 12, 2012 3:12 PM
> To: Richard Guenther
> Cc: Andrew MacLeod; Boehm, Hans; gcc-patches; Torvald Riegel
> Subject: [PR tree-optimization/52558]: RFC: questions on store data
&
On Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandez wrote:
> Here we have a testcase that affects both the C++ memory model and
> transactional memory.
>
> [Hans, this is caused by the same problem that is causing the speculative
> register promotion issue you and Torvald pointed me at].
>
> In the f
Here we have a testcase that affects both the C++ memory model and
transactional memory.
[Hans, this is caused by the same problem that is causing the
speculative register promotion issue you and Torvald pointed me at].
In the following testcase (adapted from the PR), the loop invariant
moti
22 matches
Mail list logo
