[Bug c++/65090] GCC produces instruction with bad alignment on SPARC when using -O

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65090

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-24
                 CC|                            |ebotcazou at gcc dot gnu.org
          Component|middle-end                  |c++
     Ever confirmed|0                           |1

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
4.9.x also works, but this nevertheless looks like a latent C++ bug to me:

  <<< Unknown tree: nullptr_type >>> D.29238;

  D.29238 = 0;

yields with mainline:

(insn 10 9 11 2 (set (mem/c:SI (plus:SI (reg/f:SI 104 virtual-stack-vars)
                (const_int -4 [0xfffffffffffffffc])) [0 D.29314+0 S4 A32])
        (const_int 0 [0])) t.cc:10 -1
     (nil))

But 32-bit alignment is forced by expand_one_stack_var_at, before it's 8-bit:

 <var_decl 0x7ffff583e870 D.29314
    type <nullptr_type 0x7ffff6e1bd20 decltype(nullptr) public unsigned type_6
SI
        size <integer_cst 0x7ffff6d0af00 constant 32>
        unit size <integer_cst 0x7ffff6d0af18 constant 4>
        align 8 symtab 0 alias set -1 canonical type 0x7ffff6e1bd20
        pointer_to_this <pointer_type 0x7ffff5f677e0> reference_to_this
<reference_type 0x7ffff5f675e8>>
    addressable used unsigned ignored SI file t.cc line 10 col 30 size
<integer_cst 0x7ffff6d0af00 32> unit size <integer_cst 0x7ffff6d0af18 4>
    align 8 context <function_decl 0x7ffff5f57870 __comp_ctor > abstract_origin
<var_decl 0x7ffff5f68090 D.25687>>

In other words giving SImode to NULLPTR_TYPE with only 8-bit alignment is a bit
dubious on strict-alignment platforms like SPARC.