Re: [patch] Fix GC issue triggered by arithmetic overflow checking

On Sun, Oct 16, 2016 at 8:56 PM, Eric Botcazou wrote: >> 2016-10-11 Eric Botcazou >> >> * tree.h (build_complex_type): Add second parameter with default. >> * tree.c (build_complex_type): Add NAMED second parameter and adjust >>

Re: [patch] Fix GC issue triggered by arithmetic overflow checking

> 2016-10-11 Eric Botcazou > > * tree.h (build_complex_type): Add second parameter with default. > * tree.c (build_complex_type): Add NAMED second parameter and adjust > recursive call. Create a TYPE_DECL only if NAMED is true. >

Re: [patch] Fix GC issue triggered by arithmetic overflow checking

> I guess it depends on whether temp$8 and temp$low overlap or not. I don't think so, the code is identical so that would be a more serious bug: struct cpp_num { cpp_num_part high; cpp_num_part low; bool unsignedp; bool overflow; }; I think it's just dwarf2out_var_location being

Re: [patch] Fix GC issue triggered by arithmetic overflow checking

On Thu, Oct 13, 2016 at 12:19:53PM +0200, Richard Biener wrote: > > (note 6350 6349 6351 (var_location temp (nil)) NOTE_INSN_VAR_LOCATION) > > (note 6351 6350 6352 (var_location temp$low (mem/c:DI (plus:SI (reg/f:SI 30 > > %fp) > > (const_int -112 [0xff90])) [10 MEM[(struct

Re: [patch] Fix GC issue triggered by arithmetic overflow checking

On Thu, Oct 13, 2016 at 12:15 PM, Eric Botcazou wrote: >> Yes. But that's not the only source for DECL_UID differences. Btw, >> I see lots of FOR_EACH_HASH_TABLE_ELEMENT in var-tracking.c >> but they don't look like their outcome is supposed to be dependent on >> element

Re: [patch] Fix GC issue triggered by arithmetic overflow checking

> Yes. But that's not the only source for DECL_UID differences. Btw, > I see lots of FOR_EACH_HASH_TABLE_ELEMENT in var-tracking.c > but they don't look like their outcome is supposed to be dependent on > element ordering. This leads to NOTE_INSN_VAR_LOCATION notes emitted in a different order,

Re: [patch] Fix GC issue triggered by arithmetic overflow checking

> I think only the calls in build_common_tree_nodes -- those are the ones > built early and that survive GC. The patch is ok if it passes testing > with that. Here's what I have installed, after bootstrap/regtesting on x86-64/Linux and SPARC/Solaris (with the upcoming overflow checking

Re: [patch] Fix GC issue triggered by arithmetic overflow checking

On Mon, Oct 10, 2016 at 12:38 PM, Eric Botcazou wrote: >> I believe the rule is that you might only depend on the order of objects >> with respect to their DECL_UID, not the actual value of the DECL_UID. >> As var-tracking shouldn't look at TYPE_DECLs (?) it's probably a

Re: [patch] Fix GC issue triggered by arithmetic overflow checking

On Mon, Oct 10, 2016 at 12:38 PM, Eric Botcazou wrote: >> I believe the rule is that you might only depend on the order of objects >> with respect to their DECL_UID, not the actual value of the DECL_UID. >> As var-tracking shouldn't look at TYPE_DECLs (?) it's probably a

Re: [patch] Fix GC issue triggered by arithmetic overflow checking

> I believe the rule is that you might only depend on the order of objects > with respect to their DECL_UID, not the actual value of the DECL_UID. > As var-tracking shouldn't look at TYPE_DECLs (?) it's probably a latent > var-tracking bug as well. It presumably doesn't look at TYPE_DECLs, simply

Re: [patch] Fix GC issue triggered by arithmetic overflow checking

On Sat, Oct 8, 2016 at 8:56 PM, Eric Botcazou wrote: > Hi, > > adding patterns for unsigned arithmetic overflow checking in a back-end can > have unexpected fallout because of a latent GC issue: when they are present, > GIMPLE optimization passes can create complex (math.

[patch] Fix GC issue triggered by arithmetic overflow checking

Hi, adding patterns for unsigned arithmetic overflow checking in a back-end can have unexpected fallout because of a latent GC issue: when they are present, GIMPLE optimization passes can create complex (math. sense) types at will by invoking build_complex_type. Now build_complex_type goes