On Thu, Feb 4, 2016 at 1:49 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Thu, Feb 4, 2016 at 12:09 PM, Eric Botcazou <ebotca...@adacore.com> wrote:
>>> So this doesn’t fix aarch64, c6x, epiphany, ia64, iq2000, rs6000, rx, sparc,
>>> tilegx, tilepro or xtensa.
>>> :-( That’s one of the problems by having each port copy and paste swaths of
>>> :code from other ports to express the same thing instead of ports sharing
>>> :just one copy of code. My port is also broken in the same way
>>> :(currently).
>>
>> Yes, fixing a compiler bug by changing the ABI is a no-no, and the argument
>> of
>> the compatibility with LLVM has IMO little merit since it's a GCC extension.
>
> True, but the compiler bug is in the backends - it just now gets
> exposed more easily
> (read: w/o user intervention).
>
>>> I’m curious why the caller of the hook can’t grab the main variant, if it
>>> wants. If it did this, then all the ports are fixed wrt this issue.
>>
>> Or just fix PRE wrt the alignment discrepancy, which looks a lot safer to me.
>> It's not because this works on x86 that this is necessarily correct for all
>> the other architectures, especially the strict-alignment architectures.
>
> Doesn't "fix" the same issue popping up in other passes.
Btw, one think I noticed is passes creating tempoaries with qualified type
which is not necessary. Not knowing enough about the PRE issue, does
Index: gcc/tree-ssanames.c
===================================================================
--- gcc/tree-ssanames.c (revision 233136)
+++ gcc/tree-ssanames.c (working copy)
@@ -286,7 +286,7 @@ make_ssa_name_fn (struct function *fn, t
if (TYPE_P (var))
{
- TREE_TYPE (t) = var;
+ TREE_TYPE (t) = TYPE_MAIN_VARIANT (var);
SET_SSA_NAME_VAR_OR_IDENTIFIER (t, NULL_TREE);
}
else
fix it? I played with sth similar for create_tmp_{reg,var} in the
past but don't
remember why I dropped the ball on it. At least changing create_tmp_reg
would be obvious (though that misses an assert the passed in type is
a gimple register type). For create_tmp_var it might not be that easy.
Richard.
> Richard.
>
>> --
>> Eric Botcazou
