This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug 10475] New: [3.2/3.3/3.4 regression] ICE in subreg_highpart_offset for code with long long
- From: gcc-bugzilla at gcc dot gnu dot org
- To: gcc-bugs at gcc dot gnu dot org
- Date: 21 May 2003 16:01:46 -0000
- Subject: [Bug 10475] New: [3.2/3.3/3.4 regression] ICE in subreg_highpart_offset for code with long long
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10475
Summary: [3.2/3.3/3.4 regression] ICE in subreg_highpart_offset
for code with long long
Product: gcc
Version: 3.3
Status: NEW
Keywords: ice-on-valid-code
Severity: major
Priority: P3
Component: middle-end
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: mh37@cornell.edu
CC: bangerth@dealii.org,gcc-bugs@gcc.gnu.org
My assert()ion infrastructure causes an internal compiler error. I've included a single small source file (gorp.c) with that causes the problem and included the preprocessed file (gorp.i). No header files are needed.
gcc-3.3 -O2 -v -save-temps gorp.c
Reading specs from /usr/lib/gcc-lib/i386-linux/3.3/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.3 20030412 (Debian prerelease)
/usr/lib/gcc-lib/i386-linux/3.3/cc1 -E -quiet -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 gorp.c -O2 gorp.i
ignoring nonexistent directory "/usr/i386-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc-lib/i386-linux/3.3/include
/usr/include
End of search list.
/usr/lib/gcc-lib/i386-linux/3.3/cc1 -fpreprocessed gorp.i -quiet -dumpbase gorp.c -auxbase gorp -O2 -version -o gorp.s
GNU C version 3.3 20030412 (Debian prerelease) (i386-linux)
compiled by GNU C version 3.3 20030412 (Debian prerelease).
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32135
gorp.c: In function `test':
gorp.c:59: internal compiler error: in subreg_highpart_offset, at emit-rtl.c:1319
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
typedef unsigned char uint8_t ;
typedef unsigned short uint16_t ;
typedef unsigned uint32_t ;
typedef unsigned long long uint64_t ;
typedef uint32_t count_t ;
typedef uint32_t ofs_t ;
typedef uint32_t len_t ;
typedef void * env_t ;
#define NULL (0)
#define ATTRIBUTE(x) __attribute__((x))
#define PREDICT(v,c) ((bool_t) (__builtin_expect((v),(c))))
#define PREDICT_FALSE(v) PREDICT((v), FALSE)
#define PREDICT_TRUE(v) PREDICT((v), TRUE)
#define UNUSED() ATTRIBUTE(unused)
#define NO_RETURN() ATTRIBUTE(__noreturn__)
#define IS_CONSTANT(v) __builtin_constant_p(v)
/*************************************************************/
typedef int bool_t ;
#define FALSE ((bool_t)0)
#define TRUE ((bool_t)1)
/*************************************************************/
typedef const char * string_t ;
typedef char * stringm_t ;
typedef string_t debug_t ;
/*************************************************************/
void assert_eq_fail(
uint64_t val0,
uint64_t val1,
string_t expr0,
string_t expr1,
string_t file,
uint32_t line,
string_t function
) NO_RETURN() ;
static inline
void assert_eq_help(
uint64_t const v0,
uint64_t const v1,
string_t const v0_s,
string_t const v1_s,
string_t const file,
uint32_t const line,
string_t const function
) {
if (ASSERT_PREDICT_TRUE(v0 == v1)) {
return ;
}
assert_eq_fail(v0, v1, v0_s, v1_s, file, line, function) ;
}
#define assert_eq(v0, v1) \
assert_eq_help((v0), (v1), #v0, #v1, __FILE__, __LINE__, __FUNCTION__)
/*************************************************************/
static
void test(void) {
assert_eq(0, 1) ;
}
Release:
gcc version 3.3 20030412 (Debian prerelease)
Environment:
Debian x86, testing, using gcc-3.3
How-To-Repeat:
Compile gorp.c using the command line in the description above.
------- Additional Comments From bangerth@dealii.org 2003-24-04 13:19 -------
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed. Has nothing to do with builtin_expect, though:
---------------------------
static inline
void foo(long long const v0,
long long const v1)
{
bar(v0 == v1);
}
void test(void) {
foo(0,1);
}
-------------------------
This ICEs with 3.2, 3.3 and 3.4, but not with 3.0, so is
a regression:
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/gcc -c x.i -O2
x.i: In function `test':
x.i:5: internal compiler error: in subreg_highpart_offset, at emit-rtl.c:1486
Please submit a full bug report,
W.
------- Additional Comments From arend.bayer@web.de 2003-21-05 16:01 -------
This happens when emit_store_flag() gets passed two long integers, the
2nd being 0 and the code being EQ or NE.
This call
/* If we are comparing a double-word integer with zero, we can convert
the comparison into one involving a single word. */
if (GET_MODE_BITSIZE (mode) == BITS_PER_WORD * 2
&& GET_MODE_CLASS (mode) == MODE_INT
&& op1 == const0_rtx
&& (GET_CODE (op0) != MEM || ! MEM_VOLATILE_P (op0)))
{
if (code == EQ || code == NE)
{
/* Do a logical OR of the two words and compare the result. * */
rtx op0h = gen_highpart (word_mode, op0);
rtx op0l = gen_lowpart (word_mode, op0);
to gen_highpart silently assumes that GET_MODE (op0) == mode. But
if op0 is CONST_INT, it has VOIDmode, of course.
The patch (against HEAD on 2003-05-21) below makes the ICE go away, but of
course one might want to do s.th. more intelligent with a comparison of
two integer constants...
(And another solution would of course be to teach gen_highpart () to
handle integer constants.)
Arend
Index: gcc/expmed.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/expmed.c,v
retrieving revision 1.133
diff -u -p -r1.133 expmed.c
--- gcc/expmed.c 21 Apr 2003 21:32:00 -0000 1.133
+++ gcc/expmed.c 21 May 2003 14:17:20 -0000
@@ -4350,7 +4350,8 @@ emit_store_flag (target, code, op0, op1,
if (GET_MODE_BITSIZE (mode) == BITS_PER_WORD * 2
&& GET_MODE_CLASS (mode) == MODE_INT
&& op1 == const0_rtx
- && (GET_CODE (op0) != MEM || ! MEM_VOLATILE_P (op0)))
+ && (GET_CODE (op0) != MEM || ! MEM_VOLATILE_P (op0))
+ && GET_CODE (op0) != CONST_INT)
{
if (code == EQ || code == NE)
{
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.