[Bug c++/40335] New: The implement of Switch statment is against with C++ standard
Source code: 1.cpp
#include
static int i;
int
main (void)
{
i = -1;
switch ((signed char) i) {
case 255:
printf("255\n");
break;
default:
printf("default\n");
break;
}
}
Compiling command : g++ 1.cpp && ./a.out
result : 255
The expected result: default
According to C++ standard, an integral promotion of expression "(signed char)
i" should be performed firstly, the result of control expression should be
0x; then the label of case statment will be converted to int-type. So the
expected result should be default in my opinion.
Thanks very much.
C++ standard:
The condition shall be of integral type, enumeration type, or of a class type
for which a single conversion function to integral or enumeration type exists
(12.3). If the condition is of class type, the condition is converted by
calling that conversion function, and the result of the conversion is used in
place of the original condition for the remainder of this section.
Integral promotions are performed.
Any statement within the switch statement can be labeled with one or more case
labels as follows:
case constant-expression :
where the constant-expression shall be an integral constant-expression. The
integral constant-expression (5.19) is implicitly converted to the promoted
type of the switch condition.
--
Summary: The implement of Switch statment is against with C++
standard
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shenrfen at gmail dot com
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40335
[Bug c++/40335] The implement of Switch statment is against with C++ standard
--- Comment #2 from shenrfen at gmail dot com 2009-06-04 09:09 --- The expected result should be -1, not 255. But the result is 255 when I use g++ to compiling this code. -- shenrfen at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40335
[Bug c++/40335] The implement of Switch statment is against with C++ standard
--- Comment #3 from shenrfen at gmail dot com 2009-06-04 09:47 ---
I have debug the C++ front-end of gcc3.3.5.
In function finish_switch_cond:
if (cond != error_mark_node)
{
cond = default_conversion (cond);
cond = fold (build1 (CLEANUP_POINT_EXPR, TREE_TYPE (cond), cond));
}
SRF: the type of cond is "int"
if (cond != error_mark_node)
{
index = get_unwidened (cond, NULL_TREE);
/* We can't strip a conversion from a signed type to an unsigned,
because if we did, int_fits_type_p would do the wrong thing
when checking case values for being in range,
and it's too hard to do the right thing. */
if (TREE_UNSIGNED (TREE_TYPE (cond))
== TREE_UNSIGNED (TREE_TYPE (index)))
cond = index;
}
SRF: bug the type of cond is back to "signed char" here.
Maybe there is something error in function "get_unwidened"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40335
[Bug c++/40335] The implement of Switch statment is against with C++ standard
--- Comment #5 from shenrfen at gmail dot com 2009-06-04 10:24 --- Thanks very much. Waiting for your patch. the patch of gcc3.3.5 is also expected if you have enough time to do it. it should be similar with gcc4.** Thanks agian. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40335
[Bug c/41793] New: About Long long bit field
Test case:
struct s
{
unsigned long long a:2;
unsigned long long b:40;
unsigned long long c:22;
};
int main()
{
struct s t = {1, 2, 3};
printf("0x%llx\n",(t.b-8));
}
The output of gcc42 is 0xfa (which is yield to be 40bits)
Why not 0xfffa (It should be 64bits)
--
Summary: About Long long bit field
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shenrfen at gmail dot com
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41793
[Bug c/41794] New: About Long long bit field
Test case:
struct s
{
unsigned long long a:2;
unsigned long long b:40;
unsigned long long c:22;
};
int main()
{
struct s t = {1, 2, 3};
printf("0x%llx\n",(t.b-8));
}
The output of gcc42 is 0xfa (which is yield to be 40bits)
Why not 0xfffa (It should be 64bits)
--
Summary: About Long long bit field
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shenrfen at gmail dot com
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41794
[Bug c/41793] [4.3/4.4/4.5 Regression] About Long long bit field
--- Comment #3 from shenrfen at gmail dot com 2009-10-22 09:42 ---
Confused for the result.
int main()
{
struct s t = {1, 2, 3};
printf("0x%llx\n",(t.a-8));
printf("0x%llx\n",(t.b-8));
printf("0x%llx\n",(t.c-8));
}
the output is as following
0xfff9 (32 bit)
0xfa (40 bit)
0xfb (40 bit)
if one operand type is long long bit filed and another is 32-bit int, What is
the type conversion rule? Or it is an undefined behavior?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41793
[Bug c/41793] [4.3/4.4/4.5 Regression] About Long long bit field
--- Comment #5 from shenrfen at gmail dot com 2009-10-22 15:46 ---
Thanks very much for all your reply.
But I also have another question, Why is the 3rd output 40bits?
int main()
{
struct s t = {1, 2, 3};
printf("0x%llx\n",(t.a-8));
printf("0x%llx\n",(t.b-8));
printf("0x%llx\n",(t.c-8));
}
the output is as following
0xfff9 (32 bit)
0xfa (40 bit)
0xfb (40 bit) // but why, here is also 40 bit.
And I have do another experience.
struct s
{
unsigned long long a:2;
unsigned long long b:40;
unsigned long long c:22;
};
int main()
{
struct s t = {1, 2, 3};
unsigned long long a = t.a - 8;
unsigned long long b = t.b - 8;
unsigned long long c = t.c - 8;
printf("0x%llx\n",a);
printf("0x%llx\n",b);
printf("0x%llx\n",c);
}
Tht output is :
0xfff9
0xfa
0xfffb
Could you please tell me the full name of DR #120 documents.
Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41793
[Bug c/41793] [4.3/4.4/4.5 Regression] About Long long bit field
--- Comment #7 from shenrfen at gmail dot com 2009-10-23 01:52 ---
What about the following case? There is not un-defined behavior.
PS :Could you please tell me the full name of DR #120 documents.
Thanks again.
struct s
{
unsigned long long a:2;
unsigned long long b:40;
unsigned long long c:22;
};
int main()
{
struct s t = {1, 2, 3};
unsigned long long a = t.a - 8;
unsigned long long b = t.b - 8;
unsigned long long c = t.c - 8;
printf("0x%llx\n",a);
printf("0x%llx\n",b);
printf("0x%llx\n",c);
}
Tht output is :
0xfff9
0xfa
0xfffb
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41793
[Bug c/41793] [4.3/4.4/4.5 Regression] About Long long bit field
--- Comment #10 from shenrfen at gmail dot com 2009-10-23 03:06 --- Thanks very very much. What a good development team. Good luck to all of you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41793
