Whoops, I forgot to commit that last patch. Check now.
The warning is there on the 4.7 branch now.
--
Eric Botcazou
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.
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.
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
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 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? Like
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 into the
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, Richard
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
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
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/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
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 Hernandezal...@redhat.com wrote:
On 04/13/12 03:46, Richard Guenther wrote:
On Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandezal...@redhat.com
wrote:
+
On Tue, Apr 24, 2012 at 7:43 PM, Aldy Hernandez al...@redhat.com wrote:
On 04/13/12 03:46, Richard Guenther wrote:
On Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandezal...@redhat.com wrote:
Richard. Thanks so much for reviewing and providing an alternative
approach, which AFAICT provides
On 04/25/12 06:45, Richard Guenther wrote:
On Tue, Apr 24, 2012 at 7:43 PM, Aldy Hernandezal...@redhat.com wrote:
On 04/13/12 03:46, Richard Guenther wrote:
On Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandezal...@redhat.comwrote:
+ /* ?? Perhaps we should cache this somewhere in the
On 04/13/12 03:46, Richard Guenther wrote:
On Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandezal...@redhat.com 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
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 Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandez al...@redhat.com 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].
-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
race
Here we have
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
20 matches
Mail list logo
