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.
