[Bug libstdc++/18414] Performance problem in operator new and operator new[]
--- Additional Comments From giovannibajo at libero dot it 2004-11-10 08:21 --- *** This bug has been marked as a duplicate of 14563 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18414
[Bug target/14563] [3.3/3.4/4.0 Regression] new/delete much slower than malloc/free because of sjlj exceptions
--- Additional Comments From giovannibajo at libero dot it 2004-11-10 08:21 --- Ron, can you please attach your testcase that shows the problem to this PR? This PR is a regression on cygwin because the speed is back with 3.2. -- What|Removed |Added CC||ron_hylton at hotmail dot ||com Severity|normal |critical GCC target triplet||i686-pc-cygwin Known to fail||3.3.3 3.4.2 Known to work||3.2 Summary|new/delete much slower than |[3.3/3.4/4.0 Regression] |malloc/free because of sjlj |new/delete much slower than |exceptions |malloc/free because of sjlj ||exceptions Target Milestone|--- |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563
[Bug target/14563] [3.3/3.4/4.0 Regression] new/delete much slower than malloc/free because of sjlj exceptions
--- Additional Comments From giovannibajo at libero dot it 2004-11-10 08:21 --- *** Bug 18414 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563
[Bug target/14563] [3.3/3.4/4.0 Regression] new/delete much slower than malloc/free because of sjlj exceptions
--- Additional Comments From dannysmith at users dot sourceforge dot net 2004-11-10 09:10 --- No its not a regression. GCC-3.2 built with sjlj shows the same problem. The fast version of GCC-3.2 that OP referenced was a cygming-special that had Dwarf-2 EH enabled. As I indicated ealier, this experiment was dropped because of problems with Win32 API callbacks and DW-2 EH Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Additional Comments From c dot lemmen at fz-juelich dot de 2004-11-10 09:12 --- Let me stress the importance of fixing this bug: it occurs in Basic Linear Algebra Subprograms (BLAS), in program dcabs1.f: double precision function dcabs1(z) double complex z double precision t(2) t=transfer(z,t) dcabs1 = dabs(t(1)) + dabs(t(2)) return end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug middle-end/17520] [4.0 regression] Huge compile time for C code
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-10 10:13 --- Seb, time to ping your patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17520
[Bug target/18230] SPARC VIS instructions are not generated by GCC
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 10:15 --- Subject: Bug 18230 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-10 10:14:37 Modified files: gcc: ChangeLog gcc/config/sparc: sparc.md gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/sparc: fpadd16.c fpadd16s.c fpadd32.c fpadd32s.c fpsub16.c fpsub16s.c fpsub32.c fpsub32s.c sparc.exp Log message: PR target/18230 (addsi3, subsi3): Set fptype attribute. (addv2si, addv4hi, addv2hi, subv2si, subv4hi, subv2hi): New patterns. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6262r2=2.6263 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.md.diff?cvsroot=gccr1=1.219r2=1.220 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4568r2=1.4569 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/fpadd16.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/fpadd16s.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/fpadd32.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/fpadd32s.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/fpsub16.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/fpsub16s.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/fpsub32.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/fpsub32s.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/sparc.exp.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18230
[Bug middle-end/16458] PowerPC - redundant compare
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16458
[Bug rtl-optimization/16796] PowerPC - Unnecessary Floating Point Register Copy
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-10 11:01 --- The fault is not the register allocator, is is a problem introduced by flow2 and the existance of conditional returns on PPC. During register allocation there is one exit block. The returns are 'x, x, x+x x', thus the global allocator sets the exit block to copy 'x' to the return register. flow2 replaces some of those branches to the exit block with conditional returns, because 'x' resides in both DF:33 and DF:32. The remaining use of the exit is the load from the union into DF:32, the location of 'x' during the function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16796
strange error
When I try to compile this code (witch has one ')' missing) I get a strange error... Is it a bug? bye, Mirko P.S.: I use gcc (GCC) 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) 29: for(i=1; inArg ;printf(%s\n, vsArg[i],i++) 30: if(strcmp(vsArg[i], -png)==0) 31: opz.nomeimg = vsArg[++i]; cbarre.c: In function `argomenti': cbarre.c:29: warning: too many arguments for format cbarre.c:30: parse error before if cbarre.c:30: `__s1_len' undeclared (first use in this function) cbarre.c:30: (Each undeclared identifier is reported only once cbarre.c:30: for each function it appears in.) cbarre.c:30: `__s2_len' undeclared (first use in this function) cbarre.c:30: warning: left-hand operand of comma expression has no effect cbarre.c:30: warning: left-hand operand of comma expression has no effect cbarre.c:30: warning: left-hand operand of comma expression has no effect cbarre.c:30: warning: left-hand operand of comma expression has no effect cbarre.c: At top level: cbarre.c:30: parse error before ')' token cbarre.c:32: parse error before '[' token cbarre.c:32: warning: type defaults to `int' in declaration of `__result' cbarre.c:32: ISO C forbids data definition with no type or storage class cbarre.c:32: parse error before '}' token cbarre.c:32: conflicting declarations of `__result' cbarre.c:32: `__result' previously declared here cbarre.c:32: warning: `__result' was declared `extern' and later `static' cbarre.c:32: `vsArg' undeclared here (not in a function) cbarre.c:32: `i' undeclared here (not in a function) cbarre.c:32: `__s2' undeclared here (not in a function) cbarre.c:32: parse error before if cbarre.c:32: warning: type defaults to `int' in declaration of `__result' cbarre.c:32: conflicting declarations of `__result' cbarre.c:32: `__result' previously defined here cbarre.c:32: ISO C forbids data definition with no type or storage class cbarre.c:32: parse error before '}' token cbarre.c:32: warning: type defaults to `int' in declaration of `__result' cbarre.c:32: ISO C forbids data definition with no type or storage class cbarre.c:32: parse error before '}' token cbarre.c:32: conflicting declarations of `__result' cbarre.c:32: `__result' previously declared here cbarre.c:32: warning: `__result' was declared `extern' and later `static' cbarre.c:32: `__s1' undeclared here (not in a function) cbarre.c:32: parse error before if cbarre.c:32: warning: type defaults to `int' in declaration of `__result' cbarre.c:32: conflicting declarations of `__result' cbarre.c:32: `__result' previously defined here cbarre.c:32: ISO C forbids data definition with no type or storage class cbarre.c:32: parse error before '}' token cbarre.c:34: parse error before '[' token cbarre.c:34: warning: type defaults to `int' in declaration of `__result' cbarre.c:34: ISO C forbids data definition with no type or storage class cbarre.c:34: parse error before '}' token cbarre.c:34: conflicting declarations of `__result' cbarre.c:34: `__result' previously declared here cbarre.c:34: warning: `__result' was declared `extern' and later `static' cbarre.c:34: `vsArg' undeclared here (not in a function) cbarre.c:34: `i' undeclared here (not in a function) cbarre.c:34: `__s2' undeclared here (not in a function) cbarre.c:34: parse error before if cbarre.c:34: warning: type defaults to `int' in declaration of `__result' cbarre.c:34: conflicting declarations of `__result' cbarre.c:34: `__result' previously defined here cbarre.c:34: ISO C forbids data definition with no type or storage class cbarre.c:34: parse error before '}' token cbarre.c:34: warning: type defaults to `int' in declaration of `__result' cbarre.c:34: ISO C forbids data definition with no type or storage class cbarre.c:34: parse error before '}' token cbarre.c:34: conflicting declarations of `__result' cbarre.c:34: `__result' previously declared here cbarre.c:34: warning: `__result' was declared `extern' and later `static' cbarre.c:34: `__s1' undeclared here (not in a function) cbarre.c:34: parse error before if cbarre.c:34: warning: type defaults to `int' in declaration of `__result' cbarre.c:34: conflicting declarations of `__result' cbarre.c:34: `__result' previously defined here cbarre.c:34: ISO C forbids data definition with no type or storage class cbarre.c:34: parse error before '}' token cbarre.c:36: parse error before '[' token cbarre.c:36: warning: type defaults to `int' in declaration of `__result' cbarre.c:36: ISO C forbids data definition with no type or storage class cbarre.c:36: parse error before '}' token cbarre.c:36: conflicting declarations of `__result' cbarre.c:36: `__result' previously declared here cbarre.c:36: warning: `__result' was declared `extern' and later `static' cbarre.c:36: `vsArg' undeclared here (not in a function) cbarre.c:36: `i' undeclared here (not in a function) cbarre.c:36: `__s2' undeclared here (not in a function) cbarre.c:36: parse error before if cbarre.c:36: warning: type defaults to `int' in declaration of `__result' cbarre.c:36: conflicting
[Bug rtl-optimization/16796] PowerPC - Unnecessary Floating Point Register Copy
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16796
[Bug target/18300] Infinite loop when passing object with 3+ base classes by value
--- Additional Comments From zak at transversal dot com 2004-11-10 12:36 --- I've submitted a patch which fixes this: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00811.html -- What|Removed |Added Keywords||patch Known to fail|3.2.3 3.3.3 3.3.4 3.3.5 |3.2.3 3.3.3 3.3.4 3.3.5 ||3.4.2 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300
[Bug c++/18415] New: Heavily template-expression using program crashes on -O0 but not on -O1
When running a program that makes heavy use of expression templates, it works
fine with any -O option. However, if no -O option is used, then it segfaults.
Note that if the expression used is changed to something like arg + arg, then it
doesn't crash but gives wrong results if no -O option is specified.
typedef unsigned int size_t;
struct AddOp
{
templateclass I1, class I2 static inline float
call(size_t i, const I1 i1, const I2 i2) {return i1[i] + i2[i];}
};
struct MultOp
{
templateclass I1, class I2 static inline float
call(size_t i, const I1 i1, const I2 i2) {return i1[i] * i2[i];}
};
class Expr
{
float data;
public:
Expr(float arg_data) : data(arg_data) {}
float
operator[](size_t i) const {return data;}
};
templateclass I1, class I2, class Op
class Expr3
{
const I1 i1;
const I2 i2;
public:
Expr3(const I1 ai1, const I2 ai2)
: i1(ai1), i2(ai2)
{
}
float
operator[](size_t i) const
{
return Op::call(i, i1, i2);
}
templateclass E
Expr3Expr3, E, AddOp
operator+(const E e) const
{
return Expr3Expr3, E, AddOp(*this, e);
}
};
struct Vec4
{
Vec4(float all)
: x(all), y(all), z(all), w(all)
{
}
Vec4(float ax, float ay, float az, float aw = 1)
: x(ax), y(ay), z(az), w(aw)
{
}
float x, y, z, w;
float
operator[](size_t i) const
{
switch(i) {
case 0: return x;
case 1: return y;
case 2: return z;
case 3: return w;
default: return 0xdeadbeef;
}
}
const Vec4
operator=(float arg)
{
x = y = z = w = arg; return *this;
}
Expr3Vec4, Expr, MultOp
operator*(float e) const
{
return Expr3Vec4, Expr, MultOp(*this, Expr(e));
}
templateclass E
const Vec4
operator=(const E e)
{
x = e[0]; y = e[1]; z = e[2]; w = e[3]; return *this;
}
};
templateclass T
Expr3Expr3Vec4, Expr, MultOp, Expr3Vec4, Expr, MultOp, AddOp
dostuff(const T arg)
{
return (arg * 0.f) + (arg * 0.1f);
}
int
main()
{
const float ARG1 = 3.40282347e+38f;
Vec4 v1(ARG1), v2(ARG1);
v2 = dostuff(v1);
}
--
Summary: Heavily template-expression using program crashes on -O0
but not on -O1
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ayqazi at yahoo dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18415
[Bug c++/18415] Heavily template-expression using program crashes on -O0 but not on -O1
--- Additional Comments From ayqazi at yahoo dot co dot uk 2004-11-10 12:38 --- Created an attachment (id=7515) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7515action=view) Test case to reproduce bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18415
[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions
-- What|Removed |Added Summary|[3.3/3.4/4.0 Regression]|new/delete much slower than |new/delete much slower than |malloc/free because of sjlj |malloc/free because of sjlj |exceptions |exceptions | Target Milestone|3.3.6 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563
[Bug c++/18416] New: [4.0 regression] ICE in import_export_decl
$ cat errarg.ii
class errarg {
enum { EMPTY } type;
public:
errarg();
};
extern errarg empty_errarg;
extern void errprint(const char *,
const errarg arg1 = empty_errarg,
const errarg arg2 = empty_errarg,
const errarg arg3 = empty_errarg);
errarg::errarg() : type(EMPTY)
{
}
errarg empty_errarg;
(gdb) r -fpreprocessed errarg.ii -O
Starting program: /cvs/test/gcc/gcc/cc1plus -fpreprocessed errarg.ii -O
errarg::errarg()
errarg::errarg()
errarg::errarg()
void __static_initialization_and_destruction_0(int, int)
Program received signal SIGSEGV, Segmentation fault.
import_export_decl (decl=0x2049f9c0) at /cvs/gcc/gcc/cp/decl2.c:1773
1773gcc_assert (DECL_IMPLICIT_INSTANTIATION (decl)
(gdb) p decl.decl.lang_specific
$6 = (struct lang_decl *) 0x0
--
Summary: [4.0 regression] ICE in import_export_decl
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18416
[Bug ada/18417] New: Ada bootstrap failure on IRIX 6.5: tb-gcc.c missing
I just tried to bootstrap current mainline (C and Ada only) on mips-sgi-irix6.5, but failed in Stage 1 already: gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -Wno-error -DHAVE_CONFIG_H -I. -Iada -I/vol/gnu/src/gcc/gcc-dist/gcc -I/vol/gnu/src/gcc/gcc-dist/gcc/ada -I/vol/gnu/src/gcc/gcc-dist/gcc/../include -I/vol/gnu/src/gcc/gcc-dist/gcc/../libcpp/include \ -fno-omit-frame-pointer /vol/gnu/src/gcc/gcc-dist/gcc/ada/tracebak.c -o ada/tracebak.o /vol/gnu/src/gcc/gcc-dist/gcc/ada/tracebak.c:352:20: tb-gcc.c: No such file or directory make[2]: *** [ada/tracebak.o] Error 1 That file is included from tracebak.c, but missing from the CVS repository. Environment: System: IRIX sculptor 6.5 10060437 IP32 host: mips-sgi-irix6.5 build: mips-sgi-irix6.5 target: mips-sgi-irix6.5 configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --enable-libgcj --disable-multilib --enable-languages=c,ada --with-gnu-as --with-as=/vol/gcc/lib/gas-2.15 --disable-libmudflap How-To-Repeat: Try bootstrapping as above. -- Summary: Ada bootstrap failure on IRIX 6.5: tb-gcc.c missing Product: gcc Version: 0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: mips-sgi-irix6.5 GCC host triplet: mips-sgi-irix6.5 GCC target triplet: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18417
[Bug c++/18418] New: GCC 3.4.3 builds worse code than GCC 3.3.4 using template expressions
Hi, Using a template expressions 3D maths library I'm developing, I have discovered that GCC 3.4.3 builds worse code than GCC 3.3.4 (and predecessors.) I have attached a test case file using a part of the template expression library that highlights this case. Regardless of which -march flag I used to compile it (i386, etc.) and regardless of the -msse flag being present or not, the asm output was clearly longer by about 20% in the gcc 3.4.3 compiled code. p.s. it will work if an optimisation flag is present (I have verified it.) Without an optimisation flag, GCC doesn't generate proper code (this bug has already been reported.) -- Summary: GCC 3.4.3 builds worse code than GCC 3.3.4 using template expressions Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ayqazi at yahoo dot co dot uk CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18418
[Bug c++/18418] GCC 3.4.3 builds worse code than GCC 3.3.4 using template expressions
--- Additional Comments From ayqazi at yahoo dot co dot uk 2004-11-10 13:54 --- Created an attachment (id=7516) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7516action=view) Test case for differences in GCC 3.4.3 and 3.3.4 template expression code gen Compile to assembler (e.g. g++ -S -O) using same flags with both a GCC 3.3 series compiler, and a GCC 3.4 series compiler and spot the file length difference - you MUST use an optimisation flag for it to compile correctly (another bug, already submitted.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18418
[Bug c++/18415] Template-expression using program crashes on -O0 but not on -O1
-- What|Removed |Added Summary|Heavily template-expression |Template-expression using |using program crashes on -O0|program crashes on -O0 but |but not on -O1 |not on -O1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18415
[Bug c++/18416] [4.0 regression] ICE in import_export_decl
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 13:56 --- Confirmed. Has been a problem since at least 20041012. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-10 13:56:02 date|| Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18416
[Bug c++/18415] Template-expression using program crashes on -O0 but not on -O1
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 13:58 --- return Expr3Vec4, Expr, MultOp(*this, Expr(e)); The life time of Expr(e) is just this statement so this is invalid. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18415
[Bug c++/18418] [3.4 only] GCC 3.4.3 builds worse code than GCC 3.3.4 using template expressions
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 14:07 --- First this is invalid code as explained in PR 18415. Second this works fine on the mainline as get close to optimial code. -- What|Removed |Added Keywords||missed-optimization Known to work||4.0.0 3.3.3 Summary|GCC 3.4.3 builds worse code |[3.4 only] GCC 3.4.3 builds |than GCC 3.3.4 using|worse code than GCC 3.3.4 |template expressions|using template expressions Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18418
[Bug target/18380] [3.4 regression]: _Unwind_FindTableEntry shouldn't be exported from libunwind.so.7
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 14:08 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18380
[Bug ada/18417] [4.0 Regression]Ada bootstrap failure on IRIX 6.5: tb-gcc.c missing
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 14:13 --- #elif defined (__mips) defined (__sgi) #define USE_GCC_UNWINDER #define PC_ADJUST -8 #endif Caused by: 2004-06-25 Olivier Hainque [EMAIL PROTECTED] * tracebak.c: Introduce support for a GCC infrastructure based implementation of __gnat_backtrace. -- What|Removed |Added CC||charlet at gcc dot gnu dot ||org, hainque at act-europe ||dot fr Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||build Last reconfirmed|-00-00 00:00:00 |2004-11-10 14:13:47 date|| Summary|Ada bootstrap failure on|[4.0 Regression]Ada |IRIX 6.5: tb-gcc.c missing |bootstrap failure on IRIX ||6.5: tb-gcc.c missing Target Milestone|--- |4.0.0 Version|0.0 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18417
[Bug c++/18416] [4.0 regression] ICE in import_export_decl
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10
14:39 ---
This might also effect 3.4.3 but I have not tried it.
Here is the reduced testcase:
struct errarg {
errarg();
};
extern errarg empty_errarg;
extern void errprint(const char *,
const errarg arg1 = empty_errarg);
errarg empty_errarg;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18416
[Bug tree-optimization/18419] New: [4.0 Regression] tree-ssa aliasing slow
The testcase from PR 16975 shows the tree-ssa aliasing pass can be slow. You can get the testcase from: http://www.math.purdue.edu/~lucier/GNATS/GNATS-12/_num.i.gz Here is the results from my build (yes with --disable-checking): tree PTA : 35.74 (38%) usr 0.12 ( 1%) sys 37.63 (33%) wall Note this testcase has a large number of computed gotos. -- Summary: [4.0 Regression] tree-ssa aliasing slow Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P2 Component: tree-optimization AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18419
[Bug c++/18416] [4.0 regression] ICE in import_export_decl
--- Additional Comments From schwab at suse dot de 2004-11-10 15:19 --- 3.4.3 works. -- What|Removed |Added Known to work||3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18416
[Bug tree-optimization/18419] [4.0 Regression] tree-ssa aliasing slow
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18419
[Bug tree-optimization/18419] [4.0 Regression] tree-ssa aliasing slow
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 15:36 --- Most of the time is spent in bitmap_bit_p which is called from collect_points_to_info_for, maybe we should be using sbitmap instead. Note collect_points_to_info is called from merge_pointed_to_info -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18419
[Bug bootstrap/18310] [3.4 regression] make bootstrap-lean deletes stage2/xgcc
--- Additional Comments From prj-bugzilla-gcc at multivac dot cwru dot edu 2004-11-10 15:38 --- This happened with the prerelease, but it doesn't happen with the final 3.4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18310
[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions
--- Additional Comments From ron_hylton at hotmail dot com 2004-11-10
16:20 ---
(In reply to comment #40)
Ron, can you please attach your testcase that shows the problem to this PR?
This PR is a regression on cygwin because the speed is back with 3.2.
This is the test case I was using:
#include iostream
#include stdio.h
#include time.h
#include string
using namespace std;
int main()
{
int array_size = 100;
int loop_count = 300;
try
{
long t1 = clock();
for (int iloop = 0; iloop loop_count; iloop++)
{
int *myarray = new int [array_size];
delete [] myarray;
}
long t2 = clock();
double delt1 = (double)( t2 - t1 )/ (double)(CLOCKS_PER_SEC);
cout done looping time 1= delt1 endl;
long t3 = clock();
for (int jloop = 0; jloop loop_count; jloop++)
{
int *myarray = (int *)malloc(array_size * sizeof(int));
if (myarray== NULL) { printf(alloc failed\n);
exit(1); }
else free (myarray);
}
long t4 = clock();
double delt2 = (double)( t4 - t3 )/ (double)(CLOCKS_PER_SEC);
cout done looping time 2= delt2 endl;
}
catch (...)
{
cout exception std::endl;
return 1;
}
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563
[Bug target/16975] Tremendous increase in compile times for 3.4.1 with -mcpu=G5
rename registers : 2.93 ( 5%) usr 0.14 ( 1%) sys 4.49 ( 4%) wall scheduling 2 : 0.52 ( 1%) usr 0.04 ( 0%) sys 0.92 ( 1%) wall shorten branches : 0.09 ( 0%) usr 0.01 ( 0%) sys 0.11 ( 0%) wall final : 0.23 ( 0%) usr 0.02 ( 0%) sys 0.45 ( 0%) wall symout: 0.01 ( 0%) usr 0.01 ( 0%) sys 0.01 ( 0%) wall rest of compilation : 0.18 ( 0%) usr 0.04 ( 0%) sys 0.26 ( 0%) wall TOTAL : 63.2815.56 112.92 [descartes:gcc/mainline/objdir] lucier% /pkgs/gcc-mainline/bin/gcc -v Reading specs from /pkgs/gcc-mainline/lib/gcc/powerpc-apple-darwin7.6.0/4.0.0/specs Configured with: ../configure --prefix=/pkgs/gcc-mainline --enable-checking=no --enable-languages=c Thread model: posix gcc version 4.0.0 20041110 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16975
[Bug middle-end/18420] New: ICE compiling mesa at -O2
I'll add more details as they unfold, but wanted to get this posted into bugzilla. The autotester has been pretty flaky lately that I don't have a good idea when this broke, but looks to have broken somewhere between Oct 29 and Nov 4. I don't have data between those dates, but Nov 4. build did not compile mesa. SegFault doesn't happen at -O1. SegFault Building mesa. /opt/gcc-nightly/gcc/libexec/gcc/powerpc64-linux/4.0.0/cc1 -O2 context.c context.c: In function gl_create_visual: context.c:1082: 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. Watching in GDB shows. Analyzing compilation unit Performing intraprocedural optimizations Assembling functions: free_shared_state init_material gl_create_visual Program received signal SIGSEGV, Segmentation fault. note_stores (x=0x403d62f0, fun=0x10325090 forget_old_reloads_1, data=0x0) at /home/gccbuild/gcc_mline_anoncvs/gcc/gcc/rtlanal.c:1405 1405/home/gccbuild/gcc_mline_anoncvs/gcc/gcc/rtlanal.c: No such file or directory. in /home/gccbuild/gcc_mline_anoncvs/gcc/gcc/rtlanal.c -- Summary: ICE compiling mesa at -O2 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jgrimm2 at us dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug middle-end/18420] ICE compiling mesa at -O2
-- What|Removed |Added GCC target triplet||powerpc64-linux Summary|ICE compiling mesa at -O2 |ICE compiling mesa at -O2 Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug c++/18416] [4.0 regression] ICE in import_export_decl
--- Additional Comments From schwab at suse dot de 2004-11-10 16:48 --- Broken by this: 2004-07-29 Mark Mitchell [EMAIL PROTECTED] * cp-tree.h (IDENTIFIER_REPO_CHOSEN): Define. ... -- What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18416
[Bug c++/18369] [4.0 regression] Segfault on braced new
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 17:01 --- Subject: Bug 18369 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-10 17:01:00 Modified files: gcc/cp : ChangeLog init.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/init: new12.C Log message: PR c++/18369 * init.c (build_new_1): Handle parenthesized type-ids that name an array type. Tidy. PR c++/18369 * g++.dg/init/new12.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4476r2=1.4477 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gccr1=1.400r2=1.401 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4569r2=1.4570 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/new12.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18369
[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions
--- Additional Comments From kjd at duda dot org 2004-11-10 17:05 ---
(In reply to comment #40)
Ron, can you please attach your testcase that shows the problem to this PR?
This PR is a regression on cygwin because the speed is back with 3.2.
Here's a test case for you...
-Ken
---
// Uncomment one of these defines.
// With the first define uncommented, I get 3.293 usec per operator new use.
// With the second define uncommented, I get 1.019 usec per operator new use.
// A high price to pay for having one's exceptions properly declared!
//#define THROW throw (std::bad_alloc)
#define THROW
// These definitions are taken straight from libstdc++.
#include new
#include exception_defines.h
using std::new_handler;
using std::bad_alloc;
extern C void *malloc (std::size_t);
extern new_handler __new_handler;
void *
operator new (std::size_t sz) THROW
{
void *p;
/* malloc (0) is unpredictable; avoid it. */
if (sz == 0)
sz = 1;
p = (void *) malloc (sz);
while (p == 0)
{
new_handler handler = __new_handler;
if (! handler)
#ifdef __EXCEPTIONS
throw bad_alloc();
#else
std::abort();
#endif
handler ();
p = (void *) malloc (sz);
}
return p;
}
void *
operator new[] (std::size_t sz) THROW
{
return ::operator new(sz);
}
#include string.h
#include stdlib.h
#include stdio.h
#include unistd.h
#include assert.h
typedef unsigned long long u64;
typedef u64 Usec;
#ifdef WIN32
#include Windows.h
inline Usec Now()
{
DWORD ticks = GetTickCount();
return ((Usec) ticks) * 1000;
}
#else
#include sys/types.h
#include sys/time.h
inline Usec Now()
{
struct timeval tv;
if( gettimeofday( tv, 0 ) ) {
perror( gettimeofday );
exit( 1 );
}
return ((Usec) tv.tv_sec) * 100 + tv.tv_usec;
}
#endif
using namespace std;
main()
{
int sizeMin = 4;
int sizeMax = 100;
int allocsOutstanding = 1000;
int reps = 1000;
int allocsPerRep = 1000;
int sizeRange = sizeMax - sizeMin;
char ** ptrs = (char **) malloc( sizeof( char * ) * allocsOutstanding );
memset( ptrs, 0, sizeof( char * ) * allocsOutstanding );
Usec start = Now();
int m = reps;
while( m-- ) {
int n = allocsPerRep;
while( n-- ) {
int r = rand();
int index = r % allocsOutstanding;
char * p = ptrs[index];
delete[] p;
// free( p );
int size = (r % sizeRange) + sizeMin;
p = new char[ size ];
// p = (char *) malloc( size );
ptrs[index] = p;
}
}
Usec stop = Now();
double t = ((double) stop - start) / ((double) allocsPerRep * reps);
printf( cost of new + delete is about %0.3f usec\n, t );
fflush( stdout );
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563
[Bug tree-optimization/17892] [4.0 Regression] gcc-4.0 should not reassociate floating point add or multiplication
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 17:18 --- Subject: Bug 17892 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-10 17:18:01 Modified files: gcc: tree-ssa-dom.c ChangeLog gcc/testsuite : ChangeLog Log message: Fix for PR tree-optimization/17892. OKed by Roger Sayle. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-dom.c.diff?cvsroot=gccr1=2.65r2=2.66 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6263r2=2.6264 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4570r2=1.4571 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17892
[Bug c++/18369] [4.0 regression] Segfault on braced new
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-10 17:20 --- Fixed in GCC 4.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18369
[Bug c++/18143] [4.0 Regression] Duplicated thunk with a huge member in the hierarchy
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-10 17:26 --- 2004-11-10 Nathan Sidwell [EMAIL PROTECTED] * tree.c (tree_check_failed): Emit general error if the list of node types is empty. PR c++/18143 * cp-tree.h (NON_THUNK_FUNCTION_CHECK, THUNK_FUNCTION_CHECK): New. (struct lang_decl_flags): Add thunk_p flag. (struct lang_decl): Remove separate fixed_offset. Place cloned_function and fixed_offset into union. (DECL_CLONED_FUNCTION_P, DECL_CLONED_FUNCTION): Adjust. (DECL_THUNK_P, SET_DECL_THUNK_P): Adjust. (THUNK_FIXED_OFFSET): Adjust. * method.c (make_thunk): Adjust. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18143
[Bug c++/18143] [4.0 Regression] Duplicated thunk with a huge member in the hierarchy
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 17:35 --- Subject: Bug 18143 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-10 17:34:48 Modified files: gcc: ChangeLog tree.c gcc/cp : ChangeLog method.c cp-tree.h Log message: .: * tree.c (tree_check_failed): Emit general error if the list of node types is empty. cp: PR c++/18143 * cp-tree.h (NON_THUNK_FUNCTION_CHECK, THUNK_FUNCTION_CHECK): New. (struct lang_decl_flags): Add thunk_p flag. (struct lang_decl): Remove separate fixed_offset. Place cloned_function and fixed_offset into union. (DECL_CLONED_FUNCTION_P, DECL_CLONED_FUNCTION): Adjust. (DECL_THUNK_P, SET_DECL_THUNK_P): Adjust. (THUNK_FIXED_OFFSET): Adjust. * method.c (make_thunk): Adjust. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6265r2=2.6266 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gccr1=1.444r2=1.445 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4477r2=1.4478 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gccr1=1.316r2=1.317 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gccr1=1.1069r2=1.1070 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18143
[Bug target/16975] Tremendous increase in compile times for 3.4.1 with -mcpu=G5
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 18:01 --- I already filed the compile time problem for tree-ssa aliasing as PR 18419. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16975
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
-- What|Removed |Added Component|middle-end |rtl-optimization Keywords||ice-on-valid-code Summary|ICE compiling mesa at -O2 |[4.0 Regression] ICE ||compiling mesa at -O2 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug tree-optimization/18419] [4.0 Regression] tree-ssa aliasing slow
-- What|Removed |Added CC||lucier at math dot purdue ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18419
[Bug libgcj/18376] java.io.BufferedWriter outputing extraneous characters?
--- Additional Comments From wayne dot gray at coynetextileservices dot com 2004-11-10 18:23 --- Ok thanks. I'll rip out that File.length() stuff and see if that works. Thanks for your time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18376
[Bug c/18421] New: Internal Compiler Error
Hello,
I tried to compile the newlib with -O1. I got
m68k-elf-gcc
-B/home/bwalle/src/packages/BUILD/newlib-1.12.0/m68k-elf/m5307/newlib/ -isystem
/home/bwalle/src/packages/BUILD/newlib-1.12.0/m68k-elf/m5307/newlib/targ-include
-isystem /home/bwalle/src/packages/BUILD/newlib-1.12.0/newlib/libc/include
-m5307 -DPACKAGE=\newlib\ -DVERSION=\1.12.0\ -I.
-I../../../../.././newlib/libc/locale -O2 -DCOMPACT_CTYPE
-DMISSING_SYSCALL_NAMES -fno-builtin-O2 -O1 -O2 -O1 -m5307 -c
../../../../.././newlib/libc/locale/fix_grouping.c
../../../../.././newlib/libc/locale/fix_grouping.c: In function
`__fix_locale_grouping_str':
../../../../.././newlib/libc/locale/fix_grouping.c:82: Fehler: Befehl erfüllt
nicht seine Bedingungen:
(insn 217 106 107 12 (set (reg:QI 13 %a5)
(mem:QI (reg/v/f:SI 9 %a1 [orig:32 src ] [32]) [0 S1 A8])) 33
{*m68k.md:826} (nil)
(nil))
../../../../.././newlib/libc/locale/fix_grouping.c:82: interner Compiler-Fehler:
in reload_cse_simplify_operands, bei postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
It's newlib 1.12.0, so you should have the source. There are no errors with
default -O2 or -O0.
--
Summary: Internal Compiler Error
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernhard dot walle at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: m68k-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18421
[Bug target/18421] Internal Compiler Error
-- What|Removed |Added Component|c |target Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18421
[Bug bootstrap/18310] [3.4 regression] make bootstrap-lean deletes stage2/xgcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 18:35 --- So closing as fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18310
[Bug c++/18418] [3.4 only] GCC 3.4.3 builds worse code than GCC 3.3.4 using template expressions
--- Additional Comments From giovannibajo at libero dot it 2004-11-10 18:52 --- Notice that I would prefer to see a runtime benchmark before confirming this bug. A 20% increase in code size could probably be caused by better inlining -- it does not automatically means that the code is slower unless you prove otherwise. If you compile with -O2, you should test run-time speed with a run-time benchmark: try doing some calculations and time them with different compilers. If you care about code size, try with -Os. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18418
[Bug rtl-optimization/18294] [4.0 Regression] ICE in rtl_verify_flow_info during bootstrap
--- Additional Comments From sje at cup dot hp dot com 2004-11-10 18:54 --- See proposed patch in http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00829.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18294
[Bug fortran/18375] ICE when compiling spec benchmark fma3d
-- What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2004-11-08 14:21:42 |2004-11-10 19:05:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18375
[Bug tree-optimization/17892] [4.0 Regression] gcc-4.0 should not reassociate floating point add or multiplication
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 19:07 --- Subject: Bug 17892 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-10 19:06:54 Added files: gcc/testsuite/gcc.c-torture/execute/ieee: unsafe-fp-assoc-1.c Log message: Test for PR tree-optimization/17892. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/unsafe-fp-assoc-1.c.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17892
Bad compile time complexity for large files ??? (fwd)
FYI. Joris's messages seem to have been blocked...
Please, CC: Joris when replying.
Joris --
It might help if you can provide information about the version of GCC
you're using. You might also want to try
http://gcc.gnu.org/bugzilla/
That way, your report will be recorded in the PR database.
---BeginMessage---
Salut Gabriel,
J'ai essaye plusieurs fois de poster le message ci-dessous
sur la liste gcc, mais c'est systematiquement refuse.
Peut-etre que tu peux le poster et me forwarder d'eventuelles reponses.
Je me suis desinscrit de la liste, car il y avait trop de messages.
A+, Joris
-- Forwarded message --
Date: Tue, 9 Nov 2004 12:00:47 +0100 (CET)
From: Joris van der Hoeven [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Bad compile time complexity for large files ??? (fwd)
Hi,
I have suscribed to the gcc mailing list in order to send
the message below, but it keeps being rejected. Why?
Joris
-- Forwarded message --
Date: Tue, 9 Nov 2004 11:36:29 +0100 (CET)
From: Joris van der Hoeven [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Bad compile time complexity for large files ???
Hi *,
I am using g++ for compiling automatically generated glue files
for another language (mathemagix). These glue files tend to become
quite big when I want to glue big C++ libraries. More precisely,
they contain a lot of small methods and routines, like
--
[...]
ext_inst
ext_mml_vector_rep::gen_timesassign (ext_inst arg_1, ext_inst arg_2) {
ext_type save_1 = ext_cur_1;
ext_cur_1 = x_1;
ext_inst ret = convertext_inst, mml_vectorext_inst_1
(convertmml_vectorext_inst_1, ext_inst (arg_1) *=
convertmml_vectorext_inst_1, ext_inst (arg_2));
ext_cur_1 = save_1;
return ret;
}
[...]
static mmx::generic
FUN_29 (mmx::generic g) {
return mmx::as_mmxdouble, TID (mmx::as_cppdouble, TID (g[1]) *=
mmx::as_cppdouble, TID (g[2]));
}
[...]
--
The number of classes is relatively small.
When the number of routines increases, I noticed a far more than
linear time complexity for the compilation time. This is very
disappointing for me, since it makes it nearly impossible to compile
glue files with more than a few hundred routines.
I suspect that this behaviour is due to a lack of optimization
in the way identifiers are stored by the compiler: does gcc use
a linked list instead of a hash table? Is there a compilation
option that I may have overlooked?
I would be very interested in having this important drawback being
removed; such an optimization will probably be interesting anyway,
since the performance already drops sharply for files with a few
thousand lines. If I can somehow help with improving this point,
then please let me know; I know nothing about the g++ source code,
but may learn the necessary if somebody guides me.
Best wishes, Joris
---
Joris van der Hoeven [EMAIL PROTECTED]
http://www.texmacs.org: GNU TeXmacs scientific text editor
http://www.math.u-psud.fr/~vdhoeven: personal homepage
---
---End Message---
--
Gabriel Dos Reis
[EMAIL PROTECTED]
Texas AM University -- Department of Computer Science
301, Bright Building -- College Station, TX 77843-3112
Re: Bad compile time complexity for large files ??? (fwd)
On Nov 10, 2004, at 11:14 AM, Gabriel Dos Reis wrote: FYI. Joris's messages seem to have been blocked... Please, CC: Joris when replying. Joris -- It might help if you can provide information about the version of GCC you're using. You might also want to try http://gcc.gnu.org/bugzilla/ That way, your report will be recorded in the PR database. I would be interested in seeing a test case. Compilation speed is important, and if there really is something that cases superlinear behavior I would like to fix it. --Matt
[Bug c/18322] [3.3/3.4 Regression] __func__ diagnostic in bad location
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 19:47 --- Subject: Bug 18322 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-11-10 19:46:34 Modified files: gcc: ChangeLog c-common.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: func-outside-1.c func-outside-2.c Log message: PR c/18322 * c-common.c (fname_decl): Don't use line number of decl in diagnostic. testsuite: * gcc.dg/func-outside-1.c, gcc.dg/func-outside-2.c: New tests. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.685r2=2.2326.2.686 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.476.4.9r2=1.476.4.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.306r2=1.3389.2.307 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/func-outside-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.2.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/func-outside-2.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.2.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18322
[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators
-- What|Removed |Added CC||tausq at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17564
[Bug bootstrap/18381] [4.0 Regression] Stage 1 failure in fixincludes, recent CVS
--- Additional Comments From mg_gentoo at yahoo dot com 2004-11-10 20:02 --- Same problem building compiler on x86_64 targetted at *mingw* (as opposed to cygwin). -- What|Removed |Added CC||mg_gentoo at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18381
[Bug fortran/18375] ICE when compiling spec benchmark fma3d
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 20:04 --- Subject: Bug 18375 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-10 20:03:23 Modified files: gcc/fortran: ChangeLog trans-expr.c trans-io.c Log message: PR fortran/18375 * trans-expr.c (gfc_trans_subarray_assign): Free shape before ss. * trans-io.c (transfer_array_component): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.254r2=1.255 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gccr1=1.31r2=1.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-io.c.diff?cvsroot=gccr1=1.23r2=1.24 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18375
[Bug fortran/18375] ICE when compiling spec benchmark fma3d
--- Additional Comments From pbrook at gcc dot gnu dot org 2004-11-10 20:26 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18375
[Bug fortran/18375] ICE when compiling spec benchmark fma3d
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18375
[Bug middle-end/18160] [4.0 Regression] ICE on taking register variable address
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 21:10 --- Subject: Bug 18160 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-10 21:09:30 Modified files: gcc/cp : ChangeLog typeck.c Log message: PR middle-end/18160 * typeck.c (cxx_mark_addressable): Issue an error if address of an explicit register variable is requested. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4478r2=1.4479 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gccr1=1.594r2=1.595 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18160
[Bug middle-end/18160] [4.0 Regression] ICE on taking register variable address
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 21:10 --- Subject: Bug 18160 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-10 21:09:30 Modified files: gcc/cp : ChangeLog typeck.c Log message: PR middle-end/18160 * typeck.c (cxx_mark_addressable): Issue an error if address of an explicit register variable is requested. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4478r2=1.4479 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gccr1=1.594r2=1.595 --- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-10 21:10 --- Subject: Bug 18160 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-10 21:09:59 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/warn: register-var-1.C register-var-2.C Log message: PR middle-end/18160 * g++.dg/warn/register-var-1.C: New test. * g++.dg/warn/register-var-2.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4572r2=1.4573 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/register-var-1.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/register-var-2.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18160
[Bug libstdc++/16371] [3.4/4.0 Regression] libstdc++ fails for crosses
--- Additional Comments From mg_gentoo at yahoo dot com 2004-11-10 21:11 --- Jim, you expressed an interest in this bug a while back, suggesting 1) using sysroot - which I tried, it didn't help anything and 2) looking for an unspecified something in config.log. Can you provide any insight? Tell us what to look for perhaps? I'll do just about anything to bring about a clean fix. -- What|Removed |Added CC||wilson at specifixinc dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371
[Bug c++/18416] [4.0 regression] ICE in import_export_decl
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18416
[Bug c++/18416] [4.0 regression] ICE in import_export_decl
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-10 22:09 --- I'm not able to reproduce this on i686-pc-linux-gnu. Any special configuration options required? Or is this only visible on ia64-*-linux-gnu? Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18416
[Bug AWT/17351] java.awt.color.ICC_Profile unimplemented
--- Additional Comments From sven at physto dot se 2004-11-10 22:11 --- Merged over from classpath now. Great! -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17351
[Bug AWT/18312] Component.createImage() doesn't clear bitmap
--- Additional Comments From sven at physto dot se 2004-11-10 22:12 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18312
[Bug bootstrap/18422] New: configure scripts run incredibly slow when bootstrapping on AIX
hardware: 2xPOWER3-II 450MHz/2GB RAM/36GB 10K disk oslevel -r: 5200-03 I'm not too much into the gcc bootstrapping process but I believe this occurs at stage2 (already using xgcc to compile), at first when the configure script for libstdc++ runs. The configure script is running at around a 1 (one!) check/minute rate on the system above(64bit kernel, JFS2). This leads to a build process duration of 12 hours on that hardware (without building gcj). I tried this with 3.3.4 and 3.4.3 now, both do about the same. In some mailing list archive I have found a hint to use bash for CONFIG_SHELL instead of the default AIX ksh, but this does not help much. The build process for 3.3.4 (a c and c++ only build) was successful otherwise. I'm still running the 3.4.3 bootstrap since about 18 hours now... The CPU load is less than 0.5 most of the time and topas reports a disk write rate of 1.5MB/sec _continuously_. Other autoconf-based packages used to configure within normal time frames, so I suspect there might be some special settings used in the gcc build process. -- Summary: configure scripts run incredibly slow when bootstrapping on AIX Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: critical Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rumi at rtfm dot hu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-ibm-aix5.2.0.0 GCC host triplet: powerpc-ibm-aix5.2.0.0 GCC target triplet: powerpc-ibm-aix5.2.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18422
[Bug c++/18416] [4.0 regression] ICE in import_export_decl
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 22:46 --- I could not reproduce it either on powerpc-darwin but could with a cross to ia64-*-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18416
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-10
22:50 ---
Testcase reduced from the mesa context.c file.
Compiling this with -O2 segfaults on linux-powerpc64 segfaults.
typedef unsigned int size_t;
extern void *malloc (size_t __size) __attribute__ ((__malloc__));
extern void abort(void);
struct _abc {
int ebc;
};
void xxx ( float rscale,
float gscale,
float bscale,
float ascale)
{
struct _abc *vis;
if (rscale 255.0) abort();
if (gscale 255.0) abort();
if (bscale 255.0) abort();
if (ascale 255.0) abort();
vis = (struct _abc *) malloc(sizeof(struct _abc) );
if (rscale==255.0F gscale==255.0F
bscale==255.0F ascale==255.0F) {
vis-ebc = 1;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 22:57 --- Confirmed, also happens on powerpc-darwin with -O2 -fPIC. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet|powerpc64-linux |powerpc64-linux, powerpc- ||darwin Last reconfirmed|-00-00 00:00:00 |2004-11-10 22:57:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 23:04 --- Hmm, someone did an emit_rtx and did not end_sequence as the insn looks like: (insn 143 0 0 (set (nil) (reg:CC 75 cr7)) -1 (nil) (nil)) -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 23:45 --- I was wrong in the sense that is the right RTL except that nill is wrong and is being overwritten. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug bootstrap/18422] configure scripts run incredibly slow when bootstrapping on AIX
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18422
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 23:49 --- in gen_reload, we do: emit_insn (gen_rtx_SET (VOIDmode, out, in)); but somehow the set gets changed for the out to be nil. Note out and in are correct here. After this we don't get the correct insn in the sequence at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10 23:58 --- Never mind my comment about emit_insn (gen_rtx_SET because we are not calling that but 7530emit_insn (gen_move_insn (out, in)); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 00:04 --- The bug is in emit_move_insn_1, we set the out side to null for some reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug tree-optimization/18419] [4.0 Regression] tree-ssa aliasing slow
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-11 00:05 --- Note that the number of computed gotos shouldn't matter much, we factor computed gotos to have a single common computed jump. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18419
[Bug tree-optimization/18419] [4.0 Regression] tree-ssa aliasing slow
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-11 00:29 --- You could try an sbitmap for ai-ssa_names_visited in tree-ssa-alias, and a pointer_set for visited in walk_use_def_chains_1. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-11 00:29:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18419
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 00:30 --- We used to change the mode to CC from CCFP but now we don't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11
00:31 ---
This is the rtl we used to produce:
(insn 144 69 75 8 (set (reg:CC 75 cr7)
(reg:CC 30 r30 [125])) 336 {*movcc_internal1} (nil)
(nil)) -- this the insn which we are messing up now.
(jump_insn:HI 75 144 80 8 (set (pc)
(if_then_else (ne (reg:CCFP 75 cr7)
(const_int 0 [0x0]))
(label_ref 115)
(pc))) 527 {*rs6000.md:13676} (insn_list:REG_DEP_ANTI 67
(insn_list:REG_DEP_ANTI 69
(insn_list:REG_DEP_ANTI 68 (nil
(expr_list:REG_BR_PROB (
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 00:34 --- Found the patch which caused the problem: * simplify-rtx.c (simplify_gen_subreg): Fail if simplify_subreg has failed when passed a hard register. -- What|Removed |Added CC||uweigand at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug libstdc++/16371] [3.4/4.0 Regression] libstdc++ fails for crosses
--- Additional Comments From wilson at specifixinc dot com 2004-11-11 00:40 --- Subject: Re: [3.4/4.0 Regression] libstdc++ fails for crosses On Wed, 2004-11-10 at 13:11, mg_gentoo at yahoo dot com wrote: --- Additional Comments From mg_gentoo at yahoo dot com 2004-11-10 21:11 --- Jim, you expressed an interest in this bug a while back Maybe on the gcc list? I don't recall this PR, and don't see any comments from me in the the PR. I think the key detail here is that you have to have a target C library before you can build a target libstdc++. Of course, if you are bootstrapping a build environment, then you need the target gcc before you can build the target C library. This gets tricky when glibc is involved. You need to first install the glibc headers so you can build libgcc. Then you do a partial gcc build. You build only the compiler and libgcc without the libraries like libstdc++. Then you use gcc to build a provisional glibc. Then you can build a full gcc including libstdc++. Then you build a full glibc. Then See Dan Kegel's crosstool that automatically does this for you. http://kegel.com/crosstool/ If you don't want to go through all of the trouble of bootstrapping an entire build environment, there is a much simpler way to do this. Use a sys-root. The sys-root must include header files and libraries for the target. Gcc will then be able to find them, and link tests will work, and libstdc++ will configure OK. If libstdc++ won't configure, then something is missing from your sys-root. There is another way to solve this problem which is to hand-code in answers to all of the questions that the libstdc++ configure script asks. This is what crossconfig.m4 tries to do. However, I doubt that this is kept up to date. Every time the configure script changes, the answers in crossconfig.m4 need to change to keep up to date. For most targets, no one bothers to do that, and hence this is likely always out of date. Since there are other better ways to get a cross compiler built, this is probably not worth the trouble. One of the problems with providing hand-coded answers is that the answers can be wrong if someone has a system with non-standard packages on it. So this is usually a solution of last resort. It may be worthwhile for some targets though. Note that we use this same trick in libiberty, but there we don't have a choice because libiberty has to be buildable without a C library. This is must simpler to do though, as there are fewer questions asked by the libiberty configure script, and the list of questions rarely changes, and the answers to those questions also rarely change. I would guess that the gentoo configure problem is because the host OS does not have a multilibbed C library. If the x86_64 gentoo system does not have both the 32-bit and 64-bit C libraries in /lib, then one of the multilibbed libstdc++ builds will fail to link, and you end up with the same cross-compiler problem. This has to be fixed as above, e.g. you must provide a multilibbed glibc before you can do a multilibbed gcc build, or else you have to build gcc/glibc together as per Dan Kegel's crosstool. Incidentally, the error message referring to GCC_NO_EXECUTABLES is a misnomer. This gets printed if gcc_no_link is true, and GCC_NO_EXECUTABLES does set gcc_no_link. However, gcc_no_link also gets set by AC_PROG_CC which is the standard autoconf test for determining whether the C compiler works. If autoconf determines that the C compiler can not link, then it sets gcc_no_link. This explains why a native build can see this cross-compiler problem. AC_PROG_CC fails to link if there is something missing from your compiler environment, which as I explained above, is most likely a missing C library. I am not convinced that there is any bug here. I think the only problem is people not understanding how to do cross compiler builds, which can be much more complicated than native builds. My company has recently done cross compiler builds for linux from gcc-3.4 and we didn't have any problem. Many inexperienced gcc developers have been able to build linux cross compilers by using Dan Kegel's scripts. Hence I don't believe there is any real bug here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 00:47 --- This patch fixes it: Index: simplify-rtx.c === RCS file: /cvs/gcc/gcc/gcc/simplify-rtx.c,v retrieving revision 1.207 diff -u -p -r1.207 simplify-rtx.c --- simplify-rtx.c 28 Oct 2004 12:47:21 - 1.207 +++ simplify-rtx.c 11 Nov 2004 00:47:26 - @@ -3790,7 +3790,8 @@ simplify_gen_subreg (enum machine_mode o return newx; if (GET_CODE (op) == SUBREG || GET_MODE (op) == VOIDmode - || (REG_P (op) REGNO (op) FIRST_PSEUDO_REGISTER)) + || (REG_P (op) REGNO (op) FIRST_PSEUDO_REGISTER + GET_MODE_SIZE (innermode) != GET_MODE_SIZE (innermode))) return NULL_RTX; return gen_rtx_SUBREG (outermode, op, byte); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 01:04 --- Even though this patch fixes it, it is not the right fix as simplify_subreg should just return a change in the mode rather than return null. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug other/18423] New: powerpc-eabisim build broken due to configure skipping fixincludes
There was a change to configure proposed by Paolo Bonzini in September,
checked into configure.in by Aaron LaFramboise in October, and configure
(when it was regenerated to include his own patch) by HJ Lu in November
that prevents fixincludes from being built for powerpc-eabisim, causing
a build for that target, as described in simtest-howto.html, to fail.
The following hack to configure fixes it, but I don't know if it's
appropriate to skip libgcj for that target:
Index: configure.in
===
RCS file: /opt/gcc-cvs/gcc/configure.in,v
retrieving revision 1.331
diff -u -p -r1.331 configure.in
--- configure.in8 Nov 2004 01:27:56 - 1.331
+++ configure.in11 Nov 2004 00:38:11 -
@@ -683,6 +683,9 @@ case ${target} in
powerpc-*-eabi)
noconfigdirs=$noconfigdirs ${libgcj} build-fixincludes
;;
+ powerpc-*-eabisim)
+noconfigdirs=$noconfigdirs ${libgcj}
+;;
powerpc-*-eabi* | powerpcle-*-eabi* | powerpc-*-rtems* )
noconfigdirs=$noconfigdirs build-fixincludes
;;
I submitting this as a problem report rather than as a patch because I don't
know what's going on here at all, and would like someone who understands
this stuff to take a look at it.
The bug exists in today's mainline and is a regression.
--
Summary: powerpc-eabisim build broken due to configure skipping
fixincludes
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis187 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-eabisim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18423
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 01:49 --- The problem is that the register is r30 (which is the FRAME_POINTER_REGNUM) and reload is not complete at this point, maybe this is not the correct check. ((reload_completed !frame_pointer_needed) || (REGNO (op) != FRAME_POINTER_REGNUM #if HARD_FRAME_POINTER_REGNUM != FRAME_POINTER_REGNUM REGNO (op) != HARD_FRAME_POINTER_REGNUM #endif )) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug target/18394] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/execute/strct-pack-3.c
--- Additional Comments From hp at gcc dot gnu dot org 2004-11-11 01:50 --- Observed to work with Wed Nov 10 22:59:00 UTC 2004. (Observed to fail with Wed Nov 10 20:00:24 UTC 2004.) -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18394
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 02:04 --- Jan you added that code to simplify_subreg but I could not figure out why it was really added except that it effected x86_64 (when bootstrapped with -fomit-frame-pointer). Note in this case the mode the modes are the same size which is unlike the case you found. Reference: http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01737.html http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01729.html -- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug rtl-optimization/18420] [4.0 Regression] ICE compiling mesa at -O2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 02:10 --- The reason why we are not using r31 at least on darwin is because that is the PIC register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18420
[Bug c/18424] New: 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
3.4.3 generates code which may be ~6x+ slower and larger than 3.3.1 @ -0s
as it apparently no longer evaluates constant expression trees in anything
other than simple expressions for some reason, which may result in serious
performance and code size regressions, which should really be fixed if possible.
// 00c6 foo:
int foo ( int a ){
if (a (1L 23))
// c6: aa 27 eor r26, r26
// c8: 97 fd sbrcr25, 7
// ca: a0 95 com r26
// cc: ba 2f mov r27, r26
// ce: 27 e1 ldi r18, 0x17 ; 23
// d0: b6 95 lsr r27
// d2: a7 95 ror r26
// d4: 97 95 ror r25
// d6: 87 95 ror r24
// d8: 2a 95 dec r18
// da: d1 f7 brne.-12; 0xd0
// dc: 81 70 andir24, 0x01 ; 1
// de: 90 70 andir25, 0x00 ; 0
// e0: 89 2b or r24, r25
// e2: 19 f0 breq.+6 ; 0xea
return 1;
// e4: 81 e0 ldi r24, 0x01 ; 1
// e6: 90 e0 ldi r25, 0x00 ; 0
// e8: 08 95 ret
else
return 2 ;
// ea: 82 e0 ldi r24, 0x02 ; 2
// ec: 90 e0 ldi r25, 0x00 ; 0
}
// ee: 08 95 ret
// f0: 08 95 ret
// where the second return is odd as well?
vs GCC 3.3.1 @ -0s
// 00c6 foo:
int foo2 ( int a ){
if (a (1L 23))
return 1;
else
return 2 ;
}
// c6: 82 e0 ldi r24, 0x02 ; 2
// c8: 90 e0 ldi r25, 0x00 ; 0
// ca: 08 95 ret
(where for referance int targeted to avr is 16-bits wide,
but the above problem is not likely target sensitive.)
--
Summary: 3.4.3 ~6x+ performance regression vs 3.3.1, constant
trees not being computed.
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: critical
Priority: P1
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schlie at comcast dot net
CC: dmixm at marine dot febras dot ru,ericw at evcohs dot
com,gcc-bugs at gcc dot gnu dot org
GCC build triplet: any
GCC host triplet: any
GCC target triplet: avr-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11
02:48 ---
Here is an example for PPC:
int foo2 ( short a ){
if (a (1 23))
return 1;
else
return 2 ;
}
but it is not a regression on PPC with the above example
--
What|Removed |Added
Severity|critical|minor
Component|c |middle-end
Keywords||missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 02:49 --- I amost think the size of long changed for 3.4.0 for avr to 32bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 02:52 --- or the default for -mint8 changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug other/18423] [4.0 Regression] powerpc-eabisim build broken due to configure skipping fixincludes
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 03:02 --- Just like the cygwin one we don't need fixincludes at all because the headers always comes from newlib. -- What|Removed |Added CC||geoffk at gcc dot gnu dot ||org Keywords||build Summary|powerpc-eabisim build broken|[4.0 Regression] powerpc- |due to configure skipping |eabisim build broken due to |fixincludes |configure skipping ||fixincludes Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18423
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From schlie at comcast dot net 2004-11-11 03:15
---
Subject: Re: 3.4.3 ~6x+ performance regression vs
3.3.1, constant trees not being computed.
Yes but regardless of the size of the constant 1:
if (a (1L 24)) or (a (1 24)) yields the same results,
and further, if a simpler expression containing the same constant
Sub-expression is used, it properly computes the constant expression:
int foo (int a) {
a = a + (1 24); // apparently simple enough to compute (1 24)
if (a (1 24)) {// then utilized here, which yields 0
return 1;
else
return 2;
}
= return 2;
Which implies that it is not a back-end issue, but that (1 24)
is not being calculated as a constant expression if nested within
a more complex expression for some reason, I believe?
although the PPC may have optimized it away in other ways as it has
a more powerful shift instruction, but should not be a back-end thing,
as the embedded constant expression was properly computed and applied
in 3.3.x.
From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: 11 Nov 2004 02:49:28 -
To: [EMAIL PROTECTED]
Subject: [Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1,
constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11
02:49 ---
I amost think the size of long changed for 3.4.0 for avr to 32bits.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-11 03:17 --- When I did 1 24 I got a warning (at least on the mainline on a cross to avr) about 24 being greater than the size of int so it was going to be 0. Again in real terms there is something on here but I really doubt it is a regression and you did not use -mint8 for the 3.3 build and not for the 3.4 build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18424
[Bug libstdc++/16371] [3.4/4.0 Regression] libstdc++ fails for crosses
--- Additional Comments From mg_gentoo at yahoo dot com 2004-11-11 03:45 --- Well, the problem isn't inexperience (in my case anyway) so much as that a process which worked in the past does no longer since the introduction of certain new build magic (for the better, mind you) in 3.4. Since, I suppose, the process must adhere to stricter borders these days, I'll be more than happy to work through it from scratch (probably tomorrow or friday) to see where my existing environment and scripts have failed. Thank you for the input. I knew if I kept ccing more and more people that had something to do with this (albeit the better part of a year ago), I'd eventually find someone awake. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371
[Bug middle-end/18424] 3.4.3 ~6x+ performance regression vs 3.3.1, constant trees not being computed.
--- Additional Comments From schlie at comcast dot net 2004-11-11 03:55
---
Subject: Re: 3.4.3 ~6x+ performance regression vs
3.3.1, constant trees not being computed.
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote:
When I did 1 24 I got a warning (at least on the mainline on a cross to
avr) about 24 being greater
than the size of int so it was going to be 0. Again in real terms there is
something on here but I really
doubt it is a regression and you did not use -mint8 for the 3.3 build and not
for the 3.4 build.
Yes, you're correct, (1 24) generates warnings: (not forcing -mmint8)
main.c: In function `foo1':
main.c:3: warning: left shift count = width of type
main.c: In function `foo2':
main.c:12: warning: left shift count = width of type
main.c: At top level:
main.c:21: warning: return type of 'main' is not `int'
and produces the anticipated correct code, sorry for the confusion.
---
However as reported with (1L 24), it does not, nor should it yield
different results, but it appears to product the expected code only if
the same constant expression occurs in a simpler expression in the same
basic block: ?
File: main.lss:
main.elf: file format elf32-avr
Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00800100 011e 01b2 2**0
CONTENTS, ALLOC, LOAD, DATA
1 .text 011e 0094 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .bss 00800100 011e 01b2 2**0
ALLOC
3 .noinit 00800100 00800100 01b2 2**0
CONTENTS
4 .eeprom 0081 0081 01b2 2**0
CONTENTS
5 .stab 04c8 01b4 2**2
CONTENTS, READONLY, DEBUGGING
6 .stabstr 044e 067c 2**0
CONTENTS, READONLY, DEBUGGING
Disassembly of section .text:
__vectors:
0:0c 94 46 00 jmp0x8c
4:0c 94 61 00 jmp0xc2
8:0c 94 61 00 jmp0xc2
c:0c 94 61 00 jmp0xc2
10:0c 94 61 00 jmp0xc2
14:0c 94 61 00 jmp0xc2
18:0c 94 61 00 jmp0xc2
1c:0c 94 61 00 jmp0xc2
20:0c 94 61 00 jmp0xc2
24:0c 94 61 00 jmp0xc2
28:0c 94 61 00 jmp0xc2
2c:0c 94 61 00 jmp0xc2
30:0c 94 61 00 jmp0xc2
34:0c 94 61 00 jmp0xc2
38:0c 94 61 00 jmp0xc2
3c:0c 94 61 00 jmp0xc2
40:0c 94 61 00 jmp0xc2
44:0c 94 61 00 jmp0xc2
48:0c 94 61 00 jmp0xc2
4c:0c 94 61 00 jmp0xc2
50:0c 94 61 00 jmp0xc2
54:0c 94 61 00 jmp0xc2
58:0c 94 61 00 jmp0xc2
5c:0c 94 61 00 jmp0xc2
60:0c 94 61 00 jmp0xc2
64:0c 94 61 00 jmp0xc2
68:0c 94 61 00 jmp0xc2
6c:0c 94 61 00 jmp0xc2
70:0c 94 61 00 jmp0xc2
74:0c 94 61 00 jmp0xc2
78:0c 94 61 00 jmp0xc2
7c:0c 94 61 00 jmp0xc2
80:0c 94 61 00 jmp0xc2
84:0c 94 61 00 jmp0xc2
88:0c 94 61 00 jmp0xc2
008c __ctors_end:
8c:11 24 eorr1, r1
8e:1f be out0x3f, r1; 63
90:cf ef ldir28, 0xFF; 255
92:d0 e1 ldir29, 0x10; 16
94:de bf out0x3e, r29; 62
96:cd bf out0x3d, r28; 61
0098 __do_copy_data:
98:11 e0 ldir17, 0x01; 1
9a:a0 e0 ldir26, 0x00; 0
9c:b1 e0 ldir27, 0x01; 1
9e:ee e1 ldir30, 0x1E; 30
a0:f1 e0 ldir31, 0x01; 1
a2:02 c0 rjmp.+4 ; 0xa8
00a4 .do_copy_data_loop:
a4:05 90 lpmr0, Z+
a6:0d 92 stX+, r0
00a8 .do_copy_data_start:
a8:a0 30 cpir26, 0x00; 0
aa:b1 07 cpcr27, r17
ac:d9 f7 brne.-10 ; 0xa4
00ae __do_clear_bss:
ae:11 e0 ldir17, 0x01; 1
b0:a0 e0 ldir26, 0x00; 0
b2:b1 e0 ldir27, 0x01; 1
b4:01 c0 rjmp.+2 ; 0xb8
00b6 .do_clear_bss_loop:
b6:1d 92 stX+, r1
00b8 .do_clear_bss_start:
b8:a0 30 cpir26, 0x00; 0
ba:b1 07 cpcr27, r17
bc:e1 f7 brne.-8 ; 0xb6
be:0c 94 7c 00 jmp0xf8
00c2 __bad_interrupt:
c2:0c 94 00 00 jmp0x0
00c6 foo1:
int foo1 ( int a ){
if (a (1L 23))
c6:aa 27 eorr26, r26
c8:97 fd sbrcr25, 7
ca:a0 95
