[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #10 from mmitchel at gcc dot gnu dot org 2007-03-11 03:08 --- Subject: Bug 30274 Author: mmitchel Date: Sun Mar 11 03:07:59 2007 New Revision: 122813 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122813 Log: PR c++/30274 * cp-tree.h (unlowered_expr_type): New function. * typeck.c (is_bitfield_expr_with_lowered_type): Handle COMPOUND_EXPR, MODIFY_EXPR, and SAVE_EXPR. (unlowered_expr_type): New function. (build_unary_op): Disallow predecrements of bool bitfields. * call.c (build_conditional_expr): Use unlowered_expr_type. * pt.c (type_unification_real): Likewise. PR c++/30274 * g++.dg/expr/bitfield3.C: New test. * g++.dg/expr/bitfield4.C: Likewise. * g++.dg/expr/bitfield5.C: Likewise. * g++.dg/expr/bitfield6.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/expr/bitfield3.C trunk/gcc/testsuite/g++.dg/expr/bitfield4.C trunk/gcc/testsuite/g++.dg/expr/bitfield5.C trunk/gcc/testsuite/g++.dg/expr/bitfield6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #11 from mmitchel at gcc dot gnu dot org 2007-03-11 03:09 --- Subject: Bug 30274 Author: mmitchel Date: Sun Mar 11 03:09:32 2007 New Revision: 122814 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122814 Log: PR c++/30274 * cp-tree.h (unlowered_expr_type): New function. * typeck.c (is_bitfield_expr_with_lowered_type): Handle COMPOUND_EXPR, MODIFY_EXPR, and SAVE_EXPR. (unlowered_expr_type): New function. (build_unary_op): Disallow predecrements of bool bitfields. * call.c (build_conditional_expr): Use unlowered_expr_type. * pt.c (type_unification_real): Likewise. PR c++/30274 * g++.dg/expr/bitfield3.C: New test. * g++.dg/expr/bitfield4.C: Likewise. * g++.dg/expr/bitfield5.C: Likewise. * g++.dg/expr/bitfield6.C: Likewise. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/expr/bitfield3.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/expr/bitfield4.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/expr/bitfield5.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/expr/bitfield6.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/call.c branches/gcc-4_2-branch/gcc/cp/cp-tree.h branches/gcc-4_2-branch/gcc/cp/pt.c branches/gcc-4_2-branch/gcc/cp/typeck.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-03-11 03:10 --- Fixed in 4.2.0, 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #8 from bangerth at dealii dot org 2007-02-26 19:10 --- Mark, I think you misunderstood: the value *should* be set to 'true' (==1), but is set to '2'. Or do you mean that '2' is another valid representation of 'true' and that therefore this is ok? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-02-26 20:19 --- I'm sorry; I did apparently misunderstand. My reading of the report was that x did not become 2, and that this made the submitter unhappy. I agree that x should not become 2. Although 2 is a valid *representation* of true, converting x to int must yield 1, not 2. So, either we need conversion code, or we need to avoid x being 2 in the first place. The latter is clearly more efficient. Either the C++ front end or the middle end should transform any ++ operation on bool to = true. I'm not sure if there are languages where the equivalent of b = true; ++b should yield false. In any case, I suspect this is most easily done in the front end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #7 from s__nakayama at infoseek dot jp 2007-02-21 02:25 --- (In reply to comment #6) This is not a bug. The C++ standard says: [expr.post.incr] the value of the object is modified by adding 1 to it, unless the object is of type bool, in which case it is set to true I do not understand why this is not a bug. Will someone explain why this is not a bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-02-19 20:57 --- This is not a bug. The C++ standard says: [expr.post.incr] the value of the object is modified by adding 1 to it, unless the object is of type bool, in which case it is set to true -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #3 from s__nakayama at infoseek dot jp 2006-12-22 08:39 ---
(In reply to comment #2)
When is the justification that we expect a value of 2? Bool in C++ is
a one-bit type and when you do x.x++ I would imagine that you overflow
the range of that type. The fact that you declare it as a bit-field of
length 4 is immaterial, in my opinion: you also don't get a 128-bit integer
simply by declaring a variable as
struct X {
int x : 128;
};
It is a result of g++4.2 not a expectation that a value becomes 2.
Bit-size is immaterial.
The problem is that std 5.3.2 isn't applied for bit-field.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-22 08:45 --- This is a very simple patch to fix this issue also: -if (same_type_p (TREE_TYPE (arg), boolean_type_node)) +if (TREE_CODE (TREE_TYPE (arg)) == BOOLEAN_TYPE) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |ASSIGNED Last reconfirmed|2006-12-21 18:13:05 |2006-12-22 08:45:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-22 09:24 --- Actually I was wrong in saying this is an easy fix. That part of the fix is still needed but there is another issue in that we are getting the wrong type for the increment: component_ref 0xb7d2a118 type integer_type 0xb7d5e9b4 public unsigned QI size integer_cst 0xb7c911e0 constant invariant 8 unit size integer_cst 0xb7c911f8 constant invariant 1 align 8 symtab 0 alias set -1 precision 4 min integer_cst 0xb7d61120 0 max integer_cst 0xb7d61138 15 arg 0 var_decl 0xb7c9e210 x type record_type 0xb7d5e8fc S type_1 type_5 QI size integer_cst 0xb7c911e0 8 unit size integer_cst 0xb7c911f8 1 align 8 symtab 0 alias set -1 fields field_decl 0xb7d5e958 x X() X(constX) this=(X) n_parents=0 use_template=0 interface-unknown pointer_to_this pointer_type 0xb7d5eac8 chain type_decl 0xb7d27958 S used tree_1 tree_2 tree_3 decl_5 QI file t.cc line 9 size integer_cst 0xb7c911e0 8 unit size integer_cst 0xb7c911f8 1 align 8 context function_decl 0xb7d5f0e0 main initial constructor 0xb7d61330 arg 1 field_decl 0xb7d5e958 x type integer_type 0xb7d5e9b4 used unsigned external nonlocal bit-field nonaddressable decl_3 decl_4 QI file t.cc line 4 size integer_cst 0xb7d235d0 constant invariant 4 unit size integer_cst 0xb7c911f8 1 align 1 offset_align 128 offset integer_cst 0xb7c91180 constant invariant 0 bit offset integer_cst 0xb7c91930 constant invariant 0 bit_field_type boolean_type 0xb7ca54ac bool public unsigned QI size integer_cst 0xb7c911e0 8 unit size integer_cst 0xb7c911f8 1 align 8 symtab 0 alias set -1 precision 1 min integer_cst 0xb7c915d0 0 max integer_cst 0xb7c91600 1 context record_type 0xb7d5e8fc S chain type_decl 0xb7d279c0 S type record_type 0xb7d5e8fc S nonlocal decl_4 VOID file t.cc line 3 align 1 context record_type 0xb7d5e8fc S -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-21 18:13 --- The problem is in: if (same_type_p (TREE_TYPE (arg), boolean_type_node)) Which was in 4.2 and before: if (TREE_TYPE (arg) == boolean_type_node) Confirmed. I might be able to fix this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-12-21 18:13:05 date|| Summary|bool bit-field: wrong |[4.2/4.3 Regression] bool |increment and decremenet|bit-field: wrong increment ||and decremenet Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
[Bug c++/30274] [4.2/4.3 Regression] bool bit-field: wrong increment and decremenet
--- Comment #2 from bangerth at dealii dot org 2006-12-22 00:52 ---
When is the justification that we expect a value of 2? Bool in C++ is
a one-bit type and when you do x.x++ I would imagine that you overflow
the range of that type. The fact that you declare it as a bit-field of
length 4 is immaterial, in my opinion: you also don't get a 128-bit integer
simply by declaring a variable as
struct X {
int x : 128;
};
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
