[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 = [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]; }
^
[0]
test.cc:3:26: note: in statement
int f() { return ptable[0]; }
^
ptable.0_1 = [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 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 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 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 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 #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++/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/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 #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] 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=14370action=view) Vectorization dump file -- 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:
templateunsigned x static inline void f() { }
template inline void f5() { }
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 #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 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 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
built-in:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
built-in:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
built-in:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
built-in:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
built-in:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
built-in:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
built-in:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
built-in:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
built-in:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
built-in:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
built-in:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
built-in:0: error: nonnull argument references non-pointer operand (argument
1, operand 1)
built-in:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL: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] 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 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=13801action=view) Original test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
[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 URL: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 URL:http://gcc.gnu.org/bugs.html for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399
[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 URL: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 URL: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 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 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=13546action=view) Test case -- 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
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=29889
[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/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 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 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 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 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++/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 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 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-snapshotver=20060922-1arch=alphastamp=1158945554file=logas=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 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 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 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 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 iconv.h 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++/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/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/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
f:
0: 00 04 ff 47 clr v0
4: 02 00 00 e6 beq a0,10 f+0x10
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/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:
f37:
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 f37+0x20
- 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 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 stdlib.h
/* 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/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 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 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 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 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 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 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 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 #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 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 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++/26986] [4.2 Regression] Segfault with iostream code
--- Comment #2 from falk at debian dot org 2006-04-08 08:06 --- I cannot reproduce this anymore with 4.2.0 20060407, so closing. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26986
[Bug target/8883] Alpha: regalloc too eager to use FP regs on EV6
--- Comment #4 from falk at debian dot org 2006-04-08 08:25 --- I don't see this problem anymore in 4.2.0 20060407, so closing. -- falk at debian dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8883
