[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-10 12:19 --- Subject: Bug 19342 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-10 12:18:52 Modified files: gcc: ChangeLog c-typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050119-1.c Log message: PR c/19342 * c-typeck.c (common_type): New routine. Old common_type renamed to... (c_common_type): ...this. (build_conditional_expr, build_binary_op): Use c_common_type instead of common_type. * gcc.c-torture/execute/20050119-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7429r2=2.7430 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gccr1=1.417r2=1.418 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5014r2=1.5015 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050119-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From jakub at gcc dot gnu dot org 2005-02-10 12:20 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08 23:52 --- Jakub, so why not get your patch of comment #11 in first, and worry about the, as you say yourself, unrelated bugs later? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-28 00:16 --- Jakub, what's the plan with this one, are you going to fix it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-28 06:26 --- Patch here http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01218.html. This one fixes the testcase, but while writing a larger testcase I found other unrelated bugs that aren't fixed yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-18 13:35 --- Note that GCC 3.4's common_type handled ENUMERAL_TYPEs. This was removed in PR13519 patch. -- What|Removed |Added CC||joseph at codesourcery dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From joseph at codesourcery dot com 2005-01-18 14:39 --- Subject: Re: [4.0 regression] ICE in common_type, at c-typeck.c:490 On Tue, 18 Jan 2005, jakub at gcc dot gnu dot org wrote: Note that GCC 3.4's common_type handled ENUMERAL_TYPEs. This was removed in PR13519 patch. Indeed, previously common_type did not have a well-defined purpose or interface and tried to do three different things. Now it is well-defined: /* Return the common type for two arithmetic types under the usual arithmetic conversions. The default conversions have already been applied, and enumerated types converted to their compatible integer types. So under the interface currently specified it shouldn't receive enumerated types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-18 18:28 --- But did this change for all frontends or just C? In the code in question common_type is used by code common to C and C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From joseph at codesourcery dot com 2005-01-18 20:10 --- Subject: Re: [4.0 regression] ICE in common_type, at c-typeck.c:490 On Tue, 18 Jan 2005, jakub at gcc dot gnu dot org wrote: But did this change for all frontends or just C? In the code in question common_type is used by code common to C and C++. I think the underlying problems there are (1) undesigned ad hoc sharing between the front ends, (2) this language-specific function being called from what's essentially an optimization, not only on types that appear directly in the source as operands to which usual arithmetic conversions are to be applies, (3) this optimization happens at this stage at all, rather than later in a language-independent way that doesn't need to call back into front ends. Short term, allowing enumerated types in common_type for C for this special case would make sense as a fix for this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-10 11:28
---
Yes, my patch clearly triggers this (changing silent miscompilation of the
code into an ICE).
The problem is that common_type doesn't handle ENUMERAL_TYPEs, so probably
shorten_compare should made sure it doesn't get passed down.
The difference is that while previously shorten_compare was passed
CONVERT_EXPRs,
created in convert.c's
/* If the precision of the EXPR's type is K bits and the
destination mode has more bits, and the sign is changing,
it is not safe to use a NOP_EXPR. For example, suppose
that EXPR's type is a 3-bit unsigned integer type, the
TYPE is a 3-bit signed integer type, and the machine mode
for the types is 8-bit QImode. In that case, the
conversion necessitates an explicit sign-extension. In
the signed-to-unsigned case the high-order bits have to
be cleared. */
if (TYPE_UNSIGNED (type) != TYPE_UNSIGNED (TREE_TYPE (expr))
(TYPE_PRECISION (TREE_TYPE (expr))
!= GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (expr)
code = CONVERT_EXPR;
else
code = NOP_EXPR;
return build1 (code, type, expr);
now, when the mode is fixed, we pass NOP_EXPR. So, before my patch
primop{0,1}'s
type was int while now it is that enum __attribute__((mode(byte))).
Now, C++ common_type handles ENUMERAL_TYPEs, so I don't think it is appropriate
to special case ENUMERAL_TYPEs in shorten_compare which is shared between
C/C++/ObjC. So perhaps add code to handle ENUMERAL_TYPEs in C common_type?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
-- What|Removed |Added Severity|normal |critical Keywords||ice-on-valid-code Known to fail||4.0.0 Known to work||3.3.4 3.4.2 Priority|P2 |P1 Summary|internal compiler error: in |[4.0 regression] ICE in |common_type, at c- |common_type, at c- |typeck.c:490|typeck.c:490 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 15:35 --- The only obvious change which caused this would be: 2005-01-07 Jakub Jelinek [EMAIL PROTECTED] * c-common.c (handle_mode_attribute): For ENUMERAL_TYPE, also copy TYPE_MODE. -- What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19342
