[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #8 from Richard Earnshaw  ---
Looks like a dup of 77728.  At O1 or lower we get the new ABI change warning
with a trunk compiler.  Presumably at higher levels of optimization the
prolematic code gets optimized away.

*** This bug has been marked as a duplicate of bug 77728 ***

[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to James Greenhalgh from comment #5)
> I don't know enough about the C++ standard to know whether this patch is
> reasonable to backport to GCC 5. Jason, do you have an opinion?

I'd be pretty nervous about packporting that patch, as changes to that behavior
tend to have unexpected side-effects.  And it seems likely to have just made
this bug latent, rather than actually fixed it.

[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #6 from James Greenhalgh  ---
*ping*

[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #5 from James Greenhalgh  ---
I don't know enough about the C++ standard to know whether this patch is
reasonable to backport to GCC 5. Jason, do you have an opinion?

[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from James Greenhalgh  ---
Goes away on trunk after r223301

Author: jason 
Date:   Mon May 18 17:14:11 2015 +

DR 1391
* pt.c (type_unification_real): Check convertibility here.
(unify_one_argument): Not here.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@223301 

After which the DECL_ALIGN in both TUs is 64, fixing the bug.

[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||alan.lawrence at arm dot com,
   ||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #3 from James Greenhalgh  ---
I'm still confused by this. After coming out of the front end I checked the
DECL_ALIGN for each field of each of the parameters being passed to this
function. I see:


f1.ii

std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::iterator
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_emplace_hint_unique(std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::const_iterator, _Args&& ...)  
  (struct _Rb_tree * const this
   (decl alignment: 32),
   struct const_iterator __pos
 Fields:
   _M_node (decl alignment: 32)
   _Rb_tree_const_iterator (decl alignment: 8)
   value_type (decl alignment: 8)
   reference (decl alignment: 32)
   pointer (decl alignment: 32)
   iterator (decl alignment: 8)
   iterator_category (decl alignment: 8)
   difference_type (decl alignment: 32)
   _Self (decl alignment: 8)
   _Base_ptr (decl alignment: 32)
   _Link_type (decl alignment: 32)
   (decl alignment: 32, max field alignment: 32),
   const struct piecewise_construct_t & __args#0
   (decl alignment: 32),
   struct tuple & __args#1
   (decl alignment: 32),
   struct tuple & __args#2
   (decl alignment: 32))

f2.ii

std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::iterator
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_emplace_hint_unique(std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::const_iterator, _Args&& ...) 
  (struct _Rb_tree * const this
   (decl alignment: 32),
   struct const_iterator __pos
 Fields:
   _M_node (decl alignment: 32)
   _Rb_tree_const_iterator (decl alignment: 8)
   value_type (decl alignment: 64)
   reference (decl alignment: 32)
   pointer (decl alignment: 32)
   iterator (decl alignment: 32)
   iterator_category (decl alignment: 8)
   difference_type (decl alignment: 32)
   _Self (decl alignment: 8)
   _Base_ptr (decl alignment: 32)
   _Link_type (decl alignment: 32)
   (decl alignment: 32, max field alignment: 64),
   const struct piecewise_construct_t & __args#0
   (decl alignment: 32),
   struct tuple & __args#1
   (decl alignment: 32),
   struct tuple & __args#2
   (decl alignment: 32))
---

That is to say, after gimplification we've already decided that the alignment
of the value_type field of the std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::const_iterator parameter to std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::_M_emplace_hint_unique in f2.ii is 64, whereas in f1.ii we
don't have any extra alignment information.

I know nothing about the C++ front-end and how we could end up in this
situation. I can understand why, given this, we would generate the code we do
for ARM.

[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jgreenhalgh at gcc dot 
gnu.org

--- Comment #2 from James Greenhalgh  ---
At the heart of the problem, the compiler has decided that the second parameter
to this templated function has an overaligned member (64-byte aligned in f2,
8-byte aligned in f1). This gives different parameter passing rules, and you
get the code difference above.

I haven't figured out what causes the alignment to differ between the two TUs,
or why the compiler feels it is safe to propagate the alignment information
without specializing the function name.

I'll take the bug while I look deeper.

[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-22
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from James Greenhalgh  ---
Confirmed, I'm trying to figure out what is going wrong.