[Bug rtl-optimization/19680] [missed-optimization] gcc4 is really reluctant to use fancy x86 addressing modes

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 07:45 --- That said, what are you expecting here for massage48? On K8, the latency of imul for a 32-bit register operand is 3 cycles. Alternately, we can break this down into leal (%eax,%eax,2), %eax sall $4, $ea

[Bug rtl-optimization/19680] [missed-optimization] gcc4 is really reluctant to use fancy x86 addressing modes

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 07:30 --- No, Steven, this is a different problem. Note that there are not two memory references, as in the other PR. -- What|Removed |Added --

[Bug target/19672] Performance regression in simple loop code

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 06:39 --- Hmm, this looks like a branch cost problem or related to that. I think you can get all the speed back by supplying -mbranch-cost=1 but I could be wrong. Hmm, I wonder if 3.2.x was compiled for i486 (or i3

[Bug rtl-optimization/19705] Cannot turn off doloop optimization via -fno-branch-count-reg if -fno-ivopts is also supplied

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 06:08 --- Werid it is combine which is doing it. Hmm and this is not a regression. Either the documention needs updating or the targets need to turn off these patterns when -fno- branch-count-reg is supplied. --

[Bug rtl-optimization/19705] New: [4.0 Regression] cannot turn off doloop optimization via -fno-branch-count-reg if -fno-ivopts is also supplied

Hmm, this is werid, why cannot I turn off doloop optimization with the -fno-branch-count-reg when I also turn off ivopts? I should be able to when I want to look at the interaction between those two optimizations (options). Testcase: int foo (int x) { int i= x; do { x *= 2;

[Bug target/19704] ICE for tail call of regparm 3 and dllimport

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 05:37 --- Here is the reduced testcase which shows that it has nothing to do with C++ methods at all but just tail call and regparm 3 and dllimport: __declspec(dllimport) void __attribute__ ((regparm(3))) assign(co

[Bug tree-optimization/19703] [4.0 Regression] Poor optimisation of loop test, DOM causing unsigned to int and missing combine compares

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 05:25 --- Confirmed (sorry about that I was thinking of something different at the time). Here is a better example for normal targets (PPC and x86 too): extern void foo6(int); void testloop6 (void) { int i; i = 10

[Bug tree-optimization/19703] Poor optimisation of loop test

--- Additional Comments From andrewhutchinson at cox dot net 2005-01-30 04:58 --- Subject: Re: Poor optimisation of loop test I am not sure what makes you think that. Compare with ZERO is invariabley cheaper than compare with "n". The former is "free" sign status following any conditi

[Bug target/19704] New: regparm vs dllimport of C++ methods

C++ methods that have both dllimport and regparm(3) can result in "unable to find a register to spill in class 'CREG'" error message when compiled at -O2 or -Os This causes windows port of Mozilla to fail as reported at: https://sourceforge.net/tracker/? func=detail&atid=102435&aid=1112123&group

[Bug target/19690] ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387

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

[Bug target/19690] ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 04:40 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug tree-optimization/18048] [4.0 Regression] mgrid loop performance regression with ivopts (register pressure)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 04:36 --- PR 19701 is an example of where ivopts causes a regression in that we create too many IVs. -- What|Removed |Added ---

[Bug middle-end/19698] [4.0 regression] Infinite loop in update_life_info

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 04:09 --- This testcase might or might not also cause the problem on before the tree-ssa merge but it is the reduced from .optimize tree dump: void FFT(int NumSamples, float *RealOut, float ar1) { int i5, n, j, i,

[Bug middle-end/19698] [4.0 regression] Infinite loop in update_life_info

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 03:30 --- And here is the interesting part, PRE does not move a redundant expression out of a loop (well it does but it is only out of the inner most loop). Confirmed, reduced testcase, doing -fno-tree-PRE causes u

[Bug tree-optimization/19703] Poor optimisation of loop test

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 03:17 --- (In reply to comment #1) > Hmm, on most targets it is true that != is the same case as >=. s/case/cost/. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19703

[Bug tree-optimization/19703] Poor optimisation of loop test

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 03:17 --- Hmm, on most targets it is true that != is the same case as >=. -- What|Removed |Added

[Bug target/19690] ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-30 03:15 --- Subject: Bug 19690 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-30 03:14:52 Modified files: gcc: ChangeLog gcc/config/i386: i

[Bug c/19703] New: Poor optimisation of loop test

Missed optimization gcc version 4.0.0 20041205 (experimental) 4.0.0/cc1.exe -quiet -v looprv.c -quiet -dumpbase looprv.c -mmcu=atmega169 -auxbase looprv -Os -Wall -version -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -o looprv.s Down counting loop, uses expensive compare EQ (-

[Bug target/19700] ICE in final_scan_insn with O1 -g -march=athlon-xp -mfpmath=sse

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

[Bug target/19690] ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387

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

[Bug middle-end/19698] [4.0 regression] Infinite loop in update_life_info

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 02:43 --- (In reply to comment #2) > This is broken since the tree-ssa merge. Then this most likely just a latent bug and you can generate a testcase which fails before the tree-ssa merge. I will try to reduce th

[Bug middle-end/19689] [4.0 Regression] ICE in store_bit_field, at expmed.c

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 02:35 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug middle-end/19689] [4.0 Regression] ICE in store_bit_field, at expmed.c

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-30 02:34 --- Subject: Bug 19689 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-30 02:33:28 Modified files: gcc: ChangeLog expr.c Added files:

[Bug middle-end/19698] [4.0 regression] Infinite loop in update_life_info

--- Additional Comments From schwab at suse dot de 2005-01-30 02:33 --- This is broken since the tree-ssa merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19698

[Bug middle-end/19687] [4.0 Regression] ICE with union initializer

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-30 02:17 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug middle-end/19687] [4.0 Regression] ICE with union initializer

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-30 02:13 --- Subject: Bug 19687 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-30 02:13:47 Modified files: gcc: ChangeLog expr.c Added files:

[Bug middle-end/19702] suboptimal multiple branch comparison code produced

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 02:03 --- Confirmed. The problem is that fold changes "k < 300" to "k <= 299". -- What|Removed |Added

[Bug tree-optimization/19701] [4.0 regression] Way too many IVs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 01:55 --- (In reply to comment #4) > Also happens on x86-64, but not on x86. Well the IV selection on x86 is not good either. *(long long unsigned int *) d.18 = 0; D.1187 = (long long unsigned int *) ivtmp.4 + (

[Bug rtl-optimization/19702] New: suboptimal multiple branch comparison code produced

When two comparisons immediately follow each other that compare same numbers but branch twice based on 3 possible comparison outcomes actual comparison is performed twice in asm code. One comparision suffices. Also if second branches are strongly disadvantaged even pre-jxx mov for each branch shou

[Bug tree-optimization/19701] [4.0 regression] Way too many IVs

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-30 01:33 --- Also happens on x86-64, but not on x86. -- What|Removed |Added CC|

[Bug tree-optimization/19701] [4.0 regression] Way too many IVs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 01:12 --- Here is the .optimizate dump for -fno-ivopts (the most optimial code): { : if (w > 63) goto ; else goto ; :; *(long long unsigned int *) d = 0; *(long long unsigned int *) (d + 8B) = 0; *(long long

[Bug tree-optimization/19701] [4.0 regression] Way too many IVs

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-30 01:08 --- Confirmed, also happens on powerpc-darwin (This might be the one of the reasons why SPEC is slower on the mainline on some tests with -fivopts turned on). Yes this is one of the few true iv-opts problems.

[Bug tree-optimization/19701] [4.0 regression] Way too many IVs

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-30 00:55 --- Can you add a tree dump and the output with -fno-ivopts? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19701

[Bug tree-optimization/19701] New: [4.0 regression] Way too many IVs

GNU C version 4.0.0 20050120 (experimental) (alphaev68-unknown-linux-gnu) Test case: void fbSolidFillmmx(int w, unsigned char *d) { while (w >= 64) { *(unsigned long long *) (d + 0) = 0; *(unsigned long long *) (d + 8) = 0; *(unsigned long long *) (d + 16) = 0;

[Bug libstdc++/19656] libstdc++ testsuite results differ if bootstrap gcc 4.0 using some gcc 4.0 version or early (gcc 3.4.3) gcc version at FreeBSD

--- Additional Comments From wanderer at rsu dot ru 2005-01-29 23:49 --- Result my "find the exact configuration patch that broke this": gcc mainline bootstraped using FreeBSD 5.3 system compiler (gcc 3.4.2) display error "cc1: no iconv implementation, cannot convert from ISO8859-1 to

5000 € PAR MOIS!..3 h par jour!!..VOUS INTERESSE???

En démarrant aujourd’hui, en travaillant sérieusement, vous pourrez tirer immédiatement avantage des bénéfices et atteindre les objectifs suivants : 1. Les meilleurs gagnent 5.000 €/mois à temps partiel. 2. Les meilleurs gagnent 10.000 €/mois à temps complet. 3. Tous vos clients vous paient cash

[Bug ada/19489] gnat tools not buildable cross

--- Additional Comments From laurent at guerby dot net 2005-01-29 22:39 --- Since it is clearly a regression (vs 3.2 cross RTEMS/Ada capabilities), would you mind proposing a patch to current 4.0 libada? I've included Arnaud in CC. -- What|Removed |Ad

[Bug ada/19489] gnat tools not buildable cross

--- Additional Comments From neroden at gcc dot gnu dot org 2005-01-29 22:19 --- >You may try adding a gnattools directory, whose makefile and configury is based >on libada's, but which is a host module rather than a target module. Correct (dammit). :-) I've already do

[Bug middle-end/19689] [4.0 Regression] ICE in store_bit_field, at expmed.c

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

[Bug middle-end/19687] [4.0 Regression] ICE with union initializer

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

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

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 21:19 --- As(In reply to comment #7) > Or we could simply unroll the loop completely, but while SCEV finds > the IV as Again this is most likely because fold does not fold "&x.foo[2] - 4B" to "&x.foo[0]", or someone

[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-29 21:14 --- Or we could simply unroll the loop completely, but while SCEV finds the IV as (set_scalar_evolution (scalar = this_6) (scalar_evolution = {(struct Foo * const) &x.foo[2] - 4B, +, -4B

[Bug target/19700] ICE in final_scan_insn with O1 -g -march=athlon-xp -mfpmath=sse

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

[Bug target/19700] ICE in final_scan_insn with O1 -g -march=athlon-xp -mfpmath=sse

--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-29 21:11 --- Created an attachment (id=8104) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8104&action=view) Failing source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19700

[Bug target/19700] New: ICE in final_scan_insn with O1 -g -march=athlon-xp -mfpmath=sse

le-languages=c,f95 Thread model: posix gcc version 4.0.0 20050129 (experimental) -- Summary: ICE in final_scan_insn with O1 -g -march=athlon-xp - mfpmath=sse Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

--- Additional Comments From pcarlini at suse dot de 2005-01-29 20:52 --- Interesting ;) After so many months, it turns out we have to add push/pop to *all* the headers?!? Why nobody mentioned that before?!? Not a big deal, in case, but I'm somewhat suprised. -- http://gcc.gnu.org/b

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

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 20:48 --- (In reply to comment #5) > What other pass than fold() is supposed to handle this sort of simplification? Actually if you look at the tree dumps you will see that we removed that if. It does not help the t

[Bug target/19690] ICE with -O3 -march=athlon-xp -mfpmath=sse -mno-80387

--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-29 20:01 --- Created an attachment (id=8103) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8103&action=view) Failing preprocessed C source code To see wether this problem can also be exposed with the C fronten

[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-29 19:39 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

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

-- Bug 19639 depends on bug 15791, which changed state. Bug 15791 Summary: fold misses that two ADDR_EXPR of an arrary obvious not equal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15791 What|Old Value |New Value

[Bug middle-end/19699] [4.0 Regression] warning about not returning from end of a non-void function because of dead code

-- What|Removed |Added CC||larsbj at gullik dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19699

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

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-29 19:25 --- Subject: Bug 15791 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-29 19:25:17 Modified files: gcc: ChangeLog fold-const.c gcc/t

[Bug middle-end/19699] [4.0 Regression] warning about not returning from end of a non-void function because of dead code

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 19:25 --- I also happens with the C front-end too. -- What|Removed |Added Component|c++

[Bug middle-end/19698] [4.0 regression] Infinite loop in update_life_info

-- What|Removed |Added Keywords||compile-time-hog Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.c

[Bug c++/19699] [4.0 Regression] warning about not returning from end of a non-void function because of dead code

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

[Bug middle-end/19583] [4.0 Regression] Incorrect diagnostic: control may reach end of non-void function '...' being inlined

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 19:23 --- (In reply to comment #23) > This does not seem to be fixed so reopening. I opened another PR because it is related but not fully the same problem. (PR 19699). -- http://gcc.gnu.org/bugzilla/show_bug.cg

[Bug c++/19699] New: [4.0 Regression] warning about not returning from end of a non-void function because of dead code

Reduced testcase (why don't we remove the dead code before inlining). void g(void); inline int f(void) { return 1; g(); } int h(void) { return f(); } Note this is reduced from: #include #include void foo(std::vector & matches) { char * buf[10]; matches.insert(matches.end(), buf, buf + 10

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

--- Additional Comments From guardia at sympatico dot ca 2005-01-29 19:21 --- Hum, ok we can do a "movd %mm0, %eax", that's why it gets combined... Well, I give up. The V8QI (and whatever) -> V2SI conversion seems to be causing all the trouble here if we look at the RTL of something li

[Bug middle-end/19698] [4.0 regression] Infinite loop in update_life_info

--- Additional Comments From schwab at suse dot de 2005-01-29 19:18 --- Created an attachment (id=8102) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8102&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19698

[Bug middle-end/19698] New: [4.0 regression] Infinite loop in update_life_info

The attached test causes the compiler to hang in update_life_info (called from rest_of_handle_life) while compiling the FFT function with -O2. -- Summary: [4.0 regression] Infinite loop in update_life_info Product: gcc Version: 4.0.0 Status: UNCONFIRM

[Bug middle-end/19583] [4.0 Regression] Incorrect diagnostic: control may reach end of non-void function '...' being inlined

--- Additional Comments From larsbj at gullik dot net 2005-01-29 19:09 --- This does not seem to be fixed so reopening. -- What|Removed |Added CC|

[Bug middle-end/19697] New: [4.0 Regression] gcc.c-torture/execute/ieee/mzero6.c:24: error: unrecognizable insn

Executing on host: /test/gnu/gcc-3.3/objdir/gcc/xgcc -B/test/gnu/gcc-3.3/objdir/ gcc/ /test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c -w -O0 -lm -o /test/gnu/gcc-3.3/objdir/gcc/testsuite/mzero6.x0(timeout = 300) /test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/ex

[Bug other/19696] gcc.c-torture/execute/ieee/copysign1.c: Unsatisfied symbols: copysignl

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 17:51 --- Confirmed on powerpc-darwin7.7.0 which also does not have fully the C99 math functions (well have all of them except for the long double form. -- What|Removed |Added --

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

--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-29 17:48 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug other/19696] New: gcc.c-torture/execute/ieee/copysign1.c: Unsatisfied symbols: copysignl

PASS: gcc.c-torture/execute/ieee/compare-fp-4.c execution, -Os Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/gc c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/copysign1.c -w -O0 -lm -o /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/copysign1.x0(t

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

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-29 17:46 --- Subject: Bug 18565 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-29 17:46:35 Modified files: gcc/fortran: ChangeLog check.c intrinsic.c intrins

[Bug c++/19185] [3.3/3.4/4.0 Regression] ICE: cp_expr_size, at cp/cp-lang.c:308

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 17:41 --- http://gcc.gnu.org/ml/gcc/2001-01/msg01594.html http://gcc.gnu.org/ml/gcc/2001-01/msg01721.html http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00817.html http://gcc.gnu.org/ml/gcc/2001-02/msg00461.html http://

[Bug c++/19185] ICE: cp_expr_size, at cp/cp-lang.c:308

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 17:36 --- *** Bug 19222 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19185

[Bug c++/19222] [4.0 Regression] ICE: in fold_convert, at fold-const.c:1980

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 17:36 --- This is a dup of bug 19185 which is exactly the same problem just changed where the ICE is. *** This bug has been marked as a duplicate of 19185 *** -- What|Removed |Ad

[Bug c++/19185] ICE: cp_expr_size, at cp/cp-lang.c:308

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 17:35 --- Confirmed, there is another dup of this bug. I have seen somewhere PCC_STATIC_STRUCT_RETURN causes problems with c++ before. -- What|Removed |Added ---

[Bug tree-optimization/19670] [4.0 regression] testsuite failure: gcc.c-torture/execute/builtins/strlen-3.c compilation, -O1

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 17:33 --- *** Bug 19695 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug middle-end/19695] [4.0 Regression] gcc.c-torture/execute/builtins/strlen-3.c:20: ICE: verify_flow_sensitive_alias_info failed

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 17:33 --- *** This bug has been marked as a duplicate of 19670 *** -- What|Removed |Added

[Bug c++/19628] [3.4/4.0 Regression] g++ no longer accepts __builtin_constant_p in constant-expressions

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 17:31 --- Patch here: . -- What|Removed |Added

[Bug middle-end/19695] New: [4.0 Regression] gcc.c-torture/execute/builtins/strlen-3.c:20: ICE: verify_flow_sensitive_alias_info failed

Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/gc c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3.c /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/strlen-3-lib.c /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute

[Bug c/18166] top const stripped in structs for C

--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-01-29 16:31 --- My patch should cause fields to be given the correct types within the C front end, and might thereby fix this bug. -- http://gcc.gnu.org/bugzilla/

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 16:26 --- (In reply to comment #12) > I am sorry, in my attempt to reduce the exmaple I introduced a bug in the > testcase. Yes and this is not a target related bug at all but a libstdc++ one. -- What

[Bug target/19664] libstdc++ headers should have pop/push of the visibility around the declarations

--- Additional Comments From andreas dot pokorny at gmx dot de 2005-01-29 16:24 --- I am sorry, in my attempt to reduce the exmaple I introduced a bug in the testcase. -- What|Removed |Added --

[Bug c/19694] [3.4 Regression] Warning about mismatched function declaration is now error

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 16:23 --- Confirmed, only a 3.4 regression, it works on the mainline (we get warnings and not errors). -- What|Removed |Added -

[Bug c/19694] New: Warning about mismatched function declaration is now error

Consider the following source file: static int foo (arg1, arg2) void *arg1, *arg2; { bar (arg1, arg2); return 0; } void bar (arg1, arg2) void *arg1, *arg2; { callme (arg1, arg2); } If I compile it with GCC 3.3.3 or earlier, I get a warning: tfwd.c:11: warning: type mismatch wit

[Bug libfortran/19595] eor does not work

--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-29 15:47 --- . -- What|Removed |Added Status|RESOLVED|REOPENED Re

[Bug libfortran/19595] eor does not work

--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-29 15:47 --- Whoops, maybe not fixed. -- What|Removed |Added Last reconfirmed|2005-01-26 21:48:45

[Bug libfortran/19595] eor does not work

--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-29 15:46 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug fortran/19589] Regression: Error on Data assignment with LOGICAL*1

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 15:39 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug libfortran/19595] eor does not work

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-29 15:45 --- Subject: Bug 19595 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-29 15:45:17 Modified files: gcc/testsuite : ChangeLog libgfortran: C

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

-- Bug 19292 depends on bug 19589, which changed state. Bug 19589 Summary: Regression: Error on Data assignment with LOGICAL*1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19589 What|Old Value |New Value --

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 15:37 --- Note the orginal testcase is: #include int some_function( std::string const& do_something ) __attribute__ ((visibility("default"))); int some_function( std::string const& do_something ) { std::string

[Bug fortran/19589] Regression: Error on Data assignment with LOGICAL*1

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-29 15:36 --- Subject: Bug 19589 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-29 15:35:51 Modified files: gcc/fortran: ChangeLog expr.c gcc/testsui

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 15:32 --- (In reply to comment #9) > (In reply to comment #8) > > I am also refereing to this example: > > http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html > > Now there is a libstdc++ bug for not using pop/pus

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 15:28 --- (In reply to comment #8) > I am also refereing to this example: > http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html Now there is a libstdc++ bug for not using pop/push of the visibility in the headers

[Bug bootstrap/19692] Internal error during gcc 3.3.5 bootstrap (Alpha)

--- Additional Comments From pascal at quies dot net 2005-01-29 15:28 --- (In reply to comment #1) > How much memory/swap do you have? 64MB/48MB A upgrade to 128MB swap solved the problem. Thank you very much for the quick responce and the correct answer :) -- What|Rem

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

--- Additional Comments From andreas dot pokorny at gmx dot de 2005-01-29 15:26 --- I am also refereing to this example: http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664

[Bug target/19664] -fvisibility-inlines-hidden fails with gcc's extern template extension on amd64

--- Additional Comments From andreas dot pokorny at gmx dot de 2005-01-29 15:08 --- If it is a programmers bug, why does it happen only with amd64, but not with ia32 or ia64? > Actually this is not a gcc or a linker bug but a programmers. > Basically -fvisibility=hidden -fvisibility-i

[Bug target/19300] [4.0 Regression] PCH failures on sparc-linux

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 14:01 --- Even though this is a user visible regression. This is not a regression as it was just by chance that this worked in the first place: . Removing the targe

[Bug fortran/19693] optimization problem with LAPACK routine cgtts2.f

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 13:55 --- At -O0 on powerpc-darwin I get: B(1,1) = ( +Infinity, NaN) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19693

[Bug fortran/19693] optimization problem with LAPACK routine cgtts2.f

--- Additional Comments From billingd at gcc dot gnu dot org 2005-01-29 13:52 --- Created an attachment (id=8100) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8100&action=view) cgtts2.f is LAPACK routine that is miscompiled cgtts2.f is LAPACK routine that is miscompiled -- ht

[Bug fortran/19693] optimization problem with LAPACK routine cgtts2.f

-- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19693

[Bug fortran/19693] optimization problem with LAPACK routine cgtts2.f

--- Additional Comments From billingd at gcc dot gnu dot org 2005-01-29 13:51 --- Created an attachment (id=8099) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8099&action=view) driv.f: test driver driv.f is driver routine -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19693

[Bug fortran/19693] New: optimization problem with LAPACK routine cgtts2.f

With gfortran 20050129 I get a testsuite failure at -O2 that I don't see at - O0. The failure is in the CGT tests in ctest.in: CGT: General tridiagonal Matrix types (1-6 have specified condition numbers): 1. Diagonal7. Random, unspecified CNDNUM 2. R

[Bug c++/15759] ICE with function pointers

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 13:43 --- Note the following is make sure that we create correct code: extern "C" void exit (int); extern "C" void abort(); int defValue() { exit(0);return(0); } int(*defaultValue)() = defValue; void a(int blah = defa

[Bug target/14973] ICE with -maltivec for vector types not matching HW types

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 13:39 --- Fixed, most likely for a while now. -- What|Removed |Added Status|NEW

  1   2   >