This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR
- From: "dodji at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 10 Sep 2008 14:50:13 -0000
- Subject: [Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR
- References: <bug-37146-12710@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #4 from dodji at gcc dot gnu dot org 2008-09-10 14:50 -------
At PDF page 115, 5.16.6 (conditional operator), the standard says:
"Lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3)
standard conversions are performed on the second and third operands. After
those conversions, one of the following shall hold:"
? The second and third operands have the same type; the result is of that type.
? The second and third operands have arithmetic or enumeration type; the usual
arithmetic conversions are performed to bring them to a common type, and the
result is of that type.
[...]
"
We should actualy fall into the case of "the second and third operands have
arithmetic or enumeration type ...", but we are not. And that is the bug, I
think.
Instead, we are considering earlier that arg2 and arg3 have the same type --
which I believe is not true. We are considering that because the condition
if (real_lvalue_p (arg2)
&& real_lvalue_p (arg3)
&& same_type_p (arg2_type, arg3_type))
{
[...]
is true.
We are considering that arg2 and arg3 have the same type because we think
same_type_p (arg2_type, arg3_type) should be enough to determine their type
equality. But in this particular case, it's not because arg2_type and arg3_type
lost the information about the bit-field type and size of arg2 and arg3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37146