[Bug java/21695] ICE when building gnu-xml.lo in libjava directory
--- Additional Comments From marco at technoboredom dot net 2005-06-23 18:47 --- My build crashes on the same location with the same message (The fresh gcj ICEs in DomDOMException.java:171), when I am trying to build a mingw cross on my slackware box. Here is my configuration statement from config.status: /usr/local/src/gcc/source/gcc-4.0.0/configure -v --prefix=/usr/local/gcc/mingw32-4.0.0 --target=i386-pc-mingw32 --en able-nls --enable-libgcj --enable-interpreter --enable-threads=win32 --enable-java-gc=boehm --enable-sjlj-exceptions --w ithout-included-gettext --with-system-zlib --disable-version-specific-runtime-libs --disable-win32-registry --with-gcc-v ersion-trigger=/usr/local/src/gcc/source/gcc-4.0.0/gcc/version.c --enable-languages=c,c++,java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21695
[Bug c/45115] New: attribute((pure)) does not work when returning structs
compiling this with 'gcc -O3 -S x.c'
x.c ---
#define PURE __attribute__((pure))
struct res {int u; };
extern struct res calc_1() PURE;
extern intcalc_2() PURE;
int fun_1()
{
return calc_1().u+calc_1().u;
}
int fun_2()
{
return calc_2()+calc_2();
}
yields code which calls calc_2() *once* in fun_2() but calls calc_1() *twice*
in fun_1(). Obviously, fun_1 misses an optimization.
Tested on gcc 4.4.3 (Ubuntu 10.04), gcc 4.5.0/4.4.4/4.3.5 (MacPorts)
--
Summary: attribute((pure)) does not work when returning structs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marco at technoboredom dot net
GCC host triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45115
[Bug c++/44822] New: Recusive functions optimize in unpredictable ways
$ uname -a
Linux oblomow 2.6.31.12-0.2-desktop #1 SMP PREEMPT 2010-03-16 21:25:39 +0100
x86_64 x86_64 x86_64 GNU/Linux
$ g++-4.5 -v
Using built-in specs.
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/opt/gcc-4.5.0/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5.0/configure --with-mpc=/opt/gcc-4.5.0
--enable-languages=c,c++ --prefix=/opt/gcc-4.5.0 --program-suffix=-4.5
Thread model: posix
gcc version 4.5.0 (GCC)
The following program computes fib(n) with NN identical, mutually recursive
functions.
#include
template
struct F
{
static int f(int n)
{
if (n<2) return n;
return F<(k+1)%N,N>::f(n-2)+F<(k+1)%N,N>::f(n-1);
}
};
int main()
{
printf("NN=%d, res=%d\n",NN,F<0,NN>::f(44));
}
For NN=1 only one function is used, for NN=2 F<0,2>:f(int) calls F<1,2>:f(int)
and vice versa, etc.pp. The running time variance under different values for NN
is **suprising**:
> for x in {1..15} ; do g++-4.5 -O3 -DNN=$x f.cc -o f$x ; time ./f$x ; echo
> "---"; done
NN=1, res=701408733
real0m4.617s
user0m4.606s
sys 0m0.003s
---
NN=2, res=701408733
real0m2.361s
user0m2.358s
sys 0m0.002s
---
NN=3, res=701408733
real0m3.267s
user0m3.264s
sys 0m0.001s
---
NN=4, res=701408733
real0m1.191s
user0m1.183s
sys 0m0.001s
---
NN=5, res=701408733
real0m0.949s
user0m0.946s
sys 0m0.002s
---
NN=6, res=701408733
real0m1.541s
user0m1.540s
sys 0m0.000s
---
NN=7, res=701408733
real0m1.475s
user0m1.459s
sys 0m0.002s
---
NN=8, res=701408733
real0m0.509s
user0m0.499s
sys 0m0.001s
---
NN=9, res=701408733
real0m0.723s
user0m0.720s
sys 0m0.002s
---
NN=10, res=701408733
real0m1.566s
user0m1.558s
sys 0m0.001s
---
NN=11, res=701408733
real0m1.871s
user0m1.868s
sys 0m0.002s
---
NN=12, res=701408733
real0m0.806s
user0m0.803s
sys 0m0.001s
---
NN=13, res=701408733
real0m1.735s
user0m1.735s
sys 0m0.000s
---
NN=14, res=701408733
real0m1.282s
user0m1.281s
sys 0m0.000s
---
NN=15, res=701408733
real0m1.916s
user0m1.906s
sys 0m0.002s
---
The NN=1 case is 9x slower than NN=8, which is again 3x faster than NN=7 and
NN=10, even though it is the same computation in all cases. Great news is, that
the figures themselves are much better than with gcc-4.4, but the variance
bothers me a bit.
--
Summary: Recusive functions optimize in unpredictable ways
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marco at technoboredom dot net
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44822
[Bug c++/44822] Recusive functions optimize in unpredictable ways
--- Comment #2 from marco at technoboredom dot net 2010-07-05 14:46 --- (In reply to comment #1) > recursive inlining is limited to a depth of 8. > > While the testcase may be "interesting", does it have any practical > relevance? Probably. The test case shows that the compiler fails to recognize that f() can be optimzed a *magnitude* better, unless we explicitly "expand" the call graph (NN>1). The stock version (NN==1) of f() is the slowest. > Certainly nobody looked to optimize for these funny > callgraphs. It's still the call graph of f() only that f changes it's name in each call -- F<0,3>::f calls F<1,3>::f calls F<2,3>::f calls F<0,3>::f etc. -- marco at technoboredom dot net changed: What|Removed |Added Component|tree-optimization |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44822
[Bug c++/26696] New: ICE with statement forming unused static member function reference
Testcase is short enough:
struct A
{
static void f() {}
};
int main()
{
A a;
a.f;
}
Produces a segfault on the line where "a.f" occurs. It should instead issue the
warning "statement is a reference, not call, to function A::f". gcc 4.1.0 (at
least the experimental mingw cross compiler I'm using here) seems to be
affected too.
--
Summary: ICE with statement forming unused static member function
reference
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marco at technoboredom dot net
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26696
[Bug c++/26714] New: violation of [class.temporary]/5
Somebody in c.l.c++.m[1] dug out an overlooked clause in 12.2/5
[class.temporary], namely that "A temporary bound to a reference member in a
constructor's ctor-initializer (12.6.2) persists until the constructor exists"
The following piece of code should therefore print:
===
A()
A()
B()
~A()
~A()
main
===
however, all tested versions (gcc-3.3.6, gcc-4.0.3, gcc-4.1.0) print:
==
A()
~A()
A()
~A()
B()
main
==
// begin example
extern "C" int puts(const char*);
struct A
{
A() { puts("A()"); }
~A() { puts("~A()"); }
};
struct B
{
const A &a1;
const A &a2;
B() : a1(A()),a2(A()) { puts("B()"); }
};
int main()
{
B b;
puts("main");
}
// end example
References:
[1] Message-ID:<[EMAIL PROTECTED]>
--
Summary: violation of [class.temporary]/5
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marco at technoboredom dot net
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26714
