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
>> recursive call. Create a TYPE_DECL only if NAME
> 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.
> (build_common_tree_nodes): Pass true in
> 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 sensitiv
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 cpp_
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 ordering.
>
> This leads
> 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,
> 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 support).
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 latent
>> var-tracking bug
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 latent
>> var-tracking bug
> 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
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. sense) types at will by
>
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 thr
12 matches
Mail list logo
