[Bug target/19421] [4.0 regression] ICE with soft-float on m68k

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-26 08:07 --- Subject: Bug 19421 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-26 08:07:05 Modified files: gcc: ChangeLog tree-inline.c Log message

[Bug tree-optimization/19626] Aliasing says stores to local memory do alias

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 08:47 --- Subject: Re: Aliasing says stores to local memory do alias > D.2540 = (struct Loc<1> *) &dX.D.2210.D.2166.domain_m.buffer; > That confuses the aliasing mechanism > buffer is of type

[Bug middle-end/19600] [4.0 Regression] All acats tests fail

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-26 08:49 --- > Should be fixed by: > 2005-01-25 Ian Lance Taylor > > * gimple-low.c (block_may_fallthru): Correct handling of > SWITCH_EXPR--may fall through if SWITCH_LABELS is NULL. Yep. --

[Bug fortran/18565] gfortran: CONJG: false error message about standard violation

--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-26 09:08 --- The same bug happens with aimag (and, as far as I can see, for the same reasons): $ cat a.f90 program bug implicit none complex(8) x write(*,*) aimag(x) end $ gfortran -std=f95 a.f90 In file

[Bug target/19421] [4.0 regression] ICE with soft-float on m68k

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 09:18 --- Honza, did you add the wrong PR number? I think you mean 19241... -- What|Removed |Added

[Bug tree-optimization/19241] [4.0 Regression] ICE in make_decl_rtl with inliner

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 09:21 --- Fixed (including fixing the PR number in the ChangeLog ;-)) -- What|Removed |Added

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26 09:22 --- I have just run a Lapack test on ia64-unknown-linux-gnu, under the following conditions: I used the 20050123 snapshot with wide complex scaling, i.e. the fix for PR 19486 http://gcc.gnu.org/cgi-bin/cvs

[Bug middle-end/18902] Naive (default) complex division algorithm

