[Bug 10475] New: [3.2/3.3/3.4 regression] ICE in subreg_highpart_offset for code with long long

gcc-bugzilla@gcc.gnu.org gcc-bugzilla@gcc.gnu.org
Wed May 21 17:02:00 GMT 2003

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.


           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:
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 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

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__)


void test(void) {
    assert_eq(0, 1) ;

gcc version 3.3 20030412 (Debian prerelease)

Debian x86, testing, using gcc-3.3

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) {
    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,

------- 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.) 
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.

More information about the Gcc-bugs mailing list