[Bug c++/83993] error: constant not recomputed when ADDR_EXPR changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83993 --- Comment #1 from Falk Hueffner --- /tmp% cat test.cc extern const int table[]; const int* const ptable = &table[0]; int f() { return ptable[0]; }
[Bug c++/83993] New: error: constant not recomputed when ADDR_EXPR changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83993 Bug ID: 83993 Summary: error: constant not recomputed when ADDR_EXPR changed Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: falk at debian dot org Target Milestone: --- /tmp% g++ --version g++ (GCC) 8.0.1 20180119 (experimental) Copyright (C) 2018 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. /tmp% g++ -c test.cc test.cc: In function ‘int f()’: test.cc:3:5: error: constant not recomputed when ADDR_EXPR changed int f() { return ptable[0]; } ^ &table[0] test.cc:3:26: note: in statement int f() { return ptable[0]; } ^ ptable.0_1 = &table[0]; during GIMPLE pass: cfg test.cc:3:5: internal compiler error: verify_gimple failed int f() { return ptable[0]; } ^ 0xebe341 verify_gimple_in_cfg(function*, bool) ../../gcc/tree-cfg.c:5574 0xda714f execute_function_todo ../../gcc/passes.c:1994 0xda7bae execute_todo ../../gcc/passes.c:2048 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug tree-optimization/44483] [4.6 regression] gcc consumes all available memory when optimizing
--- Comment #2 from falk at debian dot org 2010-06-09 19:11 --- Confirmed, seems to be in if-conv. Here's a smaller test case: int ffesum (void) { int ch[4], ii, jj, kk; char asc[32]; for (ii = 0; ii < 4; ii++) { for (jj = 0; jj < 4; jj++) ch[jj] = ii; for (kk = 0; kk < 13; kk++) for (jj = 0; jj < 4; jj += 2) if ((unsigned char) ch[jj] || (unsigned char) ch[jj + 1]) ch[jj]++; for (jj = 0; jj < 4; jj++) asc[4 * jj + ii] = ch[jj]; } return asc[0]; } -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
[Bug middle-end/43997] [4.6 Regression] -finline-small-functions related oops
--- Comment #2 from falk at debian dot org 2010-05-05 22:46 --- Confirmed, here is a smaller testcase: extern inline void add_1(int *dst, const int *src, int n) { if (n) dst[n] = src[n]; } typedef void (*aors_1_t)(int *, const int *, int); aors_1_t fudge(aors_1_t f) { return f; } void check_add_1 (int *dst, const int *src, int n) { fudge(add_1)(dst, src, n); fudge(add_1)(dst, src, n); } -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Summary|-finline-small-functions|[4.6 Regression] -finline- |related oops|small-functions related oops http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43997
[Bug c++/43956] g++: internal compiler error: Segmentation fault with -flto and -g flags
--- Comment #3 from falk at debian dot org 2010-05-01 23:11 --- Confirmed. Here is a test case that gives: mini.cc: In member function uploadMessage: mini.cc:6:49: internal compiler error: tree check: expected class type, have declaration (function_decl) in gen_type_die_with_usage, at dwarf2out.c:18876 struct addMessagePull { virtual ~addMessagePull(); }; void doUploadMessage() { class uploadMessage : public addMessagePull { }; uploadMessage upload; } -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43956
[Bug tree-optimization/43845] [4.4/4.5 Regression] Segfault when using __attribute__((const)), versions 4.4.3 and 4.6
--- Comment #2 from falk at debian dot org 2010-04-22 07:35 --- Confirmed on x86-64, already in 4.3, but not in 4.1. Here is a testcase that gives an SSA verification error on 4.6 instead of segfaulting: typedef int __attribute__ ((const)) (*x264_pixel_cmp_t)(void); typedef struct { x264_pixel_cmp_t ssd; } x264_pixel_function_t; int x264_pixel_ssd_wxh (x264_pixel_function_t *pf, int i_width) { int i_ssd = 0, x; for (x = 0; x < i_width; x++) i_ssd += pf->ssd(); return i_ssd; } % gcc -c -O3 -W -Wall mini.c mini.c: In function x264_pixel_ssd_wxh: mini.c:7:5: error: definition in block 3 does not dominate use in block 5 for SSA_NAME: D.2728_7 in statement: D.2737_15 = D.2728_7 (); mini.c:7:5: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 Known to fail||4.1.3 Known to work||4.3.4 4.4.3 4.5.0 4.6.0 Summary|Segfault when using |[4.4/4.5 Regression] |__attribute__((const)), |Segfault when using |versions 4.4.3 and 4.6 |__attribute__((const)), ||versions 4.4.3 and 4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43845
[Bug tree-optimization/43791] kernel/rtmutex.c:1138:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
--- Comment #8 from falk at debian dot org 2010-04-19 20:25 --- Confirmed with current 4.6 on x86-64, here is a testcase: int owner(); int clear(); static void fixup() { clear(); } inline __attribute__ ((always_inline)) void slowtrylock(void) { if (owner()) fixup(); } void fasttrylock(void (*slowfn)()) { slowfn(); } void trylock(void) { fasttrylock(slowtrylock); } -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|other |tree-optimization Ever Confirmed|0 |1 Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43791
[Bug tree-optimization/43537] [4.3/4.4 Regression] c++ -O2 optimizes away a branch inside a loop (-ftree-vrp maybe)
--- Comment #8 from falk at debian dot org 2010-03-26 15:30 --- This seems to be a problem with the struct hack in QVector. Here is a test case: extern "C" { void *memset(void *s, int c, __SIZE_TYPE__ n); void *malloc(__SIZE_TYPE__ size); int printf(const char *format, ...); void abort(void); } void print(int v) { volatile int x = v; (void) x; } struct QVector { int p[1]; }; int main() { int i; QVector* vect = (QVector*) malloc(1024); memset(vect->p, 0, 1024); for (i = 0; i < 4; i++) { int v = vect->p[i]; if (i >= 3 && i <= 4) return 0; print(v); } abort(); } Using "int p[]" instead of "int p[1]" makes the problem go away and is probably a good workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43537
[Bug c/43534] Extra '+' operator not shown as an error.
--- Comment #2 from falk at debian dot org 2010-03-26 12:28 --- Unary plus is allowed in standard C. Use -Wtraditional to get a warning. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43534
[Bug debug/43370] [4.4/4.5 Regression] ICE gen_type_die_with_usage, at dwarf2out.c:14745
--- Comment #3 from falk at debian dot org 2010-03-14 23:35 --- Confirmed, here is a testcase: int fragile_block(void) { typedef __attribute__ ((aligned (16))) struct { int i; } XmmUint16; return 0; } -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |debug Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.4.1 4.5.0 Summary|ICE gen_type_die_with_usage,|[4.4/4.5 Regression] ICE |at dwarf2out.c:14745|gen_type_die_with_usage, at ||dwarf2out.c:14745 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43370
[Bug tree-optimization/19778] Unnecessary jumps for comparisons
--- Comment #5 from falk at debian dot org 2009-09-29 21:02 --- Of course the optimization would be wrong if the second clause had side effects, but it doesn't and this will frequently be the case. So this is definitely a valid and in my opinion worthwhile optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19778
[Bug bootstrap/39108] LTO fails to bootstrap on Alpha
--- Comment #2 from falk at debian dot org 2009-07-13 14:19 --- It bootstraps now, except that it fails for objc. I'll file a bug report for that later. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39108
[Bug c++/39798] would like flag to disable constructors for built-in types
--- Comment #1 from falk at debian dot org 2009-04-20 15:28 --- Removing the default constructor is a bad idea, since it would break about any available library including the standard lib in subtle ways, and would make g++ pretty much unusable. But apparently this isn't actually what you really want anyway, but actually you want to be able to create STL containers with uninitialized memory. This seems to me a pretty unusual requirement, and it could be achieved by creating a wrapper class for int with empty constructor, so I don't think this justifies language or library changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39798
[Bug c/39748] [4.5 regression] warning "outside bounds of constant string" not suppressed in dead code
--- Comment #2 from falk at debian dot org 2009-04-14 14:47 --- The problem comes from some convoluted code that was apparently substituted for strlen to special-case constant arguments. It boils down to: int f(void) { if (0) return ((const char *) "")[2]; return 0; } (without the cast, no warning is given). -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Known to fail||4.5.0 Known to work||4.4.0 Summary|possible bogus offset |[4.5 regression] warning |warning |"outside bounds of constant ||string" not suppressed in ||dead code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39748
[Bug middle-end/39673] [4.5 regression] internal compiler error: in fold_binary, at fold-const.c:9642
--- Comment #4 from falk at debian dot org 2009-04-07 21:47 --- Here's a test case: unsigned long f1(); int f2(); int store_aff_word(int x) { return (int) (x ? f1() : f2()); } -- falk at debian dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.5.0 Known to work||4.3.1 Summary|internal compiler error: in |[4.5 regression] internal |fold_binary, at fold- |compiler error: in |const.c:9642|fold_binary, at fold- ||const.c:9642 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39673
[Bug c++/39480] generated memcpy causes trouble in assignment
--- Comment #19 from falk at debian dot org 2009-03-18 09:06 --- (In reply to comment #18) > I can't imagine an implementation of memcpy that would break when the two > addresses are the same, it just doesn't work if one is offset but > overlapping. > So the valgrind warning is pedantically correct, but I think it doesn't > indicate a real safety issue. As I mentioned in comment #6, it could go wrong if memcpy uses "cache prefetch with write intent" instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug libstdc++/39480] generated memcpy causes trouble in assignment
--- Comment #6 from falk at debian dot org 2009-03-17 12:10 --- (In reply to comment #1) > calling memcpy with exactly overlapping operands is safe (obviously). It's not safe at all. A memcpy implementation might use a "prefetch with write intent" instruction that allocates a cache line to a memory location without actually fetching it, such as wh64 on Alpha, which is actually being used by glibc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #19 from falk at debian dot org 2009-03-16 10:24 --- (In reply to comment #18) > Well, I've got bad news for you anyway: > it seems that the problem affects gcc-4.3.2 too: > it seems it's reproducible in another app, > however one potentially much harder to debug. > Please read http://bugs.winehq.org/show_bug.cgi?id=17406 > and give some ideas for a test. The fact that -fno-inline helps gives only very little indication that this is actually the same problem. In any case, I don't think there's really anything we can do without a complete test case (that is, a single file with a main() that exits with 0 when everything's fine and 1 otherwise). This is very difficult to do for someone who doesn't know the freeciv codebase. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug tree-optimization/39394] [4.4 regression] ICE in copy_tree_body_r
--- Comment #5 from falk at debian dot org 2009-03-09 10:59 --- Here's a test case: void *p; extern inline void *f1(int n) { asm volatile("" : "=m"(*(struct { char x[n]; }*) p)); } int x; extern inline void f2() { x ? f1(1) : f1(2); } inline void f3() { f2(); } void f4() { f3(); } With trunk #144708, I'm getting: min.c: In function 'f4': min.c:12: internal compiler error: in copy_tree_body_r, at tree-inline.c:1042 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.4.0 Known to work||4.3.1 Summary|gcc 4.4.0 20090306 segfaults|[4.4 regression] ICE in |at argp-help.c in glibc 2.7 |copy_tree_body_r |and 2.9 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39394
[Bug c/39341] Feature request: function attribute to save all used registers
--- Comment #1 from falk at debian dot org 2009-03-02 11:43 --- Why not just use -fcall-saved-reg for the relevant registers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39341
[Bug bootstrap/39108] New: LTO fails to bootstrap on Alpha
when configuring libgcc: configure:2611: /home/falk/lto/build/./gcc/xgcc -B/home/falk/lto/build/./gcc/ -B/usr/local/alphaev68-unknown-linux-gnu/bin/ -B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem /usr/local/alphaev68-unknown-linux-gnu/include -isystem /usr/local/alphaev68-unknown-linux-gnu/sys-include -c -g -O2 -mieee conftest.c >&5 conftest.c:16: internal compiler error: tree check: expected function_decl, have error_mark in get_personality_function, at expr.h:806 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. configure:2614: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "GNU C Runtime Library" | #define PACKAGE_TARNAME "libgcc" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU C Runtime Library 1.0" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } -- Summary: LTO fails to bootstrap on Alpha Product: gcc Version: lto Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org GCC build triplet: alphaev68-linux-gnu GCC host triplet: alphaev68-linux-gnu GCC target triplet: alphaev68-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39108
[Bug tree-optimization/18557] Inefficient code generated by -ftree-vectorize on Alpha
--- Comment #11 from falk at debian dot org 2009-02-03 12:50 --- (In reply to comment #10) > By changing the test to: > > unsigned int p[64]; In this case 8-byte alignment is guaranteed, so no peeling is needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18557
[Bug c/39076] internal compiler error when cross-compiling flac
--- Comment #2 from falk at debian dot org 2009-02-02 19:02 --- No problem with the trunk, but it's still there in the 4.3 branch. Here's a test case. Requires -funroll-loops -Os, no problem with any other -O, or without -funroll-loops, curiously. int f(int x, int y) { int bytes = 4 * x + y; if (bytes == 0) return 0; return bytes + 1; } -- falk at debian dot org changed: What|Removed |Added CC| |falk at debian dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.4 Known to work||4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
[Bug c++/38986] comparing lengths of 2 strings reads through both strings completely
--- Comment #3 from falk at debian dot org 2009-02-01 10:50 --- The main problem is that just replacing the code by the below loop won't necessarily give a speedup. strlen is usually implemented in highly efficient and platform-specific assembly that treats several bytes at a time. I don't think the vectorizer will give equally efficient code for the loop. Also, in normal applications almost all strings are pretty short (and not of very unequal length). Probably the best way to motivate somebody to look into this is if you gave benchmark results that show a noticeable improvement for some real-world application. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38986
[Bug c++/39002] codegen bug?
--- Comment #5 from falk at debian dot org 2009-01-28 14:44 --- (In reply to comment #4) > What I can try is finding the revision which causes the fault. While that would certainly be helpful, it's unlikely that anybody would be willing to debug this without a usable testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug c++/39002] codegen bug?
--- Comment #3 from falk at debian dot org 2009-01-28 14:25 --- We need the preprocessed source of a *complete* (including main) program to be able to reproduce this. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39002
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #1 from falk at debian dot org 2009-01-24 17:48 --- const char *logout_cmd = logout_cmd; actually initializes the variable with its own (uninitialized) value. You can get a warning about this with "-Winit-self". -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug target/36004] alpha doesn't see stores, through other variables, for "struct hack"
--- Comment #3 from falk at debian dot org 2008-05-14 11:08 --- (In reply to comment #2) > Regarding gnat; Can we use this ticket for tracking the problem? No, please file a new bug. Or is this the same as PR 36025? -- falk at debian dot org changed: What|Removed |Added CC| |falk at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36004
[Bug target/36004] alpha doesn't see stores, through other variables, for "struct hack"
--- Comment #1 from falk at debian dot org 2008-05-02 13:55 --- I can reproduce this with 4.1, but not with 4.2.3 or 4.3.1 20080401. So it seems to be fixed. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36004
[Bug rtl-optimization/35388] [4.2 Regression] error compiling dealII SPEC CPU 2006 benchmark
--- Comment #3 from falk at debian dot org 2008-03-24 16:23 --- I can't reproduce this on Alpha Linux with Debian 4.2.3-2. On that system, long double is 16 bytes. What's the length on your system? Also, can you try 4.3? -- falk at debian dot org changed: What|Removed |Added CC| |falk at debian dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35388
[Bug target/22093] Unaligned access to HI values causes unrecognizable insn error
--- Comment #3 from falk at debian dot org 2007-12-23 21:46 --- (In reply to comment #2) > Falk, do you think you could check if this is still an issue? It's very unlikely to be fixed. The fix mentioned seems to be right, but without a big-endian Alpha system to test the patch on I wouldn't want to commit it (big-endian Alpha is a pretty weird configuration, I think the only one is the Cray T3E supercomputer). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22093
[Bug tree-optimization/33804] ICE in vect_transform_stmt, at tree-vect-transform.c:6131 with -ftree-vectorize
--- Comment #8 from falk at debian dot org 2007-10-22 13:47 --- (In reply to comment #7) > Could you please check if the patch in Comment #6 fixes the ICE? Yes, this fixes it. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
[Bug tree-optimization/33804] ICE in vect_transform_stmt, at tree-vect-transform.c:6131 with -ftree-vectorize
--- Comment #4 from falk at debian dot org 2007-10-18 19:26 --- Created an attachment (id=14370) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14370&action=view) Vectorization dump file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
[Bug tree-optimization/33804] ICE in vect_transform_stmt, at tree-vect-transform.c:6131 with -ftree-vectorize
--- Comment #2 from falk at debian dot org 2007-10-18 06:27 --- Whoops. void f(unsigned char *s, unsigned char *d, int n) { int i; for (i = 0; i < n; i += 4) { d[i + 0] += s[i + 0]; d[i + 1] += s[i + 1]; d[i + 2] += s[i + 2]; d[i + 3] += s[i + 3]; } } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
[Bug tree-optimization/33804] New: ICE in vect_transform_stmt, at tree-vect-transform.c:6131 with -ftree-vectorize
[EMAIL PROTECTED]:/tmp% gcc -c -O2 129.c [EMAIL PROTECTED]:/tmp% gcc -c -O2 -ftree-vectorize 129.c 129.c: In function 'add_bytes_c': 129.c:1: internal compiler error: in vect_transform_stmt, at tree-vect-transform.c:6131 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE in vect_transform_stmt, at tree-vect- transform.c:6131 with -ftree-vectorize Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org GCC build triplet: alphaev68-unknown-linux-gnu GCC host triplet: alphaev68-unknown-linux-gnu GCC target triplet: alphaev68-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
[Bug tree-optimization/32540] [4.3 Regression] Exponential time behavior in PRE
--- Comment #5 from falk at debian dot org 2007-09-24 20:18 --- As noted by Edvin Török, the bug is not fixed for the original test case (although it is fixed for the small test case). A small test case that still fails is int f(void); void acceptloop_th(int *t) { int options = 0; if (f()) options |= 0x1 << 0; if (f()) options |= 0x1 << 1; if (f()) options |= 0x1 << 2; if (f()) options |= 0x1 << 3; if (f()) options |= 0x1 << 4; if (f()) options |= 0x1 << 5; if (f()) options |= 0x1 << 6; if (f()) options |= 0x1 << 7; if (f()) options |= 0x1 << 8; if (f()) options |= 0x1 << 9; if (f()) options |= 0x1 << 10; if (f()) options |= 0x1 << 11; if (f()) options |= 0x1 << 12; if (f()) options |= 0x1 << 13; if (f()) options |= 0x1 << 14; if (f()) options |= 0x1 << 15; if (f()) options |= 0x1 << 16; if (f()) options |= 0x1 << 17; if (f()) options |= 0x1 << 18; if (f()) options |= 0x1 << 19; if (f()) options |= 0x1 << 20; if (f()) options |= 0x1 << 21; if (f()) options |= 0x1 << 22; if (f()) options |= 0x1 << 23; if (f()) options |= 0x1 << 24; if (f()) options |= 0x1 << 25; if (f()) options |= 0x1 << 26; if (f()) *t = options; } (the only change is that the last line is conditional). -- falk at debian dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug target/33142] New: wrong code with abs in comparison
[ forwarded from http://bugs.debian.org/429657 ] [EMAIL PROTECTED]:/tmp% cat test.c int abs(int j); void abort(void); __attribute__((noinline)) int lisp_atan2(long dy, long dx) { if (dx <= 0) if (dy > 0) return abs(dx) <= abs(dy); return 0; } int main() { volatile long dy = 63, dx = -77; if (lisp_atan2(dy, dx)) abort(); return 0; } [EMAIL PROTECTED]:/tmp% gcc-4.1 -O1 test.c && ./a.out [EMAIL PROTECTED]:/tmp% gcc-4.1 -O2 test.c && ./a.out zsh: abort ./a.out not reproducible on alpha or amd64, or with 4.2. -- Summary: wrong code with abs in comparison Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org 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=33142
[Bug c++/32400] [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
--- Comment #5 from falk at debian dot org 2007-08-01 20:15 --- Actually, two lines suffice: template static inline void f() { } template<> inline void f<5>() { } This also breaks inkscape. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes
--- Comment #9 from falk at debian dot org 2007-07-26 22:49 --- (In reply to comment #8) > Bug 32747 fixed, so I successfully bootstrapped r126943 (all languages minus > java) with patch from comment #6 on alphaev56-unknown-linux-gnu. > So, are you going to post the patch to gcc-patches? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug middle-end/32856] Invalid optimization in the face of aliasing
--- Comment #9 from falk at debian dot org 2007-07-25 08:24 --- (In reply to comment #8) > You may only access union members through the union, not through other > pointers. Where is this documented? I thought it should be in extend.texi, but I couldn't find it... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32856
[Bug middle-end/32856] Invalid optimization in the face of aliasing
--- Comment #7 from falk at debian dot org 2007-07-23 14:17 --- (In reply to comment #6) > This program demonstrates the problem, it creates different output depending > on > if compiled with or without optimisation. This does not demonstrate the problem, since your code has undefined behavior (already c = ... is undefined). You really need something like the union mentioned earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32856
[Bug middle-end/32856] Invalid optimization in the face of aliasing
--- Comment #5 from falk at debian dot org 2007-07-22 23:19 --- Well, certainly not legal in C, since there you may only access the element of a union last written to. However, in GNU C, other accesses are allowed. -- falk at debian dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32856
[Bug middle-end/32856] Invalid optimization in the face of aliasing
--- Comment #3 from falk at debian dot org 2007-07-22 23:01 --- Can you give an example how n->next->next->prev and n->next might be at the same address? I don't see any legal way to achieve that. And FWIW, DEC C also optimizes like gcc does. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32856
[Bug target/32522] [4.3 Regression] Bootstrap failure on Alpha due to pointer-plus changes
--- Comment #2 from falk at debian dot org 2007-07-05 13:01 --- I tried this patch from Andrew Pinski: Index: gcc/config/alpha/alpha.c === --- gcc/config/alpha/alpha.c(revision 126053) +++ gcc/config/alpha/alpha.c(working copy) @@ -6111,8 +6111,8 @@ valist, offset_field, NULL_TREE); t = make_tree (ptr_type_node, virtual_incoming_args_rtx); - t = build2 (PLUS_EXPR, ptr_type_node, t, - build_int_cst (NULL_TREE, offset)); + t = build2 (POINTER_PLUS_EXPR, ptr_type_node, t, + size_int (offset)); t = build2 (GIMPLE_MODIFY_STMT, TREE_TYPE (base_field), base_field, t); TREE_SIDE_EFFECTS (t) = 1; expand_expr (t, const0_rtx, VOIDmode, EXPAND_NORMAL); @@ -6172,8 +6173,8 @@ } /* Build the final address and force that value into a temporary. */ - addr = build2 (PLUS_EXPR, ptr_type, fold_convert (ptr_type, base), -fold_convert (ptr_type, addend)); + addr = build2 (POINTER_PLUS_EXPR, ptr_type, fold_convert (ptr_type, base), +fold_convert (sizetype, addend)); internal_post = NULL; gimplify_expr (&addr, pre_p, &internal_post, is_gimple_val, fb_rvalue); append_to_statement_list (internal_post, pre_p); which allows bootstrap to continue, but it still fails: checking for alphaev68-unknown-linux-gnu-gcc... /src/gcc-2007.07.05/build/./gcc/xgcc -B/src/gcc-2007.07.05/build/./gcc/ -B/usr/local/alphaev68-unknown-linux-gnu/bin/ -B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem /usr/local/alphaev68-unknown-linux-gnu/include -isystem /usr/local/alphaev68-unknown-linux-gnu/sys-include checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage2-target-libgcc] Error 1 make[2]: Leaving directory `/src/gcc-2007.07.05/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/src/gcc-2007.07.05/build' make: *** [all] Error 2 libgcc/config.log says: configure:2566: checking for suffix of object files configure:2587: /src/gcc-2007.07.05/build/./gcc/xgcc -B/src/gcc-2007.07.05/build/./gcc/ -B/usr/local/alphaev68-unknown-linux-gnu/bin/ -B/usr/loc al/alphaev68-unknown-linux-gnu/lib/ -isystem /usr/local/alphaev68-unknown-linux-gnu/include -isystem /usr/local/alphaev68-unknown-linux-gnu/sys- include -c -g -O2 conftest.c >&5 :0: error: nonnull argument references non-pointer operand (argument 1, operand 1) :0: error: nonnull argument references non-pointer operand (argument 1, operand 1) :0: error: nonnull argument references non-pointer operand (argument 1, operand 1) :0: error: nonnull argument references non-pointer operand (argument 1, operand 1) :0: error: nonnull argument references non-pointer operand (argument 1, operand 1) :0: error: nonnull argument references non-pointer operand (argument 1, operand 1) :0: error: nonnull argument references non-pointer operand (argument 1, operand 1) :0: error: nonnull argument references non-pointer operand (argument 1, operand 1) :0: error: nonnull argument references non-pointer operand (argument 1, operand 1) :0: error: nonnull argument references non-pointer operand (argument 1, operand 1) :0: error: nonnull argument references non-pointer operand (argument 1, operand 1) :0: error: nonnull argument references non-pointer operand (argument 1, operand 1) :0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. configure:2590: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "GNU C Runtime Library" | #define PACKAGE_TARNAME "libgcc" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU C Runtime Library 1.0" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2604: error: cannot compute suffix of object files: cannot compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug tree-optimization/32540] Exponential time behavior in PRE
--- Comment #1 from falk at debian dot org 2007-06-28 20:15 --- Created an attachment (id=13801) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13801&action=view) Original test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug tree-optimization/32540] New: Exponential time behavior in PRE
int f(void); void acceptloop_th(int *t) { int options = 0; if (f()) options |= 0x1 << 0; if (f()) options |= 0x1 << 1; if (f()) options |= 0x1 << 2; if (f()) options |= 0x1 << 3; if (f()) options |= 0x1 << 4; if (f()) options |= 0x1 << 5; if (f()) options |= 0x1 << 6; if (f()) options |= 0x1 << 7; if (f()) options |= 0x1 << 8; if (f()) options |= 0x1 << 9; if (f()) options |= 0x1 << 10; if (f()) options |= 0x1 << 11; if (f()) options |= 0x1 << 12; if (f()) options |= 0x1 << 13; if (f()) options |= 0x1 << 14; if (f()) options |= 0x1 << 15; if (f()) options |= 0x1 << 16; if (f()) options |= 0x1 << 17; if (f()) options |= 0x1 << 18; if (f()) options |= 0x1 << 19; if (f()) options |= 0x1 << 20; if (f()) options |= 0x1 << 21; if (f()) options |= 0x1 << 22; if (f()) options |= 0x1 << 23; if (f()) options |= 0x1 << 24; if (f()) options |= 0x1 << 25; if (f()) options |= 0x1 << 26; *t = options; } takes many minutes to compile with 4.3. No problem with 4.2. Timing report shows PRE, and -fno-tree-pre makes it go really fast. Some timings, where the first number is the number of "if"-lines: 10 gcc -c -O3 mini2.c -DN=$n 0.17s user 0.01s system 97% cpu 0.184 total 11 gcc -c -O3 mini2.c -DN=$n 0.20s user 0.02s system 97% cpu 0.221 total 12 gcc -c -O3 mini2.c -DN=$n 0.28s user 0.01s system 95% cpu 0.306 total 13 gcc -c -O3 mini2.c -DN=$n 0.42s user 0.03s system 97% cpu 0.463 total 14 gcc -c -O3 mini2.c -DN=$n 0.76s user 0.02s system 97% cpu 0.805 total 15 gcc -c -O3 mini2.c -DN=$n 1.52s user 0.03s system 97% cpu 1.604 total 16 gcc -c -O3 mini2.c -DN=$n 3.24s user 0.07s system 97% cpu 3.396 total 17 gcc -c -O3 mini2.c -DN=$n 7.00s user 0.12s system 97% cpu 7.314 total 18 gcc -c -O3 mini2.c -DN=$n 15.01s user 0.21s system 96% cpu 15.748 total 19 gcc -c -O3 mini2.c -DN=$n 33.21s user 0.49s system 94% cpu 35.600 total 20 gcc -c -O3 mini2.c -DN=$n 76.29s user 0.87s system 96% cpu 1:19.94 total I'll also attach the original source this test case was extracted from. -- Summary: Exponential time behavior in PRE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[Bug bootstrap/32522] New: Bootstrap failure on Alpha due to pointer-plus changes
src/gcc-2007.06.27/build/./gcc/xgcc -B/src/gcc-2007.06.27/build/./gcc/ -B/usr/local/alphaev68-unknown-linux-gnu/bin/ -B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem /usr/local/alphaev68-unknown-linux-gnu/include -isystem /usr/local/alphaev68-unknown-linux-gnu/sys-include -g -fkeep-inline-functions -O2 -O2 -g -O2 -mieee -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mieee -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -o _gcov_execl.o -MT _gcov_execl.o -MD -MP -MF _gcov_execl.dep -DL_gcov_execl -c ../../../libgcc/../gcc/libgcov.c ../../../libgcc/../gcc/libgcov.c: In function '__gcov_execl': ../../../libgcc/../gcc/libgcov.c:838: internal compiler error: in build2_stat, at tree.c:3074 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [_gcov_execl.o] Error 1 make[3]: Leaving directory `/src/gcc-2007.06.27/build/alphaev68-unknown-linux-gnu/libgcc' This happens as soon as varargs are used: $ cat test.c void f(int x, ...) { __builtin_va_list ap; __builtin_va_start(ap, x); } $ /src/gcc-2007.06.27/build/gcc/xgcc -B/src/gcc-2007.06.27/build/gcc/ -c test.c test.c: In function 'f': test.c:3: internal compiler error: in build2_stat, at tree.c:3074 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Apparently, the Alpha backend needs to adapt to the pointer-plus changes. -- Summary: Bootstrap failure on Alpha due to pointer-plus changes Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org GCC build triplet: alphaev68-unknown-linux-gnu GCC host triplet: alphaev68-unknown-linux-gnu GCC target triplet: alphaev68-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
[Bug middle-end/32399] [4.3 Regression] ICE in build2_stat, at tree.c:3074
--- Comment #7 from falk at debian dot org 2007-06-27 15:37 --- This makes bootstrap fail on alphaev68-linux: /src/gcc-2007.06.27/build/./gcc/xgcc -B/src/gcc-2007.06.27/build/./gcc/ -B/usr/local/alphaev68-unknown-linux-gnu/bin/ -B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem /usr/local/alphaev68-unknown-linux-gnu/include -isystem /usr/local/alphaev68-unknown-linux-gnu/sys-include -g -fkeep-inline-functions -O2 -O2 -g -O2 -mieee -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mieee -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -o _gcov_execl.o -MT _gcov_execl.o -MD -MP -MF _gcov_execl.dep -DL_gcov_execl -c ../../../libgcc/../gcc/libgcov.c ../../../libgcc/../gcc/libgcov.c: In function '__gcov_execl': ../../../libgcc/../gcc/libgcov.c:838: internal compiler error: in build2_stat, at tree.c:3074 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [_gcov_execl.o] Error 1 make[3]: Leaving directory `/src/gcc-2007.06.27/build/alphaev68-unknown-linux-gnu/libgcc' This happens as soon as varargs are used: $ cat test.c void f(int x, ...) { __builtin_va_list ap; __builtin_va_start(ap, x); } $ /src/gcc-2007.06.27/build/gcc/xgcc -B/src/gcc-2007.06.27/build/gcc/ -c test.c test.c: In function 'f': test.c:3: internal compiler error: in build2_stat, at tree.c:3074 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[Bug tree-optimization/31911] Short function (md4) takes very long to compile
--- Comment #1 from falk at debian dot org 2007-05-13 13:49 --- Created an attachment (id=13546) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13546&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31911
[Bug tree-optimization/31911] New: Short function (md4) takes very long to compile
The attached code (a md4 function, about 100 lines) takes many minutes (apparently >100) to compile with gcc mainline 4.3 at -O3. At -O2, or with gcc 4.2, it takes below 1 second. 4.3.0 20070411 is OK, too. Memory requirement stays very low. The top of a profile with mainline looks like this: %symbol name 14.8255 iterative_hash_expr 14.5251 bitmap_find_leader 13.8068 phi_translate 7.3317 iterative_hash 6.5265 get_value_handle 5.3315 htab_find_slot_with_hash 5.0914 iterative_hash_pointer 3.8050 iterative_hash_hashval_t 3.4260 bitmap_set_contains_value 2.3798 is_gimple_min_invariant 2.2232 iterative_hash_host_wide_int 2.0325 tree_operand_length 1.8615 translate_vuses_through_block 1.7766 bitmap_bit_p 1.6062 find_leader_in_sets 1.5111 expression_for_id 1.3981 vn_compute 1.2290 tree_operand_length 1.0592 expr_pred_trans_eq -- Summary: Short function (md4) takes very long to compile Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org GCC build triplet: alphaev68-unknown-linux-gnu GCC host triplet: alphaev68-unknown-linux-gnu GCC target triplet: alphaev68-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31911
[Bug rtl-optimization/22392] Huge memory usage and infinite(?) loop with -fno-enforce-eh-specs
--- Comment #4 from falk at debian dot org 2007-04-28 14:21 --- Not a problem in 4.1 anymore, so let's close it. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22392
[Bug bootstrap/29889] New: jc1 segfaults while bootstrap
[...] /src/gcc-2006.11.16/build/gcc/gcj -B/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava/ -B/src/gcc-2006.11.16/build/gcc/ -mieee -fclasspath= -fbootclasspath=/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -fjni -findirect-dispatch -fno-indirect-classes -c @gnu-CORBA.list -fPIC -o .libs/gnu-CORBA.o gnu/CORBA/CDR/gnuRuntime.java: In class 'gnu.CORBA.CDR.gnuRuntime$Redirection': gnu/CORBA/CDR/gnuRuntime.java: In method 'gnu.CORBA.CDR.gnuRuntime$Redirection.toString()': gnu/CORBA/CDR/gnuRuntime.java:95: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [gnu-CORBA.lo] Error 1 make[3]: Leaving directory `/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/src/gcc-2006.11.16/build' make: *** [bootstrap] Error 2 [EMAIL PROTECTED]:/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava% gdb ../../gcc/jc1 GNU gdb 6.5-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alpha-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r /tmp/cckTVEkLjx -fhash-synchronization -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -mieee -fkeep-inline-functions -quiet -dumpbase ccWKKQvWjx -mieee -mcpu=ev67 -auxbase-strip .libs/gnu-CORBA.o -g -O2 -Wno-deprecated -version -ffilelist-file -fclasspath= -fbootclasspath=/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava/classpath/lib -fencoding=UTF-8 -fbootstrap-classes -fjni -findirect-dispatch -fno-indirect-classes -fPIC -o /tmp/ccQxnArK.s Starting program: /src/gcc-2006.11.16/build/gcc/jc1 /tmp/cckTVEkLjx -fhash-synchronization -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -mieee -fkeep-inline-functions -quiet -dumpbase ccWKKQvWjx -mieee -mcpu=ev67 -auxbase-strip .libs/gnu-CORBA.o -g -O2 -Wno-deprecated -version -ffilelist-file -fclasspath= -fbootclasspath=/src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava/classpath/lib -fencoding=UTF-8 -fbootstrap-classes -fjni -findirect-dispatch -fno-indirect-classes -fPIC -o /tmp/ccQxnArK.s GNU Java version 4.3.0 20061116 (experimental) (alphaev68-unknown-linux-gnu) compiled by GNU C version 4.3.0 20061116 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Class path starts here: ./ /src/gcc-2006.11.16/build/alphaev68-unknown-linux-gnu/libjava/classpath/lib/ (system) Program received signal SIGSEGV, Segmentation fault. add_type_assertion (class=, assertion_code=, op1=0x2473a20, op2=) at ../../gcc/java/expr.c:477 477 **(type_assertion **)as_pp = as; (gdb) bt #0 add_type_assertion (class=, assertion_code=, op1=0x2473a20, op2=) at ../../gcc/java/expr.c:477 #1 0x0001200893ac in vfy_is_assignable_from (target=0x1, source=0x18) at ../../gcc/java/verify-glue.c:246 #2 0x00012008af50 in types_compatible (t=, k=) at ../../gcc/java/verify-impl.c:376 #3 0x00012008b3a0 in vfy_pop_type_t (match={key = reference_type, klass = 0x1207d2f90, pc = -2}) at ../../gcc/java/verify-impl.c:1172 #4 0x00012008d1a4 in verify_instructions () at ../../gcc/java/verify-impl.c:2913 #5 0x00012008e9ec in verify_method (meth=0x11ffed210) at ../../gcc/java/verify-impl.c:3305 #6 0x000120088634 in verify_jvm_instructions_new (jcf=0x201eac8, byte_ops=0x1206cf50c "»", length=20) at ../../gcc/java/verify-glue.c:507 #7 0x00012007eca4 in expand_byte_code (jcf=0x201eac8, method=) at ../../gcc/java/expr.c:3094 #8 0x000120091564 in parse_class_file () at ../../gcc/java/jcf-parse.c:955 #9 0x000120095d2c in java_parse_file (set_yydebug=) at ../../gcc/java/jcf-parse.c:1310 #10 0x00012032a030 in toplev_main (argc=, argv=) at ../../gcc/toplev.c:1033 #11 0x0001200ad228 in main (argc=8609912, argv=0xafafafafafafafaf) at ../../gcc/main.c:35 (gdb) -- Summary: jc1 segfaults while bootstrap Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org GCC build triplet: alphaev68-unknown-linux-gnu G
[Bug target/29686] [4.1 Regression] ICE when building the kernel on ARM
--- Comment #3 from falk at debian dot org 2006-11-02 13:40 --- Confirmed with a native 4.1.2 20061020. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29686
[Bug c/29687] internal compiler error in push_reload, at reload.c:1315 building liboil-0.3.9
--- Comment #2 from falk at debian dot org 2006-11-02 13:36 --- Please attach the .i file as obtained by adding -save-temps. Also, please try a newer gcc version, the 3.3 branch is dead. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29687
[Bug target/27891] [4.0/4.1 regression] ICE in tree_split_edge, at tree-cfg.c:3107
--- Comment #5 from falk at debian dot org 2006-10-29 09:57 --- Zdenek, do you think this patch (or another fix) can be backported to 4.1? http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01259.html -- falk at debian dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27891
[Bug middle-end/29631] [4.1 regression] Incorrect zero extension of signed short IV
--- Comment #2 from falk at debian dot org 2006-10-28 23:13 --- (In reply to comment #1) > What happens if you try -O2 -fno-loop-optimize? No crash then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29631
[Bug tree-optimization/29631] New: [4.1 regression] Incorrect zero extension of signed short IV
This is extracted from gnushogi (http://bugs.debian.org/393075). [EMAIL PROTECTED]:~% cat bug.c const signed char nunmap[] = { 17, -1, 1 }; __attribute__((noinline)) void ff(int i) { asm volatile(""); } __attribute__((noinline)) void f(short delta) { short p0 = 2, s; for (s = 0; s < 2; s++) { p0 += delta; ff(s); if (nunmap[p0] == 17) asm volatile("# nop"); } } int main() { f(-1); return 0; } [EMAIL PROTECTED]:~% gcc-3.4 -O2 bug.c && ./a.out [EMAIL PROTECTED]:~% gcc-4.2 -O2 bug.c && ./a.out [EMAIL PROTECTED]:~% gcc-4.1 -O2 bug.c && ./a.out zsh: segmentation fault (core dumped) ./a.out Reason seems to be that delta is zero extended, not sign extended: $f..ng: lda $30,-32($30) ldah $1,nunmap($29) !gprelhigh lda $1,nunmap($1) !gprellow stq $9,8($30) stq $10,16($30) mov $31,$9 stq $11,24($30) lda $10,3($1)# $10 = numap + 3 zapnot $16,3,$11 # $11 = zero extend delta (=65535) stq $26,0($30) .prologue 1 $L4: addq $10,$11,$10 # $10 += $11 addl $31,$9,$16 bsr $26,ff !samegp ldq_u $1,-1($10) # access numap[65537] -> SEGV extqh $1,$10,$1 sra $1,56,$1 cmpeq $1,17,$1 bne $1,$L12 $L5: lda $9,1($9) cmpeq $9,2,$1 beq $1,$L4 ldq $26,0($30) ldq $9,8($30) ldq $10,16($30) ldq $11,24($30) lda $30,32($30) ret $31,($26),1 .align 4 $L12: .setmacro # nop .setnomacro br $31,$L5 -- Summary: [4.1 regression] Incorrect zero extension of signed short IV Product: gcc Version: 4.1.2 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org GCC build triplet: alpha-linux-gnu GCC host triplet: alpha-linux-gnu GCC target triplet: alpha-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29631
[Bug target/27891] [4.0/4.1 regression] ICE in tree_split_edge, at tree-cfg.c:3107
--- Comment #3 from falk at debian dot org 2006-10-22 12:50 --- This bug is still there in 4.1, but not in mainline. Janis, can you perhaps do a regression hunt to see what fixed this and whether it is feasible to backport? -- falk at debian dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27891
[Bug c/29062] unclear diagnostic for declaration after label
--- Comment #5 from falk at debian dot org 2006-10-13 12:52 --- I also think the diagnostics should be improved. -- falk at debian dot org changed: What|Removed |Added Severity|minor |enhancement Status|RESOLVED|UNCONFIRMED GCC host triplet|i486-linux | Keywords||diagnostic Known to fail||4.1.2 4.2.0 Resolution|INVALID | Summary|Parse error after label and |unclear diagnostic for |variable declaration|declaration after label http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29062
[Bug c++/28656] duplicated null argument warning on memcpy()
--- Comment #2 from falk at debian dot org 2006-10-13 12:43 --- >From the standard: [...] n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values. So the warning is justified (but not giving it twice). For the missing warning on the second memcpy, please file a second report since this is a totally different problem (and would require some aliasing analysis to detect). -- falk at debian dot org changed: What|Removed |Added Summary|unhelpful null argument |duplicated null argument |warning on memcpy() |warning on memcpy() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656
[Bug ada/27936] [4.2 Regression] gnatbind fails to link on Tru64 UNIX
--- Comment #9 from falk at debian dot org 2006-10-01 21:50 --- FWIW, the same problem breaks bootstrap on Alpha Linux: http://buildd.debian.org/fetch.php?&pkg=gcc-snapshot&ver=20060922-1&arch=alpha&stamp=1158945554&file=log&as=raw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27936
[Bug rtl-optimization/17264] [hppa] Missing address increment optimization for fp load/stores
--- Comment #1 from falk at debian dot org 2006-09-24 19:52 --- For this test case: void f(double *pds, double *pdd, unsigned long len) { while (len >= 8*sizeof(double)) { register double r1,r2,r3,r4; r1 = *pds++; r2 = *pds++; r3 = *pds++; r4 = *pds++; *pdd++ = r1; *pdd++ = r2; *pdd++ = r3; *pdd++ = r4; } } gcc starting from 4.0 produces this: .L3: fldds -16(%r26),%fr22 fldds -8(%r26),%fr23 fldds 0(%r26),%fr24 fldds 8(%r26),%fr25 ldo 32(%r26),%r26 fstds %fr22,-16(%r25) fstds %fr23,-8(%r25) fstds %fr24,0(%r25) fstds %fr25,8(%r25) b .L3 which I suspect is actually better, since it avoids dependencies between the loads. But I'm not familiar with hppa, can anybody comment? -- falk at debian dot org changed: What|Removed |Added Known to fail||3.4.2 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17264
[Bug bootstrap/25009] Bootstrap: Failure to build doc/gcc.info
--- Comment #11 from falk at debian dot org 2006-09-19 17:38 --- No feedback for a long time, let's just close it. -- falk at debian dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25009
[Bug target/21323] internal compiler error: Segmentation fault
--- Comment #7 from falk at debian dot org 2006-08-25 12:07 --- Can you still reproduce this? As Andrew points out, it is probably fixed... -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21323
[Bug c/28800] Incorrect warning "ISO C forbids an empty source file"
--- Comment #1 from falk at debian dot org 2006-08-22 10:16 --- Correct, the warning should say "ISO C forbids an empty translation unit". -- falk at debian dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28800
[Bug target/28623] [4.1/4.2 regression] ICE in extract_insn, at recog.c:2077 (nrecognizable insn) [alpha]
--- Comment #2 from falk at debian dot org 2006-08-10 21:11 --- Confirmed. This is a smaller test case: int vformat(char *buffer) { return buffer[32767]; } This needs -mcpu=ev45. It is triggered by the synthetization of the 8-bit load by 64-bit loads. ldb v0, x(a0) is done as lda a0,x+1(a0) ldq_u v0,-1(a0) extqh v0,a0,v0 sra v0,56,v0 and if x=32767, this fails. (Incidentally, maybe we should do ldq_u t1,x(a0) lda a0,x+1(a0) extqh t1,a0,t1 sra t1,56,v0 and save one cycle at the cost of one extra register.) -- falk at debian dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28623
[Bug c/28446] GCC accepts invalid loop syntax
--- Comment #2 from falk at debian dot org 2006-07-20 14:53 --- However, gcc chould actually warn about while loops with an empty body where the exit condition has no side effects. This might be slightly difficult, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28446
[Bug debug/26881] [4.1/4.2 Regression] internal compiler error in dwarf2out_finish
--- Comment #13 from falk at debian dot org 2006-07-14 12:26 --- *** Bug 28379 has been marked as a duplicate of this bug. *** -- falk at debian dot org changed: What|Removed |Added CC||stephan at s11n dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
[Bug c/28379] internal compiler error with demo code
--- Comment #2 from falk at debian dot org 2006-07-14 12:26 --- This is a duplicate of PR 26881. *** This bug has been marked as a duplicate of 26881 *** -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28379
[Bug target/28376] [4.1 Regression] ICE when building opensp with -O3 on alpha
--- Comment #3 from falk at debian dot org 2006-07-14 08:08 --- This simplified test case ICEs already at -O: static const long unsigned sizes[] = { 4, 8 }; static long unsigned maxSize(const long unsigned *v) { unsigned long max = 0; unsigned long i = 0; for (; i < 2; i++) if (v[i] > max) max = v[i]; return max; } unsigned long a = maxSize(sizes); 00.expand already contains the unfolded leu. I suppose this is not valid RTL? 4.2 does not exhibit this bug. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28376
[Bug regression/28373] C code gives "unaligned access"
--- Comment #1 from falk at debian dot org 2006-07-13 20:58 --- The conversion from int* to aa* is only defined if the pointer is correctly aligned. Even if it was correctly aligned, dereferencing this pointer is undefined behavior (see -Wstrict-aliasing documentation). So this is not a gcc bug. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28373
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation
--- Comment #10 from falk at debian dot org 2006-07-08 07:24 --- I see the same on alphaev68-linux-gnu. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Summary|[4.2 Regression] ICE during |[4.2 Regression] ICE during |extc++.h pch generation on |extc++.h pch generation |Tru64 UNIX V5.1B| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #3 from falk at debian dot org 2006-07-06 20:14 --- (In reply to comment #2) > Even if I add directly to extc++.h (a complete hack), the > compilation errors about iconv_t missing are gone, but the ICE remains, > even at -O0. Can you give the .ii for that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug c/28195] << (shift operator) does rotate operation
--- Comment #1 from falk at debian dot org 2006-06-28 17:57 --- Shifting by an amount larger than the size of a type is undefined behavior, so anything might happen. Gcc even warns about this. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28195
[Bug c/28038] Double to char conversion fails at 32769.0
--- Comment #1 from falk at debian dot org 2006-06-15 10:16 --- If the value of the integral part cannot be represented by the integer type, the behavior is undefined. So this is not a bug. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC target triplet| Pentium III (Coppermine) |Pentium III (Coppermine) Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28038
[Bug c++/28015] Nonspecific error messages
-- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28015
[Bug c/8268] no compile time array index checking
--- Comment #39 from falk at debian dot org 2006-06-08 15:02 --- I'm not actually working on this at the moment -- falk at debian dot org changed: What|Removed |Added AssignedTo|falk at debian dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug target/27907] [4.2 regression] ICE in expand_simple_unop, at optabs.c:2307
--- Comment #1 from falk at debian dot org 2006-06-07 08:12 --- Confirmed with 4.2.0 20060606. Cleaned up test case: struct fann_neuron { double value; } __attribute__ ((packed)); void fann_run (struct fann_neuron **last_neuron) { while (1) (*last_neuron)->value = 1; } The same ICE occurs in the ufraw package, test case: void f(double); void SaveNikonDataFile(void) { while (1) { union { double d; unsigned char b[8]; } dat1, dat2; dat1.d = 1; dat2.d = 1; dat2.b[7] = dat1.b[0]; f(dat2.d); } } This one occurs only with -ffast-math. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27907
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #8 from falk at debian dot org 2006-06-06 21:04 --- (In reply to comment #7) > PR 23971 is closed as fixed, I don't know if alpha is having this problem > anymore or not. It takes 3.39s now, which while much faster than it used to be is still ridiculously slow (with 1 as constant, it takes 0.06s). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug target/27891] [4.0/4.1 regression] ICE in tree_split_edge, at tree-cfg.c:3107
--- Comment #2 from falk at debian dot org 2006-06-04 12:51 --- Here is a cleaned-up testcase: int firstkey(); void DBM_error(int); void domisc() { int i = 0; try { try { firstkey(); while (1) { i++; firstkey(); } } catch (int) { ; } DBM_error(i); } catch (int) { ; } } I have no idea why this would happen only on Alpha, it seems unlikely it's actually a target bug... -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.0.3 4.1.0 Known to work||3.4.6 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27891
[Bug target/27571] [4.2 regression] alpha: ICE in get_attr_usegp, at config/alpha/alpha.md:171
--- Comment #6 from falk at debian dot org 2006-05-26 12:30 --- Fixed. -- falk at debian dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27571
[Bug c/27744] Optimized code gives incorrect result
--- Comment #1 from falk at debian dot org 2006-05-23 19:40 --- This code accesses v, which is of type void*, via an lvalue of type int. This is not allowed by C aliasing rules. Use -fno-strict-aliasing or a union to express this operation. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27744
[Bug target/27082] segfault with virtual class and visibility ("hidden")
--- Comment #8 from falk at debian dot org 2006-05-21 16:34 --- (In reply to comment #7) > This is interesting, I cannot reproduce this with a cross compiler to > alphaev68-unknown-linux-gnu from powerpc-darwin. Hrm :-(. Can anybody try a cross-compiler on i386 with valgrind? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
[Bug target/27571] [4.2 regression] alpha: ICE in get_attr_usegp, at config/alpha/alpha.md:171
--- Comment #4 from falk at debian dot org 2006-05-18 15:47 --- I did a regression test, I'll submit the patch tomorrow (I hope). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27571
[Bug c/27628] Incorrect memory access type used used in accessing bitfields
--- Comment #1 from falk at debian dot org 2006-05-16 12:40 --- There is no guarantee that this happens, and it would suppress many useful optimizations. However, if you mark the fields as volatile, the ARM ABI guarantees that the access will be in the specified width (and after PR 23623 has been fixed, gcc should follow this). -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27628
[Bug tree-optimization/27504] New: x && (x & y) not optimized to x & y
Example: [EMAIL PROTECTED]:/tmp% cat test.c int f(int x) { return x && (x & 0x55); } [EMAIL PROTECTED]:/tmp% gcc -c -O3 test.c && objdump -d test.o : 0: 00 04 ff 47 clr v0 4: 02 00 00 e6 beq a0,10 8: 01 b0 0a 46 and a0,0x55,t0 c: a0 03 e1 43 cmpult zero,t0,v0 10: 01 80 fa 6b ret -- Summary: x && (x & y) not optimized to x & y Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27504
[Bug tree-optimization/27469] New: zero extension not eliminated
unsigned parity(unsigned x) { x ^= x >> 16; x ^= x >> 8; x ^= x >> 4; x &= 0xf; return (0x6996 >> x) & 1; } gcc 4.2.0 20060506 produces: extwl a0,0x2,t2 lda v0,27030 xor t2,a0,t2 zapnot t2,0xf,t1 # redundant zero-extension srl t1,0x8,t1 xor t1,t2,t1 zapnot t1,0xf,t0 # redundant zero-extension srl t0,0x4,t0 xor t0,t1,t0 and t0,0xf,t0 sra v0,t0,v0 and v0,0x1,v0 -fsee doesn't change anything here. -- Summary: zero extension not eliminated Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org GCC build triplet: alphaev68-unknown-linux-gnu GCC host triplet: alphaev68-unknown-linux-gnu GCC target triplet: alphaev68-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27469
[Bug tree-optimization/27468] New: sign-extending Alpha instructions not exploited
The sign-extending Alpha instructions like addl are sometimes not used. I don't know whether the SEE pass is supposed to affect this, or whether it is something a combiner pass should do... #include /* gcc 4.2.0 20060506: negqa0,v0 cmovge a0,a0,v0 sextl v0,v0 optimal: negla0,v0 cmovge a0,a0,v0 */ int f5(int x) { return abs(x); } /* gcc 4.2.0 20060506: s4addq a0,a0,v0 s4addq v0,v0,v0 s8addq v0,a0,v0 s8addq v0,a0,v0 # sextl v0,v0# can be combined to s8addl v0,a0,v0 */ int64_t f23(int16_t x) { return 1609 * x; } /* gcc 4.2.0 20060506: ldaht0,-32768 xor a0,t0,v0 addqv0,t0,v0 # sextl v0,v0# can be combined to addlv0,t0,v0 */ unsigned f49(unsigned val) { return (val ^ 0x8000) - 0x8000; } -- Summary: sign-extending Alpha instructions not exploited Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org GCC build triplet: alphaev68-unknown-linux-gnu GCC host triplet: alphaev68-unknown-linux-gnu GCC target triplet: alphaev68-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27468
[Bug tree-optimization/27467] New: -fsee introduces spurious movs
[EMAIL PROTECTED]:~/ctest% cat see.c int f37(int t, int seg) { if (seg) t = (t + t + 1 + 32) << (seg + 2); else t = (t + t + 1 ) << 3; return t; } [EMAIL PROTECTED]:~/ctest% gcc -c -O3 -fno-see see.c && objdump -dr see.o >! no-see.s && gcc -c -O3 -fsee see.c && objdump -dr see.o >! see.s && diff -u10 no-see.s see.s --- no-see.s2006-05-07 10:49:20.0 +0200 +++ see.s 2006-05-07 10:49:20.0 +0200 @@ -2,17 +2,17 @@ see.o: file format elf64-alpha Disassembly of section .text: : 0: 01 04 10 42 addqa0,a0,t0 4: 02 00 51 20 lda t1,2(a1) 8: 50 16 21 40 s8addq t0,0x8,a0 c: 21 00 21 20 lda t0,33(t0) 10: 21 07 22 48 sll t0,t1,t0 - 14: 00 00 f0 43 sextl a0,v0 + 14: 00 04 f0 47 mov a0,v0 18: 01 00 20 e6 beq a1,20 - 1c: 00 00 e1 43 sextl t0,v0 - 20: 01 80 fa 6b ret - 24: 00 00 fe 2f unop + 1c: 00 04 e1 47 mov t0,v0 + 20: 00 00 e0 43 sextl v0,v0 + 24: 01 80 fa 6b ret 28: 1f 04 ff 47 nop 2c: 00 00 fe 2f unop It looks like SEE correctly recognized that the sign extension after the shift has to be done only once. However, it also introduces two spurious movs. -- Summary: -fsee introduces spurious movs Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org GCC build triplet: alphaev68-unknown-linux-gnu GCC host triplet: alphaev68-unknown-linux-gnu GCC target triplet: alphaev68-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27467
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #15 from falk at debian dot org 2006-05-01 20:55 --- (In reply to comment #12) > Subject: Re: goto crossing P.O.D. initialization > > "falk at debian dot org" <[EMAIL PROTECTED]> writes: > > | I think this is a valid request. While random language extensions aren't > | useful, > | compatibility with C99 is. Maybe somebody else can comment on this... > > You have to be more precise about what you mean by C99 compatibility. I have trouble seeing what might be unclear about this term. I mean that code that is valid C99 is accepted in C++ unless there is a good reason not to. just like most of C89 is accepted in C++ unless there is a good reason not to. > My take on this goto stuff, if it is not valid C++, it is valid C++. That logically implies that everything valid C++, which might be overdoing it a bit ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug libstdc++/17373] std::set::erase(const_iterator) doesn't output error on compilation
--- Comment #5 from falk at debian dot org 2006-04-25 13:20 --- (In reply to comment #4) > The standard doesn't mention set::erase with "iterator" argument, only with > "const_iterator". erm. the other way round, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
[Bug libstdc++/17373] std::set::erase(const_iterator) doesn't output error on compilation
--- Comment #4 from falk at debian dot org 2006-04-25 13:19 --- The standard doesn't mention set::erase with "iterator" argument, only with "const_iterator". Maybe it is legal for g++ to allow it anyway (even if I cannot find anything in the standard allowing it at the moment), but other compilers don't, so it is a rather useless extension. So I'll reopen this bug. -- falk at debian dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
[Bug c++/27306] while and (type *&)variable++ causes never ending loop
--- Comment #2 from falk at debian dot org 2006-04-25 12:19 --- It's a valid C++ fragment. However, this code accesses "ptr", which is of type void*, via an lvalue of type U16*. This is undefined behavior, so there is no gcc bug here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27306
[Bug c/27273] [4.2 regression] tree check fail for legal code
--- Comment #2 from falk at debian dot org 2006-04-23 19:34 --- Confirmed. Test case: unsigned char rx_async(unsigned char p) { return p & 512; } -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.2.0 Known to work||4.0.3 4.1.0 Summary|tree check fail for legal |[4.2 regression] tree check |code|fail for legal code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27273
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #7 from falk at debian dot org 2006-04-23 19:05 --- I think this is a valid request. While random language extensions aren't useful, compatibility with C99 is. Maybe somebody else can comment on this... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug middle-end/26729] [4.0/4.1/4.2 regression] bad bitops folding
--- Comment #15 from falk at debian dot org 2006-04-19 14:20 --- Roger's patch http://gcc.gnu.org/ml/gcc/2006-04/msg8.html fixes this. I don't know about the status of this patch, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug c/27153] function result is dereferenced error
--- Comment #12 from falk at debian dot org 2006-04-18 12:37 --- (In reply to comment #11) > No, this testcase is unspecified, not undefined. There are intervening > sequence points at the start and end of each call to function OK. > However, the evaluation of the > arguments to printf may overlap and the order is unspecified, so there are > many possible outputs from the program (but "3 2 1" and "3 1 1", for > example, are not possible). I don't understand why is "3 2 1" is not possible. How about "1 1 1"? Is this a bug in gcc after all? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27153
[Bug c/27153] function result is dereferenced error
--- Comment #10 from falk at debian dot org 2006-04-18 06:27 --- Uhm, this has nothing to do at all with evaluation order. Evaluation order of arguments is unspecified (not undefined, which wouldn't make a lot of sense), but that is in fact irrelevant here, it could lead to, say, 3 1 2, but not 1 1 1. The actual problem is that val is modified more than once without an intervening sequence point, which makes the behavior undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27153
[Bug rtl-optimization/27114] [4.1/4.2 Regression] Bug under optimization. (cast to reference)
--- Comment #2 from falk at debian dot org 2006-04-11 09:40 --- It seems to me that t.p, which is of type char*, is accessed via an lvalue of type long. So this is undefined behavior. Or am I missing something? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27114
[Bug c++/27083] New: [4.1,4.2 regression] bit-field value not narrowed
[EMAIL PROTECTED]:/tmp% cat test.c #ifdef __cplusplus extern "C" #endif void abort(void); __attribute__((noinline)) unsigned long f(const unsigned long x) { struct { unsigned long x : 1; } s; s.x = x; return s.x; } int main() { if (f(3) != 1) abort(); } [EMAIL PROTECTED]:/tmp% gcc test.c && ./a.out [EMAIL PROTECTED]:/tmp% g++ test.c && ./a.out [EMAIL PROTECTED]:/tmp% g++ -O test.c && ./a.out zsh: abort (core dumped) ./a.out not a problem with 4.0 or earlier -- Summary: [4.1,4.2 regression] bit-field value not narrowed Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org GCC build triplet: alphaev68-unknown-linux-gnu GCC host triplet: alphaev68-unknown-linux-gnu GCC target triplet: alphaev68-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27083