--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26 09:32 --- The recent fixes in complex handling, and the scaled division algorithm, have eliminated the Lapack regressions with -O0 at least on ia64-unknown-linux-gnu (see http://gcc.gnu.org/bugzilla/show_bug.cgi?i

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26 09:42 --- At -O1 on ia64-unknown-linux-gnu, I still run into PR 18977 (segfault in xeigtsts). Pity. -- What|Removed |Added ---

[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization

-- What|Removed |Added OtherBugsDependingO||5900 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977

[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 10:00 --- Is there a test case someone can attach to this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977

[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 10:20 --- Bah, I hate profiles for "cc1plus -O2 ir.ii" without peaks: CPU: P4 / Xeon with 2 hyper-threads, speed 3194.17 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopp

[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 10:24 --- Subject: Re: [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code > Bah, I hate profiles for "cc1plus -O2 ir.ii" without peaks: > > CPU: P4 / Xeon with 2 hyper-thread

[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 10:24 --- Subject: Re: [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code > Bah, I hate profiles for "cc1plus -O2 ir.ii" without peaks: > > CPU: P4 / Xeon with 2 hyper-thread

[Bug c++/19076] Pointer to member function not matched to pointer to member template

--- Additional Comments From pcarlini at suse dot de 2005-01-26 10:25 --- New patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01627.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19076

[Bug c++/6628] cannot typedef const functions

--- Additional Comments From pcarlini at suse dot de 2005-01-26 10:27 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01627.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6628

[Bug target/19634] Infinite memory usage on Alpha

--- Additional Comments From giovannibajo at libero dot it 2005-01-26 10:30 --- Is this a regression? -- What|Removed |Added Component|middle-end |

[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code

--- Additional Comments From kgardas at objectsecurity dot com 2005-01-26 10:46 --- Subject: Re: [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code Just to note something about 4.0.0 and 3.4.2 memory usage while compiling ir.cc. 3.4.2: it is quickly gorwing up to

[Bug middle-end/18902] Naive (default) complex division algorithm

--- Additional Comments From pcarlini at suse dot de 2005-01-26 10:54 --- > This is a huge step. I think PR 18902 should now be considered > critical, at least for gfortran. Ok, I'll start on it immediately (after all, it's rather straightforward, now). Then the maintainers will decide

[Bug target/19636] New: Can't compile ethernut OS (avr-gcc)

Hi, I'm testing gcc version 4.0.0 20050123: avr-gcc -c -Os usart.i usart.c: In function 'UsartIOCtl': usart.c:821: error: unable to find a register to spill in class 'BASE_POINTER_REGS' usart.c:821: error: this is the insn: (insn 653 159 160 14 (set (mem:HI (plus:HI (reg/f:HI 28 r28)

[Bug target/19636] Can't compile ethernut OS (avr-gcc)

--- Additional Comments From dieterbmeier at yahoo dot com 2005-01-26 11:00 --- Created an attachment (id=8073) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8073&action=view) usart.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636

[Bug target/19634] [4.0 regression] Infinite memory usage on Alpha

--- Additional Comments From falk at debian dot org 2005-01-26 11:03 --- (In reply to comment #2) > Is this a regression? Yes, g++ 3.4 compiles this fine , and 3.3 too if I s/class/struct/. -- What|Removed |Added

[Bug target/19634] [4.0 regression] Infinite memory usage on Alpha

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 11:16 --- Is this a recent problem, ie. any idea when this started to FAIL? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19634

[Bug target/19634] [4.0 regression] Infinite memory usage on Alpha

--- Additional Comments From falk at debian dot org 2005-01-26 11:17 --- Whoops. -- What|Removed |Added Version|3.0 |4.0.0 http://gcc.g

[Bug target/19634] [4.0 regression] Infinite memory usage on Alpha

--- Additional Comments From falk at debian dot org 2005-01-26 11:23 --- (In reply to comment #4) > Is this a recent problem, ie. any idea when this started to FAIL? With 20041209, I get a segfault. With 20050116 or 20050120, I get the infinite loop. I don't have any other old versions

[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 11:36 --- It would be a Good Thing to look at the hash function. The number of collisions per search is extremely high: String pool entries 128928 identifiers 128928 (100.00%) slots 262144 bytes

[Bug c/19635] static nested function workaround for -Wmissing-declarations (see bug #1517) no longer works

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 11:57 --- No static means something werid in nested functions (really it means nothing so that is why it was removed). The correct way to fix the missing declarations warning is the following: int main (void) { i

[Bug target/19636] Can't compile ethernut OS (avr-gcc)

-- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636

[Bug java/19473] rhug build problem, regression?

--- Additional Comments From timo dot lindfors at iki dot fi 2005-01-26 12:16 --- Works fine with 2005-01-25 here too. Seems somebody already fixed this. -- What|Removed |Added --

[Bug java/19473] rhug build problem, regression?

-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19473

[Bug tree-optimization/19637] New: Missed constant propagation with placement new

For the following testcase with three similar functions we do different tree optimizations: #include struct Foo { Foo() { i[0] = 1; } int i[2]; }; int foo_char(void) { int i[2]; new (reinterpret_cast(i)) Foo(); return reinterpret_cast(i)->i[0]; } int foo

[Bug tree-optimization/19637] Missed constant propagation with placement new

-- What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/s

[Bug other/19638] New: GNU assembler command line failure

The new option --alternate is handled incorrect. If I issue a command like this: > powerpc-eabi-elf-as -mregnames -o a.o -ahl=a.lst a.s then a.s is assembled OK and the list goes to a.lst. If I write this: (leaving out -a sub-options) > powerpc-eabi-elf-as -mregnames -o a.o -a=a.lst a.s then I get

[Bug other/19638] GNU assembler command line failure

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 13:45 --- GCC does not control the assembler, report it to the binutils: . -- What|Removed |Added

[Bug tree-optimization/19639] New: Funny (horrible) code for empty destructor

The following simple testcase struct Foo { ~Foo() {} int i; }; struct NonPod { Foo foo[2]; }; void foo(void) { NonPod x; } produces(!) at -O2 _Z3foov: .LFB5: pushl %ebp .LCFI0: movl%esp, %ebp .LCFI1: subl$16, %esp .LCFI2: leal-2(%ebp), %edx

[Bug c++/19640] New: ICE when using the "(type) {...}" syntax array constructor expression syntax

In C++ mode (not in C) this code invariably creates an ICE (segmentation fault): typedef int matrix[4]; matrix foo = (matrix) {1,2,3,4}; This one does too: int mat[1] = (int[1]) {2}; While removing the "(type)" part makes it compile perfectly: typedef int matrix[4]; matrix foo = {1,2,3,4}; int

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 13:57 --- Well there are multiple problems in this bug. One is that empty loops are not removed (PR 17640). The only problem Another is that we don't fold "(&x.foo[2] == &x.foo)" to false And "&x.foo[2] - 4B" to "&x.

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 14:10 --- We can also not fold &i[0] == &i[1] to false in int foo(void) { int i[2]; if (&i[0] == &i[1]) return 1; return 0; } or i+0 == i+1 which is transf

[Bug c++/16042] [3.3/3.4/4.0 regression] ICE with array assignment

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:11 --- Actually this was accepted for 3.2.3 (and earlier versions of 3.3.x) The ICE started: Search converges between 2003-06-03-trunk (#253) and 2003-06-04-trunk (#254). But note 3.3.3 produced wrong code but 3.

[Bug c++/19640] [3.3/3.4/4.0 Regression] ICE when using the "(type) {...}" syntax array constructor expression syntax

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:12 --- The ICE started: Search converges between 2003-06-03-trunk (#253) and 2003-06-04-trunk (#254). But note 3.3.3 produced wrong code but 3.3.1 produced correct code. 3.3.x regressed between 20040128 and 20040

[Bug c++/16042] [3.3/3.4/4.0 regression] ICE with array assignment

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:12 --- *** Bug 19640 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug tree-optimization/19641] New: &a[0] == &a[1] is not folded.

int foo(void) { int i[2]; if (&i[0] == &i[1]) return 1; return 0; } We should get 0. -- Summary: &a[0] == &a[1] is not folded. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: missed-optimizat

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:17 --- (In reply to comment #2) > We can also not fold &i[0] == &i[1] to false in I filed PR 19641 for that. -- What|Removed |Added -

[Bug tree-optimization/19641] &a[0] == &a[1] is not folded.

-- What|Removed |Added OtherBugsDependingO||19639 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19641

[Bug tree-optimization/19641] &a[0] == &a[1] is not folded.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:18 --- Woops I knew I had filed this before. *** This bug has been marked as a duplicate of 15791 *** *** This bug has been marked as a duplicate of 15791 *** -- What|Removed

[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:18 --- *** Bug 19641 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15791

[Bug tree-optimization/19639] Funny (horrible) code for empty destructor

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:19 --- (In reply to comment #3) > (In reply to comment #2) > > We can also not fold &i[0] == &i[1] to false in > I filed PR 19641 for that. Actually I had already file PR 15791 for that. -- What|Re

[Bug c++/19642] New: streaming doubles is very slow compared to sprintf

$ g++ -v Configured with: ../gcc-3.4.2/configure --prefix=/tools/pkg/gcc/3.4.2 --enable- languages=c,c++ --with-ld=/bin/ld --with-as=/bin/as --disable-threads Thread model: aix gcc version 3.4.2 /// t.cc #include #include using namespace std; int main( int argc, char** argv ) { std::ios_bas

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

-- What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642

[Bug libstdc++/17140] Floating point output is slow

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:34 --- *** Bug 19642 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:34 --- *** This bug has been marked as a duplicate of 17140 *** -- What|Removed |Added

[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 14:35 --- Could we, in general, fold &a[i] TRUTHOP &a[j] to i TRUTHOP j? I guess the only special case would be for sizeof(a[i]) == 0 -- but that is not allowed by the standard? I'll be wading t

[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 14:38 --- (In reply to comment #5) > Could we, in general, fold &a[i] TRUTHOP &a[j] to i TRUTHOP j? I guess the > only special case would be for sizeof(a[i]) == 0 -- but that is not allowed > by the standard? I'll

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

--- Additional Comments From pcarlini at suse dot de 2005-01-26 14:47 --- Wait a minute... Ok, we have got 17140, but here, if the issue is confirmed, we are talking about 2 orders of magnitude!?!?! Indeed, on my P4-2400 (gcc3.4.3, actually, similar bevavior for mainline) I cannot confi

[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 14:54 --- Subject: Re: fold misses that two ADDR_EXPR of an arrary obvious not equal On 26 Jan 2005, pinskia at gcc dot gnu dot org wrote: > (In reply to comment #5) > > Could we, in general, f

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

-- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26 15:00 --- I took some backtraces during a longer run of the program and most of the time it looked like this: (I removed some templates to make it readable) __issetuid load_locale setlocale int std::__convert_fr

[Bug middle-end/19616] [4.0 regression] missed tail call

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-26 15:08 --- Subject: Bug 19616 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-26 15:08:51 Modified files: gcc: ChangeLog calls.c tree-tailcall.c tre

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

--- Additional Comments From pcarlini at suse dot de 2005-01-26 15:10 --- Honestly, this doesn't help much, the percentages are important: suppose, for some reason, setlocale is very slow on AIX... Is _GLIBCXX_USE_C99 defined, on AIX? I'm asking because internally __convert_from_v uses s

[Bug middle-end/19616] missed tail call

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 15:12 --- No longer a regression. Probably when PR19633 is fixed we can look into doing even more tail calls. But that's just an enhancement. -- What|Removed |Added --

[Bug middle-end/16585] current_function_has_computed_jump incorrectly changed in make_edges

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 15:16 --- We can just zap it completely, of course: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01892.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16585

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26 15:18 --- Ok, lets say I took 100 backtraces and got 99 times this one. I hope this is enough percentage. _GLIBCXX_USE_C99 is defined -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19642

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-26 15:21 --- Subject: Bug 19515 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-26 15:20:53 Modified files: gcc: ChangeLog expr.c gimplify.c tree.h A

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

--- Additional Comments From pcarlini at suse dot de 2005-01-26 15:22 --- > Ok, lets say I took 100 backtraces and got 99 times this one. I hope this is > enough percentage. ;) No, I mean *relative* percentages: setlocal in your profile is on top, higher than __convert_from_v and every

[Bug middle-end/19515] [4.0 Regression] Violation of C99 6.7.8 §21 for unions

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 15:24 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization

--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26 15:26 --- (In reply to comment #8) > Is there a test case someone can attach to this bug? I'm working on it. The error vanishes if slasy2.f is compiled with -O0, which is at least a start. An equivalent error

[Bug objc/18862] [4.0 Regression] ICE on gcc-4.0-20041205/gcc/testsuite/objc.dg/selector-1.m

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 15:28 --- Patch here: and it looks correct too. -- What|Removed |Added -

[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 15:30 --- Ok - I guess it's ARRAY_REFs that are not folded ;) So the summary could be "fold misses that two ARRAY_REFs with different offset of the same arrary are obviously not equal". But I'm

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

--- Additional Comments From pcarlini at suse dot de 2005-01-26 15:37 --- For reference, on linux, a typical profile (count = 1000) begins as follows, and: 1- The various snprintf are on top. 2- uselocale (the thread safe equivalent of setlocale) is way below Therefore, we can easily

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26 15:41 --- > ;) No, I mean *relative* percentages: setlocal in your profile is on top, higher > than __convert_from_v and everything else. I'm asking: is consuming 1%, 10%, or > 99% of the total runtime? Doesn't

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

--- Additional Comments From pcarlini at suse dot de 2005-01-26 15:45 --- > Doesn't a function that is on 99% of all call stacks automatically consume > 99% > of the runtime? Ok, the time can also be spend in the childs like here in > __issetuid, but this is an implementation detail o

[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 15:47 --- Hmm. Seems to only happen with -march=pentium3, and not -march=pentium4... -- What|Removed |Added ---

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-01-26 16:00 --- If it helps you, here the first lines of prof. But in practice some backtraces help me a lot more than a a [g]prof output. Its very fast in finding big bottlenecks, like setlocale in this PR. count =

[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 16:16 --- Umm, no. We fold the ARRAY_REF comparison to PLUS_EXPR(ADDR_EXPR, INTEGER_CST) == PLUS_EXPR(ADDR_EXPR, INTEGER_CST) oh well ;) So I guess transforming &a + i truth_op &a + j to i trut

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

--- Additional Comments From pcarlini at suse dot de 2005-01-26 16:17 --- > If it helps you, here the first lines of prof. But in practice some > backtraces > help me a lot more than a a [g]prof output. Its very fast in finding big > bottlenecks, like setlocale in this PR. Ok, thank

[Bug c++/14950] [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0

--- Additional Comments From jeanmichel dot gilbert at videotron dot ca 2005-01-26 16:22 --- There is more to this bug than the compilation of code specified always_inline at -O0. I have some template code that compiles fine at -O2 but gives lots of inlining warning at -O1. Without templ

[Bug c++/14950] [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0

--- Additional Comments From jeanmichel dot gilbert at videotron dot ca 2005-01-26 16:23 --- Sorry I meant above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950

[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization

--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26 17:23 --- Here we go: $ cat sl-error.f implicit none real x(2,2) call foo(x) end subroutine foo(x) real x(2,2) real tmp(4), t16(4,4), btmp(4),temp DO 120 I = 1, 4

[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 17:24 --- Hmm, it seems it causes stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-proto

[Bug middle-end/16585] current_function_has_computed_jump incorrectly changed in make_edges

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-26 17:26 --- Subject: Bug 16585 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-26 17:26:36 Modified files: gcc: ChangeLog cfgbuild.c function.h sched

[Bug middle-end/16585] current_function_has_computed_jump incorrectly changed in make_edges

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 17:27 --- zap. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug rtl-optimization/15242] [3.3/3.4/4.0 regression] pessimization of "goto *"

-- Bug 15242 depends on bug 16585, which changed state. Bug 16585 Summary: current_function_has_computed_jump incorrectly changed in make_edges http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16585 What|Old Value |New Value

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

--- Additional Comments From pcarlini at suse dot de 2005-01-26 17:34 --- FWIW, the issue doesn't affect linux even if configured --enable-clocale=generic (thus using setlocale). Therefore, on *some* targets setlocale is slow and causes it, not everywhere. -- http://gcc.gnu.org/bugz

[Bug libstdc++/19642] streaming doubles is very slow compared to sprintf

-- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-

[Bug c++/19199] [3.3/3.4/4.0 Regression] Wrong warning about returning a reference to a temporary

--- Additional Comments From amylaar at gcc dot gnu dot org 2005-01-26 18:02 --- Is the folowing the same bug? extern void abort (void); int i0 = 999; int *const p = &i0; int const *const & foo () { return p; } int main () { int i = *foo (); if (i != i0) abort (); return

[Bug tree-optimization/15791] fold misses that two ADDR_EXPR of an arrary obvious not equal

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 18:03 --- Fails without the patch, too, with the same error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15791

[Bug tree-optimization/19643] New: "0 % variable" isn't optimized to 0

Consider the following testcase, reduced from cfgexpand.c: int foo (int align) { int off = 0 % align; return off ? align - off : 0; } tree-level: foo (align) { int off; int D.1120; : off = 0 % align; if (off != 0) goto ; else goto ; :; D.1120 = 0; goto (); :; D.1120 = align

[Bug tree-optimization/19643] "0 % variable" isn't optimized to 0 at tree level

-- What|Removed |Added Summary|"0 % variable" isn't|"0 % variable" isn't |optimized to 0 |optimized to 0 at tree level http://gcc.

[Bug middle-end/18008] [4.0 Regression] Duplicate mask on bitfield insertion

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 18:11 --- Tricky. Part the first, I thought, is that the mode of the FIELD_DECL doesn't match the mode of the FIELD_DECL's type. Except that doesn't actually appear to matter. I shall fix it anyway. As for combine, th

[Bug tree-optimization/19643] "0 % variable" isn't optimized to 0 at tree level

--- Additional Comments From kazu at cs dot umass dot edu 2005-01-26 18:25 --- Exactly the same pattern appears in function.i. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19643

[Bug tree-optimization/18134] computed goto and if statement

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 18:32 --- With the patch attached to PR18133 we get: foo: xorl%eax, %eax cmpl$0, 4(%esp) setne %al ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18134

[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)

-- What|Removed |Added AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED

[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 18:40 --- Sorry, but this appears to be unfixable without a complete rewrite of MMX support. Everything I tried had side effects where MMX instructions were used when we were not using MMX intrinsics. -- Wh

[Bug tree-optimization/19644] New: ICE: in reload_cse_simplify_operands, at postreload.c:391

I build gcc from the actual snapshot gcc-4.0-20050123. When I compile our sources I get an ICE. This ICE doesn't occur if I use gcc from last week (gcc-4.0-20050116). Michael Cieslinski g++ -c -O2 -march=opteron -o MetisImageInterface2_diagnostics.o MetisImageInterface2_diagnostics.ii ../../../

[Bug tree-optimization/19643] "0 % variable" isn't optimized to 0 at tree level

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 18:50 --- Hmm, interesting. Confirmed. -- What|Removed |Added Status|UNCONFIRMED

[Bug tree-optimization/19644] ICE: in reload_cse_simplify_operands, at postreload.c:391

--- Additional Comments From micis at gmx dot de 2005-01-26 18:52 --- Created an attachment (id=8076) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8076&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19644

[Bug tree-optimization/19644] ICE: in reload_cse_simplify_operands, at postreload.c:391

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-26 18:55 --- I think this is a duplicate of bug 19584 which is already fixed in a later version of 4.0.0, could you try the latest CVS version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19644

[Bug c++/18370] [3.4/4.0 Regression] cp_parser_initializer_list uninit variable problems

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-26 18:59 --- Subject: Bug 18370 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-26 18:59:04 Modified files: gcc/cp : ChangeLog Log message: Add

[Bug tree-optimization/19644] ICE: in reload_cse_simplify_operands, at postreload.c:391

--- Additional Comments From micis at gmx dot de 2005-01-26 19:03 --- Behind the firewall here I have no cvs access. But I will try it with next weeks snapshot. MIchael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19644

[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization

--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-01-26 19:07 --- Thomas, Your reduce test case compiles and runs fine on amd64-*-freebsd6.0. This must be a target bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977

  1   2   >