[Bug middle-end/43997] New: -finline-small-functions related oops
; } -- Summary: -finline-small-functions related oops Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dps at simpson dot demon dot co dot uk GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43997
[Bug middle-end/43997] -finline-small-functions related oops
--- Comment #1 from dps at simpson dot demon dot co dot uk 2010-05-05 22:04 --- Created an attachment (id=20573) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20573action=view) code for test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43997
[Bug c/41203] New: -mtune=pentium2 structure related tree-outof-ssa internal compiler error
There seems to be a tree-ssa related structure member assignment problem that
affects gcc -m32 -{O,O2,O3,Os} -mtune=pentium2 but apparently nothing else.
Removing the if statement out of the set_foo function also avoids the bug.
Screen shot:
$ gcc --version
gcc (GCC) 4.5.0 20090809 (experimental)
... all the rest eldided...
$ gcc -Os -m32 -march=i686 -mtune=pentium2 -c -o block/blk-settings.o
/tmp/blk-settings2.c
/tmp/blk-settings2.c: In function 'set_foo':
/tmp/blk-settings2.c:9:6: internal compiler error: in
insert_value_copy_on_edge, at tree-outof-ssa.c:223
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Code:
/* insert_value_copy_on_edge, at tree-outof-ssa.c:223
* gcc (GCC) 4.5.0 20090809 (experimental)
* platform x86_64-unknown-linux-gnu */
struct foo
{
unsigned short foo;
};
void set_foo(struct foo *p, unsigned short bar)
{
if (!bar)
bar = 1;
p-foo = bar;
}
--
Summary: -mtune=pentium2 structure related tree-outof-ssa
internal compiler error
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dps at simpson dot demon dot co dot uk
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41203
[Bug libffi/41014] New: Fix for libffi err_bad_abi test failure
(tramp, (char *) ffi_closure_LINUX64, 16);
tramp[2] = codeloc;
--- libffi/src/powerpc/ffi_darwin.c.dist2009-08-09 16:16:18.272507501
+0100
+++ libffi/src/powerpc/ffi_darwin.c 2009-08-09 16:17:03.916005633 +0100
@@ -580,9 +580,7 @@
closure-user_data = user_data;
default:
-
- FFI_ASSERT(0);
- break;
+ return FFI_BAD_ABI;
}
return FFI_OK;
}
--- libffi/src/sh64/ffi.c.dist 2009-08-09 16:16:18.340005195 +0100
+++ libffi/src/sh64/ffi.c 2009-08-09 16:22:13.148004794 +0100
@@ -302,7 +302,9 @@
{
unsigned int *tramp;
- FFI_ASSERT (cif-abi == FFI_GCC_SYSV);
+ /* Reject if bad ABI */
+ if (cif == NULL || cif-abi != FFI_GCC_SYSV)
+return FFI_BAD_ABI;
tramp = (unsigned int *) closure-tramp[0];
/* Since ffi_closure is an aligned object, the ffi trampoline is
--- libffi/src/arm/ffi.c.dist 2009-08-09 16:16:17.625740271 +0100
+++ libffi/src/arm/ffi.c2009-08-09 16:17:03.908010391 +0100
@@ -295,7 +295,9 @@
void *user_data,
void *codeloc)
{
- FFI_ASSERT (cif-abi == FFI_SYSV);
+ /* Reject if bad ABI */
+ if (cif == NULL || cif-abi != FFI_SYSV)
+return FFI_BAD_ABI;
FFI_INIT_TRAMPOLINE (closure-tramp[0], \
ffi_closure_SYSV, \
--- libffi/src/m68k/ffi.c.dist 2009-08-09 16:16:18.736505821 +0100
+++ libffi/src/m68k/ffi.c 2009-08-09 16:17:03.912006032 +0100
@@ -255,7 +255,9 @@
void *user_data,
void *codeloc)
{
- FFI_ASSERT (cif-abi == FFI_SYSV);
+ /* Reject if bad ABI */
+ if (cif == NULL || cif-abi != FFI_SYSV)
+return FFI_BAD_ABI;
*(unsigned short *)closure-tramp = 0x207c;
*(void **)(closure-tramp + 2) = codeloc;
--- libffi/src/x86/ffi.c.dist 2009-08-09 16:16:18.75669 +0100
+++ libffi/src/x86/ffi.c2009-08-09 16:17:03.920005594 +0100
@@ -538,6 +538,12 @@
void *user_data,
void *codeloc)
{
+ /* Reject if bad ABI */
+ if (cif == NULL)
+return FFI_BAD_ABI;
+ if (cif-abi FFI_FIRST_ABI || cif-abi = FFI_LAST_ABI)
+return FFI_BAD_ABI;
+
#ifdef X86_WIN64
#define ISFLOAT(IDX) (cif-arg_types[IDX]-type == FFI_TYPE_FLOAT ||
cif-arg_types[IDX]-type == FFI_TYPE_DOUBLE)
#define FLAG(IDX) (cif-nargs(IDX)ISFLOAT(IDX)?(1(IDX)):0)
--- libffi/src/x86/ffi64.c.dist 2009-08-09 16:16:18.75669 +0100
+++ libffi/src/x86/ffi64.c 2009-08-09 16:17:03.916005633 +0100
@@ -443,6 +443,12 @@
{
volatile unsigned short *tramp;
+ /* Reject if bad ABI */
+ if (cif == NULL)
+return FFI_BAD_ABI;
+ if (cif-abi FFI_FIRST_ABI || cif-abi = FFI_LAST_ABI)
+return FFI_BAD_ABI;
+
tramp = (volatile unsigned short *) closure-tramp[0];
tramp[0] = 0xbb49; /* mov code, %r11 */
--- libffi/src/ia64/ffi.c.dist 2009-08-09 16:16:18.936507927 +0100
+++ libffi/src/ia64/ffi.c 2009-08-09 16:17:03.912006032 +0100
@@ -425,7 +425,9 @@
struct ffi_ia64_trampoline_struct *tramp;
struct ia64_fd *fd;
- FFI_ASSERT (cif-abi == FFI_UNIX);
+ /* Reject if bad ABI */
+ if (cif == NULL || cif-abi != FFI_UNIX)
+return FFI_BAD_ABI;
tramp = (struct ffi_ia64_trampoline_struct *)closure-tramp;
fd = (struct ia64_fd *)(void *)ffi_closure_unix;
--- libffi/src/cris/ffi.c.dist 2009-08-09 16:16:18.804505313 +0100
+++ libffi/src/cris/ffi.c 2009-08-09 16:17:03.908010391 +0100
@@ -368,7 +368,10 @@
void *codeloc)
{
void *innerfn = ffi_prep_closure_inner;
- FFI_ASSERT (cif-abi == FFI_SYSV);
+ /* Reject if bad ABI */
+ if (cif == NULL || cif-abi != FFI_SYSV)
+return FFI_BAD_ABI;
+
closure-cif = cif;
closure-user_data = user_data;
closure-fun = fun;
--
Summary: Fix for libffi err_bad_abi test failure
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dps at simpson dot demon dot co dot uk
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41014
[Bug target/40957] New: standard_sse_constant_opcode crash on x86 64
The following code, which is a trimmed version of a preprocessed glibc test
case (which also fails) calls standard_sse_constant_opcode with a case which is
not implemenetd. Hence the slightly strange code, The precise version of gcc is
4.5.0 20090731 (experimental). The bugs works with gcc -O[123s] -mavx. gcc -O0
-mavx is not affected.
I think this is a bug in the i386 driver, which fails to realise this case is
possible, but really do not know enough about this area to be absolutely
certain.
typedef unsigned int uint32_t;
typedef unsigned long int uint64_t;
typedef unsigned long int ulong;
typedef unsigned int uint;
typedef unsigned int u_int32_t __attribute__ ((__mode__ (__SI__)));
typedef uint32_t Elf_Symndx;
typedef float La_x86_64_xmm __attribute__ ((__vector_size__ (16)));
typedef float La_x86_64_ymm __attribute__ ((__vector_size__ (32)));
typedef union
{
La_x86_64_ymm ymm[2];
La_x86_64_xmm xmm[4];
} La_x86_64_vector __attribute__ ((aligned(16)));
typedef struct La_x86_64_retval
{
uint64_t lrv_rax;
uint64_t lrv_rdx;
La_x86_64_xmm lrv_xmm0;
La_x86_64_xmm lrv_xmm1;
long double lrv_st0;
long double lrv_st1;
La_x86_64_vector lrv_vector0;
La_x86_64_vector lrv_vector1;
} La_x86_64_retval;
typedef int __v8si __attribute__ ((__vector_size__ (32)));
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));
extern __inline __m256i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm256_set1_epi32 (int __A)
{
return __extension__ (__m256i)(__v8si){ __A, __A, __A, __A,
__A, __A, __A, __A };
}
# 7 tst-auditmod4b.c 1
unsigned int
x_pltexit (La_x86_64_retval *outregs)
{
__m256i ymm = _mm256_set1_epi32 (-1);
asm volatile (vmovdqa %0, %%ymm0 : : x (ymm) : xmm0 );
return 0;
}
--
Summary: standard_sse_constant_opcode crash on x86 64
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dps at simpson dot demon dot co dot uk
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40957
[Bug c/35170] New: Suspected value range propagation [VRP] failure with ? :
There is at least one simple case that the value range deduction apparently
fails to cover. The compiler generates a message about control reaching
possibly the end of a non-void function given the source file:
#include string.h
int ns_strcmp(const char *a, const char *b)
{
int i;
i= (a==NULL) ? 0 : 1;
i |= (b==NULL) ? 0 : 2;
switch(i)
{
case 0: /* a=NULL, b=NULL */
return 0; /* a=b */
/* NOT REACHED */
case 1: /* a=NULL, b!=NULL */
return -1; /* ab */
/* NOT REACHED */
case 2: /* a!=NULL, b=NULL */
return 1; /* ab */
/* NOT REACHED */
case 3: /* a!=NULL, b!=NULL */
return strcmp(a, b);/* Use strcmp */
/* NOT REACHED */
}
/* NOT REACHED */
}
Reaching the end of the function is clearly impossible because i must be 0, 1
after i=(a==NULL) ? 0 : 1 and 0, 1, 2, 3 or after the i |= (b==NULL) ? 0 : 2.
It would be nice if value range propagation could deduce that i=0 and i=3,
after which it would be sufficient to notice that all the possible values are
covered in the switch to deduce that the control can not reach beyond the
switch.
However gcc seems to miss this fact, even with -O3, and the generated assembly
seems to include coverage of both i0 and i3. Replacing |= with += does not
eliminate the warning about control possibly reaching the end of a non-void
function.
It would be even nicer if I could replace 2 with 4 and adjust the case values
accordingly and still not get a warning but that would require propagation of
more than a single value range. My processor is an AMD Athlon(tm) 64 X2 Dual
Core Processor 4400+, although I suspect the logic that misses the relevant
information is target independent.
I can avoid the warning by handling the last case after the switch.
host$ Linux dps 2.6.24 #9 SMP PREEMPT Sat Feb 2 18:17:42 GMT 2008 x86_64
GNU/Linux
host$ gcc --version
gcc (GCC) 4.3.0 20080209 (experimental)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
host$ gcc -c -O3 -Wall /tmp/message.c
/tmp/message.c: In function ns_strcmp:
/tmp/message.c:24: warning: control reaches end of non-void function
--
Summary: Suspected value range propagation [VRP] failure with ? :
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dps at simpson dot demon dot co dot uk
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35170
[Bug libgcj/33114] jc1 segault building lljava/java/util/AbstractMap.java
--- Comment #4 from dps at simpson dot demon dot co dot uk 2007-12-07 13:26 --- Subject: Re: jc1 segault building lljava/java/util/AbstractMap.java I have experinced odd problems which seemed to be related to svn not being quite magic enoguh to keep what was on my disc in sync with the repository (I think). Whatever the explanation nuking my coy and obtain a frsh one form stratch made the problem vanish. The box that had sufficient horse power to sensibly build gcc has died, so I will wait for a (faster) replacement before I try again. I will want a 64 bit compiler in any case, and probably a 32 bit cross compiler. I put cross in quotes because I will be getting an AMD Athlon X2 which actually can run 32 bit binaries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33114
[Bug libgcj/33114] jc1 segault building lljava/java/util/AbstractMap.java
--- Comment #2 from dps at simpson dot demon dot co dot uk 2007-08-21
21:49 ---
Subject: Re: jc1 segault building
lljava/java/util/AbstractMap.java
No CLASSPATH variable exists in the build environment.
The compiler was confiugred with
../gcc/configure --prefix=/usr --enabled-shared
and the gcc, libjava, etc source tree was in ../gcc. The gcc source itself was
in ../gcc/gcc.
The make command was make bootstrap or nice make bootstrap. Using a
completely clean directory did not change anything.
The segfault is repeatable on at least my system. The jc1 instance was
extracted from the last compile command with --verbose and -save-temps. A lot
of versions of the source from svn are all affected. (I hace been sitting on
this misbehaviour for at least a week.)
If you add
if (n_initialised==0)
{
fprintf(stderr, fini_ssa_operands called with n_initialsised==0\n);
return;
}
at the top of fini_ssa_operands then I get a pile of those messages after the
complains about non extant methods and no segfault. Instead gcj returns
correctly with exit status 1. Arguably this not ideal but IMHO a distinct
improvement.
I took this as evidence that no input whatsoever was meant to lead to
fini_ssa_operands calls when n_initialised is 0. (Exactly how far the code has
proceeded from the java frontend to the backend before the segfault strikes I
have not determined.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33114
[Bug tree-optimization/33114] New: jc1 segault building lljava/java/util/AbstractMap.java
Using gcc 4.3.0 20070818 (experimental) has tI hit the following problem building libjava libtool: compile: /home/dps/src/egcs/gcc-i686/gcc/gcj -B/home/dps/src/egcs/gcc-i686/i686-pc-linux-gnu/libjava/ -B/home/dps/src/egcs/gcc-i686/gcc/ -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../gcc/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -fsource-filename=/home/dps/src/egcs/gcc-i686/i686-pc-linux-gnu/libjava/classpath/lib/classes -MT java/util.lo -MD -MP -MF java/util.deps @java/util.list -fPIC -o java/.libs/util.o ../../../../../gcc/libjava/classpath/java/util/AbstractMap.java: In class 'java.util.AbstractMap$2$1': ../../../../../gcc/libjava/classpath/java/util/AbstractMap.java: In constructor '(java.util.AbstractMap$2)': ../../../../../gcc/libjava/classpath/java/util/AbstractMap.java:604: error: class 'java.util.AbstractMap$2' has no method named 'access$0' matching signature '(Ljava/util/AbstractMap$2;)Ljava/util/AbstractMap;' ../../../../../gcc/libjava/classpath/java/util/AbstractMap.java: In class 'java.util.AbstractMap$3': ../../../../../gcc/libjava/classpath/java/util/AbstractMap.java: In method 'access$0(java.util.AbstractMap$3)': ../../../../../gcc/libjava/classpath/java/util/AbstractMap.java:0: internal compiler error: Segmentation fault Apprerently the reason for this that fini_ssa_operands is called more times than init_ssa_operands. Backtrace of call with n_initialized=0 is (gdb) bt #0 fini_ssa_operands () at ../../gcc/gcc/tree-ssa-operands.c:389 #1 0x08403a40 in delete_tree_ssa () at ../../gcc/gcc/tree-ssa.c:866 #2 0x0832fedc in execute_free_datastructures () at ../../gcc/gcc/tree-optimize.c:215 #3 0x0824b79f in execute_one_pass (pass=0x87c3540) at ../../gcc/gcc/passes.c:1108 #4 0x0824b99f in execute_pass_list (pass=0x87c3540) at ../../gcc/gcc/passes.c:1161 #5 0x0832ffed in tree_rest_of_compilation (fndecl=0xb7c98f80) at ../../gcc/gcc/tree-optimize.c:405 #6 0x084a5cf0 in cgraph_expand_function (node=0xb7454280) at ../../gcc/gcc/cgraphunit.c:1077 #7 0x084a7060 in cgraph_assemble_pending_functions () at ../../gcc/gcc/cgraphunit.c:440 #8 0x084a74ed in cgraph_finalize_function (decl=0xb7c98f80, nested=0 '\0') at ../../gcc/gcc/cgraphunit.c:557 #9 0x08064889 in finish_method (fndecl=0xb7c98f80) at ../../gcc/gcc/java/decl.c:1859 #10 0x08070415 in end_java_method () at ../../gcc/gcc/java/decl.c:1807 #11 0x08095308 in parse_class_file () at ../../gcc/gcc/java/jcf-parse.c:1689 #12 0x08095cf3 in java_parse_file (set_yydebug=0) at ../../gcc/gcc/java/jcf-parse.c:1980 #13 0x082ce838 in toplev_main (argc=34, argv=0xbfdc8ba4) at ../../gcc/gcc/toplev.c:1043 #14 0x080a15bf in main (argc=Cannot access memory at address 0x4 ) at ../../gcc/gcc/main.c:35 n_initialized reaches -4 and then the code segaults on line 1092 of upodate_stmt_operands. Backtrace is #0 0x083c46b3 in update_stmt_operands (stmt=0xb7469c40) at ../../gcc/gcc/tree-ssa-operands.c:1092 #1 0x082d3742 in bsi_insert_after (i=0xbfdc8780, t=0xb7469c40, m=BSI_NEW_STMT) at ../../gcc/gcc/tree-flow-inline.h:368 #2 0x084c83ff in copy_body (id=0xbfdc881c, count=value optimized out, frequency=0, entry_block_map=0xb746b8e8, exit_block_map=0xb746b924) at ../../gcc/gcc/tree-inline.c:811 #3 0x084c9b8d in tree_function_versioning (old_decl=0xb7ca0200, new_decl=0xb7467680, tree_map=0x0, update_clones=1 '\001') at ../../gcc/gcc/tree-inline.c:3445 #4 0x084a6b97 in save_inline_function_body (node=0xb7467380) at ../../gcc/gcc/cgraphunit.c:1626 #5 0x084ac22e in apply_inline () at ../../gcc/gcc/ipa-inline.c:1580 #6 0x0824b79f in execute_one_pass (pass=0x87c4ca0) at ../../gcc/gcc/passes.c:1108 #7 0x0824b99f in execute_pass_list (pass=0x87c4ca0) at ../../gcc/gcc/passes.c:1161 #8 0x0832ffed in tree_rest_of_compilation (fndecl=0xb7ca0200) at ../../gcc/gcc/tree-optimize.c:405 #9 0x084a5cf0 in cgraph_expand_function (node=0xb7467380) at ../../gcc/gcc/cgraphunit.c:1077 #10 0x084a7060 in cgraph_assemble_pending_functions () at ../../gcc/gcc/cgraphunit.c:440 #11 0x084a74ed in cgraph_finalize_function (decl=0xb7ca0200, nested=0 '\0') at ../../gcc/gcc/cgraphunit.c:557 #12 0x08064889 in finish_method (fndecl=0xb7ca0200) at ../../gcc/gcc/java/decl.c:1859 #13 0x08070415 in end_java_method () at ../../gcc/gcc/java/decl.c:1807 #14 0x08095308 in parse_class_file () at ../../gcc/gcc/java/jcf-parse.c:1689 #15 0x08095cf3 in java_parse_file (set_yydebug=0) at ../../gcc/gcc/java/jcf-parse.c:1980 #16 0x082ce838 in toplev_main (argc=34, argv=0xbfdc8ba4) at ../../gcc/gcc/toplev.c:1043 #17 0x080a15bf in main (argc=65715, argv=0x0) at ../../gcc/gcc/main.c:35 -- Summary: jc1 segault building lljava/java/util/AbstractMap.java Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dps at simpson dot demon dot
[Bug c/25487] New: Assertion failure in pointer analysis
The source here generates an asserion failure compiled with anything above -O0.
Changing p+1 to p seems to avoid the bug. The infinite loops are not a feature
of the original code but the uderlying problem appears to be indentical.
screenshot
[EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc --version
gcc (GCC) 4.2.0 20051217 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc --version
gcc (GCC) 4.2.0 20051217 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc -g -O2 -o
/tmp/foo.o
/tmp/foo.c
/tmp/foo.c: In function 'foo':
/tmp/foo.c:32: internal compiler error: in handle_ptr_arith, at
tree-ssa-structalias.c:3188
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
foo.c is the following nonsense
---cut here---
#include stdio.h
typedef struct
{
int foo;
} s_foo;
static void bar(const s_foo *p,
int (*cmp)(const char *, const char *))
{
const char *pd;
int r;
pd=(const char *) (p+1);/* The p+1 is apparently critical */
while (1)
{
r=(*cmp)(pd, 2);
if (r=0)
fputc('-', stdout);
else
fputc('+', stdout);
}
return;
}
void foo(int (*cmp)(const char *, const char *))
{
s_foo a;
while(1)
{
bar(a, cmp);
}
}
---cut here---
--
Summary: Assertion failure in pointer analysis
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dps at simpson dot demon dot co dot uk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25487
[Bug c/25488] New: Assertion failure in pointer analysis
The source here generates an asserion failure compiled with anything above -O0. Changing p+1 to p seems to avoid the bug. The infinite loops are not a feature of the original code but the uderlying problem appears to be indentical. screenshot [EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc --version gcc (GCC) 4.2.0 20051217 (experimental) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc --version gcc (GCC) 4.2.0 20051217 (experimental) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc -g -O2 -o /tmp/foo.o /tmp/foo.c /tmp/foo.c: In function 'foo': /tmp/foo.c:32: internal compiler error: in handle_ptr_arith, at tree-ssa-structalias.c:3188 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: Assertion failure in pointer analysis Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dps at simpson dot demon dot co dot uk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25488
[Bug c/25490] New: Assertion failure in pointer analysis
There is a pointer arithmetic related assersion failure, apparently in the logic attempting to deduce what the pointer might be pointing at. If you compile wiht -O0 or chaneg p+1 to p the bug is apparently bypassed. My screenshot is [EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc --version gcc (GCC) 4.2.0 20051217 (experimental) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:~/duncan/src/foo/wlocal/build/phone/mq$ gcc -g -O2 -o /tmp/foo.o /tmp/foo.c /tmp/foo.c: In function 'foo': /tmp/foo.c:32: internal compiler error: in handle_ptr_arith, at tree-ssa-structalias.c:3188 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: Assertion failure in pointer analysis Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dps at simpson dot demon dot co dot uk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25490
[Bug c/25490] Assertion failure in pointer analysis
--- Comment #2 from dps at simpson dot demon dot co dot uk 2005-12-18 22:43 --- Created an attachment (id=10530) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10530action=view) Example program that tickles the bug (with -On for n=1). The example is based on a real example without the obvious infinite loops and a slightly bugger structure (actually a header for a string which starts at p+1). I doubt it is revelent but the processor is an AMD Athlon(tm) XP 3200+. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25490
