https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 21 Jan 2016, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273 > > Jeffrey A. Law <law at redhat dot com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Priority|P3 |P2 > Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot > gnu.org > > --- Comment #4 from Jeffrey A. Law <law at redhat dot com> --- > It's starting to look like a problem in tree-ssa-pre.c > > Essentially we have these these key statements in various blocks: > > _10 = yyvsp_1->sym; > _15 = yyvsp_1->sym; > _17 = enter (_14, _15); > _22 = MEM[(union YYSTYPE *)yyvsp_1]; > > Respectively _10 and _22 have the types: > > (gdb) p debug_tree (cfun->gimple_df->ssa_names.m_vecdata[10]->typed.type) > <pointer_type 0x7ffff03c6498 > type <record_type 0x7ffff0384348 Symbol type_0 SI > size <integer_cst 0x7ffff02dd5e8 constant 32> > unit size <integer_cst 0x7ffff02dd600 constant 4> > align 32 symtab 0 alias set -1 canonical type 0x7ffff03842a0 > fields <field_decl 0x7ffff02ee8e8 name type <pointer_type > 0x7ffff02ebe70> > unsigned SI file j.c line 4 col 9 size <integer_cst 0x7ffff02dd5e8 > 32> unit size <integer_cst 0x7ffff02dd600 4> > align 32 offset_align 64 > offset <integer_cst 0x7ffff02dd618 constant 0> > bit offset <integer_cst 0x7ffff02dd678 constant 0> context > <record_type 0x7ffff03842a0 Symbol>> context <translation_unit_decl > 0x7ffff03c80f0 D.1453> > pointer_to_this <pointer_type 0x7ffff03c6498> chain <type_decl > 0x7ffff02ee850 D.1407>> > sizes-gimplified public unsigned SI size <integer_cst 0x7ffff02dd5e8 32> > unit size <integer_cst 0x7ffff02dd600 4> > align 32 symtab 0 alias set -1 canonical type 0x7ffff03c6540> > > > (gdb) p debug_tree (cfun->gimple_df->ssa_names.m_vecdata[22]->typed.type) > <pointer_type 0x7ffff03cd5e8 > type <record_type 0x7ffff0384498 Tnode type_0 BLK > size <integer_cst 0x7ffff02dd678 constant 0> > unit size <integer_cst 0x7ffff02dd618 constant 0> > align 8 symtab 0 alias set -1 canonical type 0x7ffff03843f0 context > <translation_unit_decl 0x7ffff03c80f0 D.1453> > pointer_to_this <pointer_type 0x7ffff0384c78> chain <type_decl > 0x7ffff02eea18 D.1410>> > sizes-gimplified unsigned SI > size <integer_cst 0x7ffff02dd5e8 type <integer_type 0x7ffff02d6150 > bitsizetype> constant 32> > unit size <integer_cst 0x7ffff02dd600 type <integer_type 0x7ffff02d60a8 > sizetype> constant 4> > align 64 symtab 0 alias set -1 canonical type 0x7ffff0384d20> > > The type of _15 is the same as the type of _10. > > For reference, we're referring to instances of this structure: > > union YYSTYPE > { > Symbol *sym; > Node rec; > }; > > > The key thing to note from the types is they have different alignments. > > Anyway, PRE detects the redundant memory reference and creates: > > # prephitmp_23 = PHI <pretmp_26(9), _10(5)> > > > Where _23 and _26 will have the type with the 64 bit alignment. > > That node feeds this statement: > > _17 = enter (_14, prephitmp_23); > > Yow! Remember that statement previously looked like: > > _17 = enter (_14, _15); > > So the alignment associated with the second argument to "enter" has changed > from 32 to 64. That in turn may change how the argument gets passed on some > ports (mips, epiphany, maybe others). In this specific instance is causes > the > MIPS backend to align the parameter, passing it in $6 rather than where the > callee expects it ($5), which in turn results in gsoap being mis-compiled on > MIPS. > > Richi -- you know the PRE code better than anyone that's currently active. > Thoughts? Sounds like the same mistake the ARM port had - deriving calling convention from type alignment of (r)_values_. An rvalue doesn't have alignment. Value-numbering (and PRE) unify based on value equivalence, it doesn't matter whether the type of the value stored in register _23 or _15 are different, all it matters is if they are the same, say 42 (with "alignment 8") or 42 (with "alignment 16"). Values don't have alignment. The ports need to be fixed similar to how ARM AACPS was fixed. See 2015-07-06 Alan Lawrence <alan.lawre...@arm.com> Backport from mainline r225465 2015-07-06 Alan Lawrence <alan.lawre...@arm.com> PR target/65956 * config/arm/arm.c (arm_needs_doubleword_align): Drop any outer alignment attribute, exploring one level down for records and arrays.
