[Bug fortran/18109] ICE with explicit array of strings
--- Additional Comments From dalej at apple dot com 2005-02-17 01:45 --- Please ignore comment #3, I had the bug number wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18109
[Bug c++/20581] New: Incorrect codegen for exceptions
-- Summary: Incorrect codegen for exceptions Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dalej at apple dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-linux-pc-gnu GCC host triplet: i686-linux-pc-gnu GCC target triplet: i686-linux-pc-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20581
[Bug c++/20581] Incorrect codegen for exceptions
--- Additional Comments From dalej at apple dot com 2005-03-21 21:49
---
The following is a slightly modified version of g++.dg/eh/omit-frame-pointer2.C.
It fails with -O -fomit-frame-pointer -mno-accumulate-outgoing-args -fpic (you
need all flags). Basic problem is that there are 24 bytes on the stack at the
point of
the call to f2, which throws, but the code following the landing pad only pops
12 of
them, so the return from f1 does not pick up the right address. The unwinder
could
in principle adjust SP to compensate, but it doesn't; there seems to be
sufficient info
in the tables to do this, but no such code in the unwinder. I am unsure just
how this
is supposed to work.
// Reduced from PR c++/5246, PR c++/2447
// { dg-options "-O -fomit-frame-pointer" }
// { dg-options "-O -fomit-frame-pointer -mno-accumulate-outgoing-args" {
target i?86-*-* } }
// { dg-do run }
void *sp;
void step (int)
{
sp = __builtin_alloca (0);
}
void f2 (void)
{
step (2);
throw int();
}
void f1 (void)
{
try
{
step (1);
f2 ();
step (-1);
}
catch (int)
{
step (3);
}
}
int main ()
{
f1 ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20581
[Bug c++/20581] Incorrect codegen for exceptions
--- Additional Comments From dalej at apple dot com 2005-03-21 21:54 --- (fails similarly on Darwin x86, if anyone cares) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20581
[Bug middle-end/19650] New: miscompilation of correct code
Following program miscompiles with -O1 on (32 bit) Darwin. Works with -O0.
It appears that RTL generation for
printf (&"cmp.func is %p (expected %p)\n"[0],
comparator_matrixD.2001[0][(intD.2) (D.2150 == 2)],
compare_e_stringD.2019);
is incorrect, but I haven't dug deeply yet. I will be fixing this unless
somebody recognizes it as a dup
#include
#define test(a) ((a) ? 1 : 0)
typedef int (*arg_cmp_func)();
class Item_func
{
public:
enum Functype { UNKNOWN_FUNC, EQ_FUNC, EQUAL_FUNC };
virtual enum Functype functype() const { return UNKNOWN_FUNC; }
};
class Item_bool_func2 : public Item_func
{
public:
virtual enum Functype functype() const { return EQUAL_FUNC; }
};
class Arg_comparator
{
public:
Item_bool_func2 *owner;
arg_cmp_func func;
static arg_cmp_func comparator_matrix[4][2];
int Arg_comparator::set_compare_func(Item_bool_func2 *item, int type)
{
owner = item;
/** problematic line is here /
func = comparator_matrix[type][test(owner->functype() ==
Item_func::EQUAL_FUNC)];
return 0;
}
};
int compare_string() { return 0; }
int compare_e_string() { return 0; }
int compare_real() { return 0; }
int compare_e_real() { return 0; }
int compare_int_signed() { return 0; }
int compare_e_int() { return 0; }
int compare_row() { return 0; }
int compare_e_row() { return 0; }
arg_cmp_func Arg_comparator::comparator_matrix[4][2] =
{{&compare_string, &compare_e_string},
{&compare_real, &compare_e_real},
{&compare_int_signed, &compare_e_int},
{&compare_row,&compare_e_row}};
int main()
{
Arg_comparator cmp;
Item_bool_func2 equal_func;
cmp.set_compare_func(&equal_func, 0);
printf("cmp.func is %p (expected %p)\n", cmp.func, &compare_e_string);
}
--
Summary: miscompilation of correct code
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dalej at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: same
GCC host triplet: powerpc-apple-darwin8.0.0.b3
GCC target triplet: same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19650
[Bug middle-end/19650] [4.0 Regression] miscompilation of correct code
--- Additional Comments From dalej at apple dot com 2005-01-27 01:21 --- OK, thanks, I'll go fix it. I mostly put it in here in case somebody was working on a dup. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dalej at apple dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19650
[Bug middle-end/19650] [4.0 Regression] miscompiling of array acess of (int)(a==2)
--- Additional Comments From dalej at apple dot com 2005-01-31 18:27 --- Fixed by patch above. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19650
[Bug tree-optimization/17884] asm 'volatile' is not honored as documented
--- Additional Comments From dalej at apple dot com 2005-02-02 18:19 --- Actually I adjusted the doc to my satisfaction in this thread: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01048.html I suppose it's OK to close now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17884
[Bug tree-optimization/19910] New: ICE with -ftree-loop-linear
The following gets an ICE with -O3 -ftree-loop-linear:
int x[6][5][4];
int y[6][5][4];
void initx(void)
{
int a,b,c;
int index = 0;
for(a = 5; a >=2; a--)
for (b = (a - 1); b >=1; b--)
for (c = (b - 1); c >=0; c--)
x[a][b][c] = index++;
}
void inity(void)
{
int d,e,f;
int index = 0;
for(d = 5; d >=2; d--)
for (e = (d - 1); e >=1; e--)
for (f = (e - 1); f >=0; f--)
y[d][e][f] = index++;
}
void foo() {
initx();
inity();
}
--
Summary: ICE with -ftree-loop-linear
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dalej at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin8.0.0
GCC host triplet: powerpc-apple-darwin8.0.0
GCC target triplet: powerpc-apple-darwin8.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
[Bug tree-optimization/17884] asm 'volatile' is not honored as documented
--- Additional Comments From dalej at apple dot com 2004-10-12 18:30 --- OK, thanks. From this it appears that the only effect of 'asm volatile' that users can safely rely on is that such an instruction will not be deleted. If this is agreeable to everybody, I will revise the documentation to say that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17884
[Bug rtl-optimization/5738] GCSE missed optimization: common condition instructions
--- Additional Comments From dalej at apple dot com 2004-11-04 23:31 --- It does say that, and I expect cases can be constructed where the comment is true, but it is not completely right. When you replace 2 copies of code with 1 copy you are generally making it smaller. Plus, there is a beneficial interaction with RTL invariant hoisting, as it exposes more invariants when you do hoisting inside a loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5738
[Bug middle-end/25443] -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
--- Comment #4 from dalej at apple dot com 2007-01-12 20:13 --- With pic, the load of the global's address is pulled outside the loop, so the "base" is a register rather than the global. This causes ivopts to represent index*step all in the index field rather than as two separate fields, so the dump looks like MEM[base: &arr_base, index: (int *) iter * 4B] = D.1877; instead of MEM[symbol: arr_base, index: (int *) iter, step: 4B] = D.1877; so the test fails, but the generated code is correct and optimal. I suggest adding -fno-pic to the test, does that look OK? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
[Bug middle-end/25443] -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
--- Comment #6 from dalej at apple dot com 2007-01-13 01:32 --- Stuff in --tool_opts from RUNTESTFLAGS goes before the dg-options on the command line, I just tried it. Is there some other way to do it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
[Bug middle-end/25443] -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
--- Comment #8 from dalej at apple dot com 2007-01-15 23:41 --- You are right, thanks. Test case fixed thus in mainline (to be 4.3). http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01266.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
[Bug middle-end/25443] -fpic/-fPIC failure in gcc.dg/tree-ssa/loop-3.c
--- Comment #9 from dalej at apple dot com 2007-01-15 23:48 --- as per previous comment -- dalej at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25443
