On Fri, Jul 24, 2015 at 07:21:07AM -0700, Cesar Philippidis wrote:
> This patch the check for IS_TYPE_OF_DECL_P in this patch. Is this ok for
> trunk?
> 2015-07-24 Cesar Philippidis
>
> gcc/
> * tree-cfg.c (struct replace_decls_d): New struct.
> (replace_block_vars_by_duplica
On 07/23/2015 03:11 PM, Jakub Jelinek wrote:
> On Thu, Jul 23, 2015 at 03:01:25PM -0700, Cesar Philippidis wrote:
>> On 07/23/2015 08:32 AM, Jakub Jelinek wrote:
>>> On Thu, Jul 23, 2015 at 08:20:50AM -0700, Cesar Philippidis wrote:
The attached patch does just that; it teaches
replace_bl
On Thu, Jul 23, 2015 at 03:01:25PM -0700, Cesar Philippidis wrote:
> On 07/23/2015 08:32 AM, Jakub Jelinek wrote:
> > On Thu, Jul 23, 2015 at 08:20:50AM -0700, Cesar Philippidis wrote:
> >> The attached patch does just that; it teaches
> >> replace_block_vars_by_duplicates to replace the decls insi
On 07/23/2015 08:32 AM, Jakub Jelinek wrote:
> On Thu, Jul 23, 2015 at 08:20:50AM -0700, Cesar Philippidis wrote:
>> The attached patch does just that; it teaches
>> replace_block_vars_by_duplicates to replace the decls inside the
>> value-exprs with a duplicate too. It's kind of messy though. At t
On Thu, Jul 23, 2015 at 08:20:50AM -0700, Cesar Philippidis wrote:
> The attached patch does just that; it teaches
> replace_block_vars_by_duplicates to replace the decls inside the
> value-exprs with a duplicate too. It's kind of messy though. At the
> moment I'm only considering VAR_DECL, PARM_DE
On 07/13/2015 06:43 AM, Michael Matz wrote:
> This also hints at other problems (which might not actually occur in the
> case at hand, but still): the contents of DECL_VALUE_EXPR is the "real"
> thing containing the value of a decl (i.e. a decl having a value-expr
> doesn't itself occur in the
On 13/07/15 16:21, Michael Matz wrote:
Hi,
On Mon, 13 Jul 2015, Tom de Vries wrote:
Implementing multi-step maps or making the hashmaps non-caching
doesn't solve any of the above problems
I'm not saying that making those hashmaps non-caching solves any of
these problems.
Ah, I didn't mean
Hi,
On Mon, 13 Jul 2015, Tom de Vries wrote:
> > Implementing multi-step maps or making the hashmaps non-caching
> > doesn't solve any of the above problems
>
> I'm not saying that making those hashmaps non-caching solves any of
> these problems.
Ah, I didn't mean to imply this, I meant to im
On 13/07/15 15:43, Michael Matz wrote:
Hi,
On Sun, 12 Jul 2015, Tom de Vries wrote:
I'm trying to get to a defined policy for what is allowed for caches.
Either forbidding or allowing multi-step dependencies, I don't really
mind.
I think forbidding is the way to go, because ...
I managed t
Hi,
On Sun, 12 Jul 2015, Tom de Vries wrote:
> > I'm trying to get to a defined policy for what is allowed for caches.
> > Either forbidding or allowing multi-step dependencies, I don't really
> > mind.
I think forbidding is the way to go, because ...
> > I managed to write a patch series tha
On 12/07/15 17:43, Tom de Vries wrote:
On 09/07/15 14:24, Michael Matz wrote:
Hi,
On Thu, 9 Jul 2015, Tom de Vries wrote:
Given this I think the call to gt_ggc_mx is superfluous because it
wouldn't work relyably for multi-step dependencies anyway. Hence a
situation that works with that call
On 09/07/15 14:24, Michael Matz wrote:
Hi,
On Thu, 9 Jul 2015, Tom de Vries wrote:
Given this I think the call to gt_ggc_mx is superfluous because it
wouldn't work relyably for multi-step dependencies anyway. Hence a
situation that works with that call in place, and breaking without
it is act
Hi,
On Thu, 9 Jul 2015, Tom de Vries wrote:
> > > Given this I think the call to gt_ggc_mx is superfluous because it
> > > wouldn't work relyably for multi-step dependencies anyway. Hence a
> > > situation that works with that call in place, and breaking without
> > > it is actually a bug wai
On 09/07/15 12:44, Tom de Vries wrote:
On 07/07/15 16:00, Michael Matz wrote:
Hi,
On Mon, 6 Jul 2015, Richard Biener wrote:
By doing so, we make the behaviour of gt_cleare_cache independent
of the
order in which the entries are visited, turning:
- hard-to-trigger bugs which trigger for one vi
On 07/07/15 16:00, Michael Matz wrote:
Hi,
On Mon, 6 Jul 2015, Richard Biener wrote:
By doing so, we make the behaviour of gt_cleare_cache independent of the
order in which the entries are visited, turning:
- hard-to-trigger bugs which trigger for one visiting order but not for
another, int
Hi,
On Mon, 6 Jul 2015, Richard Biener wrote:
> >> By doing so, we make the behaviour of gt_cleare_cache independent of the
> >> order in which the entries are visited, turning:
> >> - hard-to-trigger bugs which trigger for one visiting order but not for
> >> another, into
> >> - more easily tr
On Tue, Jul 7, 2015 at 11:39 AM, Tom de Vries wrote:
> On 07/07/15 10:42, Richard Biener wrote:
>>
>> On Mon, Jul 6, 2015 at 7:29 PM, Tom de Vries
>> wrote:
>>>
>>> On 06/07/15 15:29, Richard Biener wrote:
On Mon, Jul 6, 2015 at 3:25 PM, Richard Biener
wrote:
>
>
On 07/07/15 10:42, Richard Biener wrote:
On Mon, Jul 6, 2015 at 7:29 PM, Tom de Vries wrote:
On 06/07/15 15:29, Richard Biener wrote:
On Mon, Jul 6, 2015 at 3:25 PM, Richard Biener
wrote:
On Mon, Jul 6, 2015 at 10:57 AM, Tom de Vries
wrote:
Hi,
Using attached untested patch, I managed
On Mon, Jul 6, 2015 at 7:29 PM, Tom de Vries wrote:
> On 06/07/15 15:29, Richard Biener wrote:
>>
>> On Mon, Jul 6, 2015 at 3:25 PM, Richard Biener
>> wrote:
>>>
>>> On Mon, Jul 6, 2015 at 10:57 AM, Tom de Vries
>>> wrote:
Hi,
Using attached untested patch, I managed to minim
On 06/07/15 15:29, Richard Biener wrote:
On Mon, Jul 6, 2015 at 3:25 PM, Richard Biener
wrote:
On Mon, Jul 6, 2015 at 10:57 AM, Tom de Vries wrote:
Hi,
Using attached untested patch, I managed to minimize a test-case failure for
PR 66714.
The patch introduces two-phase marking in gt_cleare_
On Mon, Jul 6, 2015 at 3:25 PM, Richard Biener
wrote:
> On Mon, Jul 6, 2015 at 10:57 AM, Tom de Vries wrote:
>> Hi,
>>
>> Using attached untested patch, I managed to minimize a test-case failure for
>> PR 66714.
>>
>> The patch introduces two-phase marking in gt_cleare_cache:
>> - first phase, it
On Mon, Jul 6, 2015 at 10:57 AM, Tom de Vries wrote:
> Hi,
>
> Using attached untested patch, I managed to minimize a test-case failure for
> PR 66714.
>
> The patch introduces two-phase marking in gt_cleare_cache:
> - first phase, it loops over all the hash table entries and removes
> those whi
Hi,
Using attached untested patch, I managed to minimize a test-case failure
for PR 66714.
The patch introduces two-phase marking in gt_cleare_cache:
- first phase, it loops over all the hash table entries and removes
those which are dead
- second phase, it runs over all the live hash table
23 matches
Mail list logo
