[Bug tree-optimization/34030] ICE in in compare_values_warnv, at tree-vrp.c:701

--- Comment #2 from christophe dot lyon at st dot com 2007-11-09 08:39 --- In any case, I would appreciate a pointer to the patch, such that I can backport it to my local 4.1.x branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34030

[Bug c++/34039] New: -Werror does not trigger non zero exit code

GCC 4.1.1, MinGW, Windows 2000 host, X86 Linux target I'm not sure about the intended behavior, but if I compile with -Werror (a C++ source in my case) and I trigger a warning that is treated as an error, then g++ exits with a zero return status. However, an existing object file for that source is

[Bug bootstrap/33992] Building libstdc++-v3: include/limits: stray '\275' in program

--- Comment #5 from lindevel at gmx dot net 2007-11-09 09:50 --- The problem (stray characters in include/limits) persists after I rebuilt the whole system to wipe out any leftovers from previous attempts at vectorisation and hidden inlines. Setting LANG and LC_ALL also didn't help. It s

[Bug rtl-optimization/34035] [4.3 Regression] ICE in calc_dfs_tree with -O2 -fnon-call-exceptions -ffast-math -fno-gcse

--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-11-09 09:55 --- Interesting combination of options (-O2 is missing though). -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added

[Bug rtl-optimization/34035] [4.3 Regression] ICE in calc_dfs_tree with -O2 -fnon-call-exceptions -ffast-math -fno-gcse

--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-11-09 10:20 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Assigne

[Bug bootstrap/34003] [4.2/4.3 Regression] gcc 4.3.0 unable to bootstrap itself; Unsatisfied symbols: ggc_free

--- Comment #13 from r dot emrich at de dot tecosim dot com 2007-11-09 10:33 --- Your right, seems to be platform-specific. hppa64-hp-hpux11.00 is ok. I will investigate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003

[Bug middle-end/34040] New: [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

Build failure in libgfortran with revision 129967 (128328 worked): /home/rask/build/gcc-sh-unknown-elf/./gcc/gfortran -B/home/rask/build/gcc-sh-unknown-elf/./gcc/ -nostdinc -B/home/rask/build/gcc-sh-unknown-elf/sh-unknown-elf/m2e/newlib/ -isystem /home/rask/build/gcc-sh-unknown-elf/sh-unknown-elf/

[Bug middle-end/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

--- Comment #1 from rask at gcc dot gnu dot org 2007-11-09 10:45 --- Created an attachment (id=14513) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14513&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040

[Bug target/30829] extra register zero extends

--- Comment #2 from rask at gcc dot gnu dot org 2007-11-09 11:08 --- It's not unusual to need more than one instruction pattern for the same machine instruction. See http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01318.html> and the followup for a recent example and what you can do about i

[Bug target/33474] bfin: ICE: RTL check: expected code 'set' or 'clobber', have 'parallel' in bfin_adjust_cost, at config/bfin/bfin.c:3120

--- Comment #1 from rask at gcc dot gnu dot org 2007-11-09 11:54 --- Created an attachment (id=14514) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14514&action=view) patch v1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33474

[Bug target/33551] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in m32c_immd_dbl_mov, at config/m32c/m32c.c:3010

--- Comment #2 from rask at gcc dot gnu dot org 2007-11-09 11:58 --- Tested revision 129966 which works. -- rask at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/34027] [4.3 regression] -Os code size nearly doubled

--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-09 12:15 --- I think whether the modulus will be bigger or smaller is terribly hard to estimate. Really, if you file -Os regressions, you should at least compile the whole kernel and compare whether the resulting sizes, rather tha

[Bug tree-optimization/34027] [4.3 regression] -Os code size nearly doubled

--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-09 12:30 --- So then shouldn't this bug be about: unsigned long long foo (unsigned long long ns) { return ns % 10L; } unsigned long long bar (unsigned long long ns) { return ns - (ns / 10L) * 10L; } no

[Bug tree-optimization/33604] [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2

--- Comment #23 from rguenth at gcc dot gnu dot org 2007-11-09 12:32 --- Subject: Bug 33604 Author: rguenth Date: Fri Nov 9 12:32:20 2007 New Revision: 130040 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130040 Log: 2007-11-09 Richard Guenther <[EMAIL PROTECTED]>

[Bug tree-optimization/33604] [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2

--- Comment #24 from rguenth at gcc dot gnu dot org 2007-11-09 12:33 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNE

[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules

--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-11-09 12:36 --- I think the problem starts with: module mod0 integer mpi_bottom common /mpipriv/ mpi_bottom end module mod0 module mod1 use mod0 end module mod1 module mod2 use mod0 use mod1 end module mod2 Becaus

[Bug tree-optimization/34027] [4.3 regression] -Os code size nearly doubled

--- Comment #5 from rguenther at suse dot de 2007-11-09 12:37 --- Subject: Re: [4.3 regression] -Os code size nearly doubled On Fri, 9 Nov 2007, jakub at gcc dot gnu dot org wrote: > --- Comment #4 from jakub at gcc dot gnu dot org 2007-11-09 12:30 --- > So then shouldn't th

[Bug tree-optimization/34027] [4.3 regression] -Os code size nearly doubled

--- Comment #3 from rguenther at suse dot de 2007-11-09 12:20 --- Subject: Re: [4.3 regression] -Os code size nearly doubled On Fri, 9 Nov 2007, jakub at gcc dot gnu dot org wrote: > --- Comment #2 from jakub at gcc dot gnu dot org 2007-11-09 12:15 --- > I think whether the

[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules

--- Comment #15 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-11-09 12:44 --- Subject: Re: gfortran excessive memory usage with COMMON blocks in modules fxcoudert at gcc dot gnu dot org wrote: > Because in that case, mod2.mod already has two copies of the common: >

[Bug tree-optimization/33604] [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2

--- Comment #25 from jacob at math dot jussieu dot fr 2007-11-09 12:49 --- Huge thanks to Richard Guenther for the fix! I don't have a 4.3 installed here but I trust you if you say it's fixed :) Also thanks to everybody who helped, especially to Paolo Bonzini for the minimal testcase!

[Bug rtl-optimization/33732] [4.3 Regression] gcc.c-torture/execute/longlong.c execution at -O3

--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-11-09 12:50 --- Subject: Bug 33732 Author: ebotcazou Date: Fri Nov 9 12:49:55 2007 New Revision: 130042 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130042 Log: PR rtl-optimization/33732 * reload.c (p

[Bug rtl-optimization/33732] [4.3 Regression] gcc.c-torture/execute/longlong.c execution at -O3

--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-11-09 12:51 --- Thanks for the preliminary analysis. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added --

[Bug tree-optimization/33604] [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2

--- Comment #26 from rguenther at suse dot de 2007-11-09 12:51 --- Subject: Re: [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2 On Fri, 9 Nov 2007, jacob at math dot jussieu dot fr wrote: > Huge thanks to Richard Guenther for the fix! >

[Bug rtl-optimization/34012] [4.3 Regression] Pessimization caused by fwprop

--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-09 13:03 --- Subject: Bug 34012 Author: jakub Date: Fri Nov 9 13:02:25 2007 New Revision: 130043 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130043 Log: PR rtl-optimization/34012 * fwprop.c (try_fwprop

[Bug rtl-optimization/34012] [4.3 Regression] Pessimization caused by fwprop

--- Comment #11 from jakub at gcc dot gnu dot org 2007-11-09 13:05 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug target/34041] New: ICE on __may_alias__ with -g

$ cat mayalias-2.c struct S { short x; }; typedef struct S __attribute__((__may_alias__)) test; $ ./bin/gcc mayalias-2.c -g mayalias-2.c:2:16: internal compiler error: in splice_child_die, at dwarf2out.c:5641 Please submit a full bug report, with preprocessed source if appropriate. See

[Bug tree-optimization/33604] [4.3 Regression] Revision 119502 causes significantly slower results with 4.3 compared to 4.2

--- Comment #27 from jacob at math dot jussieu dot fr 2007-11-09 12:55 --- OK, I'm using ubuntu and there's no 4.3 package, and last time I tried compiling a snapshot it failed. I hope someone else will be able to run the benchmark and post the result. -- http://gcc.gnu.org/bugzill

[Bug testsuite/33775] Memset

--- Comment #2 from johan dot walles at gmail dot com 2007-11-09 13:13 --- IMO the proposed change would make the code more readable. -- johan dot walles at gmail dot com changed: What|Removed |Added ---

[Bug middle-end/30442] Expanded array initialization can use memset builtin function

--- Comment #3 from johan dot walles at gmail dot com 2007-11-09 13:09 --- This optimization would have made grep 2.5.3 30% faster in a real-world test case: http://bugs.debian.org/450649 -- johan dot walles at gmail dot com changed: What|Removed

[Bug target/34042] New: Segfault in mips_cannot_change_mode_class

$ cat foo.i typedef long double Tal2ldouble __attribute__((aligned (2))); struct S2015 { Tal2ldouble a; }; extern struct S2015 check2015 (); extern void checkx2015 (struct S2015); void test2015 (void) { checkx2015 (check2015 ()); } boltzmann ~/devel/irun $ cat foo.i typedef long double Tal2ldouble

[Bug debug/34037] [4.1/4.2/4.3 Regression] Bounds for VLAs not emitted into debuginfo

-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34037

[Bug debug/34037] [4.1/4.2/4.3 Regression] Bounds for VLAs not emitted into debuginfo

--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-09 13:56 --- I have tried: --- dwarf2out.c.jj9 2007-11-05 09:05:44.0 +0100 +++ dwarf2out.c 2007-11-09 14:29:04.0 +0100 @@ -11032,6 +11032,26 @@ add_bound_info (dw_die_ref subrange_die, later parameter

[Bug bootstrap/34003] [4.2/4.3 Regression] gcc 4.3.0 unable to bootstrap itself; Unsatisfied symbols: ggc_free

--- Comment #14 from r dot emrich at de dot tecosim dot com 2007-11-09 14:40 --- nm ggc-none.o Symbols from ggc-none.o: NameValue Scope TypeSubspace $CODE$ | 0|static|data |$CODE$ $CODE$ | 0|static|data |$CODE$ $

[Bug fortran/34026] Internal compiler error: in gfc_add_modify, at fortran/trans.c:159

--- Comment #7 from Christian dot Carli at cern dot ch 2007-11-09 15:00 --- Subject: Re: Internal compiler error: in gfc_add_modify, at fortran/trans.c:159 Hello, I have now the more recent gfortran binary (even though it is still version 4.3.0) and can compile this routine wi

[Bug bootstrap/34003] [4.2/4.3 Regression] gcc 4.3.0 unable to bootstrap itself; Unsatisfied symbols: ggc_free

--- Comment #15 from r dot emrich at de dot tecosim dot com 2007-11-09 15:06 --- Created an attachment (id=14515) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14515&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003

[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE

--- Comment #11 from amacleod at redhat dot com 2007-11-09 15:37 --- OK, new investigation show that using the smaller testcase firebird2-nav.cc shows the inliner is misbehaving. before inlining (*041t.profile): # BLOCK 2 freq:1 # PRED: ENTRY [100.0%] (fallthru,exec) D.270

[Bug libstdc++/34032] -std=c++0x causes undeclared symbols errors on cygwin

--- Comment #5 from paolo at gcc dot gnu dot org 2007-11-09 15:54 --- Subject: Bug 34032 Author: paolo Date: Fri Nov 9 15:54:33 2007 New Revision: 130047 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130047 Log: 2007-11-09 Paolo Carlini <[EMAIL PROTECTED]> PR libstd

[Bug libstdc++/34032] -std=c++0x causes undeclared symbols errors on cygwin

--- Comment #6 from pcarlini at suse dot de 2007-11-09 15:56 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED

[Bug fortran/33592] FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test

--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-09 16:07 --- My mistake. This comes from a typo in trans.c (a EQ_EXPR instead of an NE_EXPR). Could you test this patch? Index: trans.c === --- trans.c (rev

[Bug tree-optimization/34043] New: Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.

Compile the attached file test.cpp with the following flags: g++ -DNDEBUG -m32 -msse2 -O2 -msse2 -DSHOW_BUG gcc_bug.cpp -S In the generated code there are useless stores and loads of %xmm0 to -40(%eps) and -56(%eps). If the code is compiled without -DSHOW_BUG it will generate a more optimal versi

[Bug tree-optimization/34043] Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.

--- Comment #1 from jsjodin at gcc dot gnu dot org 2007-11-09 16:16 --- Created an attachment (id=14516) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14516&action=view) Source code to expose the missed optimization -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34043

[Bug tree-optimization/34043] Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.

--- Comment #2 from jsjodin at gcc dot gnu dot org 2007-11-09 16:16 --- Created an attachment (id=14517) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14517&action=view) Assembly code for bad code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34043

[Bug tree-optimization/34043] Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.

--- Comment #3 from jsjodin at gcc dot gnu dot org 2007-11-09 16:17 --- Created an attachment (id=14518) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14518&action=view) Assembly code for good code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34043

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use

--- Comment #21 from bunk at stusta dot de 2007-11-09 16:26 --- Let's leave the right/wrong discussion and look at it more pragmatically: Could gcc get some kind of --expensive-libgcc flag that tells gcc that libgcc calls are a bit more expensive than usually and should be avoided? --

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use

--- Comment #22 from rguenther at suse dot de 2007-11-09 16:33 --- Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use On Fri, 9 Nov 2007, bunk at stusta dot de wrote: > --- Comment #21 from bunk at stusta dot de 2007-11-09 16:26 --- > Let's leave the ri

[Bug fortran/33592] FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test

--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-09 16:45 --- Subject: Re: FAIL: gfortran.dg/array_constructor_11.f90 -O1 execution test > Could you test this patch? Yes, tonight. Thanks. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33592

[Bug target/34001] Incorrect __attribute__ fastcall behavior

--- Comment #2 from hjl at lucon dot org 2007-11-09 16:55 --- From http://msdn2.microsoft.com/en-us/library/6xa169sk(VS.80).aspx "The first two DWORD or smaller arguments are passed in ECX and EDX registers; all other arguments are passed right to left." But it isn't clear if it appli

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use

--- Comment #23 from bunk at stusta dot de 2007-11-09 17:09 --- We need a way to globally prevent it in the kernel or it will be a repeating source of problems there. Is -fno-tree-scev-cprop a reasonable (and not too expensive) workaround for the Linux kernel? -- http://gcc.gnu.org

[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use

--- Comment #24 from rguenther at suse dot de 2007-11-09 17:11 --- Subject: Re: [4.3 regression] udivdi3 counterproductive, unwarranted use On Fri, 9 Nov 2007, bunk at stusta dot de wrote: > --- Comment #23 from bunk at stusta dot de 2007-11-09 17:09 --- > We need a way to g

[Bug rtl-optimization/34035] [4.3 Regression] ICE in calc_dfs_tree with -O2 -fnon-call-exceptions -ffast-math -fno-gcse

--- Comment #3 from janis at gcc dot gnu dot org 2007-11-09 17:23 --- The option list should have included -O2. This is one of the failures found by compiling SPEC CPU2000 with lots of sets of options and running with the test input, as described in http://gcc.gnu.org/ml/gcc/2007-09/msg

[Bug target/34001] Incorrect __attribute__ fastcall behavior

--- Comment #3 from hjl at lucon dot org 2007-11-09 17:34 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00531.html -- hjl at lucon dot org changed: What|Removed |Added ---

[Bug testsuite/33775] Memset

--- Comment #3 from manu at gcc dot gnu dot org 2007-11-09 18:16 --- (In reply to comment #2) > IMO the proposed change would make the code more readable. Johan, the code you quote is in a file from the testsuite. Such code is used to test for some correct behavior under various circums

[Bug tree-optimization/34043] Missed optimization causing extra loads and stores when using x86_64 builtin function together with aggregate types.

--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-09 18:24 --- Related to PR 33790 (and most likely fixed by it). There is another issue with that bug relating to not deleting the extra store. -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

--- Comment #6 from dominiq at lps dot ens dot fr 2007-11-09 18:26 --- Note that I still get the warning after having recompiled gcc/config/i386/crtfastmath.c with -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34025

[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE

--- Comment #12 from pinskia at gcc dot gnu dot org 2007-11-09 18:27 --- (In reply to comment #11) > OK, new investigation show that using the smaller testcase firebird2-nav.cc > shows the inliner is misbehaving. That smaller testcase is a different issue as explained in comment #6 an

[Bug c++/17577] [4.0/4.1/4.2/4.3 Regression] #pragma implementation no longer diagnoses use after file to which it applies

--- Comment #9 from tromey at gcc dot gnu dot org 2007-11-09 18:28 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC|

[Bug target/34041] ICE on __may_alias__ with -g

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-09 18:21 --- *** This bug has been marked as a duplicate of 28834 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)

--- Comment #28 from pinskia at gcc dot gnu dot org 2007-11-09 18:21 --- *** Bug 34041 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/33230] Missing check: specification function must be pure

--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-09 18:45 --- This was fixed (and the testsuite fixed also): $ gfortran char_result_7.f90 char_result_7.f90:29.20: character (len = fn (i)) :: f1 1 Error: Specification function 'fn' at (1) must be PURE

[Bug c++/34039] -Werror does not trigger non zero exit code

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-09 18:48 --- This works for me: cc1plus: warnings being treated as errors t.c:3: warning: unused parameter 'a' t.c:3: warning: unused parameter 'b' t.c: In function 'float f(float, float)': t.c:6: warning: control reaches end of

[Bug rtl-optimization/34040] [4.3 Regression] ICE: in simplify_subreg, at simplify-rtx.c:4921 building libgfortran

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot |

[Bug target/34042] Segfault in mips_cannot_change_mode_class

-- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org

[Bug fortran/33698] FAIL: gfortran.dg/gamma_5.f90

--- Comment #20 from fxcoudert at gcc dot gnu dot org 2007-11-09 18:40 --- Created an attachment (id=14519) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14519&action=view) gamma from netlib, converted to C (In reply to comment #18) > OTOH, maybe using straight Netlib code would

[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE

--- Comment #13 from amacleod at redhat dot com 2007-11-09 18:40 --- Then perhaps we should remove the attachment from this PR if it isn't relevant... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604

[Bug fortran/34044] New: OpenMP: Crashes with valid code.

Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9a7daa8d75084b6b/ The program looks valid. It crashes here at run time with -m32, but not with -m64; with "y(j) = 0.0_dp" commented out it does not crash at all, here. program sums implicit none integer, paramet

[Bug c++/34039] -Werror does not trigger non zero exit code

--- Comment #2 from manu at gcc dot gnu dot org 2007-11-09 19:13 --- Moreover, those should be "error:" messages in GCC 4.3. I don't think such a change would be backported to GCC 4.1 -- manu at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/34044] OpenMP: Crashes with valid code.

--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-09 19:18 --- (In reply to comment #0) >y(j) = 0.0_dp This part is nonsense and should be "y = 0.0_dp". The original dump looks ok; I don't know whether something else goes wrong. - It does not crash here anymore (x86-64 -m32/

[Bug bootstrap/34045] gcc does not build on Debian etch AMD64

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-09 19:29 --- What happens if you don't build in the source directory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34045

[Bug bootstrap/34045] New: gcc does not build on Debian etch AMD64

Hi, I tried to compile gcc 4.2.2 from source on Debian etch AMD64 and failed. I used the system compiler: $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-syste

[Bug fortran/34044] OpenMP: Crashes with valid code.

--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-09 19:43 --- Yeah, the crash was clearly because j was not initialized. -- jakub at gcc dot gnu dot org changed: What|Removed |Added --

[Bug rtl-optimization/21150] Suboptimal byte extraction from 64bits

--- Comment #4 from rask at gcc dot gnu dot org 2007-11-09 19:48 --- I think this might be a middle-end issue related to PR 7061 or PR 15184. We're doing slightly better with GCC 4.3.0 (because of subreg lowering, I guess), but not much (asm output with -dp for readability): a:

[Bug target/31943] very missed optimization.

--- Comment #4 from pluto at agmk dot net 2007-11-09 20:33 --- current 4.3 works fine: (32-bits): _Z3msby: movzbl 11(%esp), %eax ret (64-bits): _Z3msby: shrq$56, %rdi movl%edi, %eax ret -- pluto at agmk dot net changed:

[Bug rtl-optimization/18560] better optimalization of EOR/MOV block.

--- Comment #7 from rask at gcc dot gnu dot org 2007-11-09 20:40 --- This has been fixed for more than a year: reverse: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. eor r3, r0, r0, ror

[Bug c++/34046] New: verify_flow_info failed

I just tried to compile the Suse Linux package snes9x-1.5-107 with the GNU C++ compiler version 4.3 snapshot 20071102 The compiler said spc700.cpp:977: warning: deprecated conversion from string constant to 'char*' spc700.cpp: In function 'void ApuCA()': spc700.cpp:807: error: verify_flow_info: W

[Bug c++/34046] verify_flow_info failed

--- Comment #1 from dcb314 at hotmail dot com 2007-11-09 20:50 --- Created an attachment (id=14520) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14520&action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34046

[Bug c/34047] New: ice for legal code

I just tried to compile the Suse Linux package spandsp-0.0.3-43 with the GNU C compiler version 4.3 snapshot 20071102 The compiler said v17rx.c: In function 'v17_rx_restart': v17rx.c:12020: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if ap

[Bug c/34047] ice for legal code

--- Comment #1 from dcb314 at hotmail dot com 2007-11-09 20:53 --- Created an attachment (id=14521) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14521&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34047

[Bug target/31943] very missed optimization.

--- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-09 20:43 --- This was the normal "subreg" issue which was fixed by Ian back on 2007-01-31. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/34044] OpenMP: Crashes with valid code.

--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-09 21:21 --- > Yeah, the crash was clearly because j was not initialized. My inability to generate test cases does not mean that there is not necessarily no bug in gfortran. See http://gcc.gnu.org/ml/fortran/2007-11/msg00052.html

[Bug fortran/34044] OpenMP: Crashes with valid code.

--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-09 21:30 --- Given how big the array is it is very likely they just overflow the thread stack. What ulimit -s they are using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34044

[Bug tree-optimization/34047] [4.3 Regression] ice for legal code in vectorizer

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot |

[Bug fortran/33698] FAIL: gfortran.dg/gamma_5.f90

--- Comment #21 from tkoenig at gcc dot gnu dot org 2007-11-09 21:50 --- (In reply to comment #20) Hi FX, > I can work on the C version of lgamma at some point in the week-end, if you > want me to. That would be great. Real Life has caught up with me in a big way the last few weeks,

[Bug tree-optimization/19097] [4.1/4.2/4.3 regression] Quadratic behavior with many sets for the same register in VRP

--- Comment #43 from steven at gcc dot gnu dot org 2007-11-09 22:08 --- IMVHO this should be closed as WONTFIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug middle-end/34046] [4.3 Regression] verify_flow_info failed

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot |

[Bug middle-end/34046] [4.3 Regression] verify_flow_info failed

--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-09 22:55 --- *** This bug has been marked as a duplicate of 33737 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug rtl-optimization/33737] [4.3 Regression] verify_flow_info failed: Wrong probability of edge 94->1 -6651

--- Comment #13 from rguenth at gcc dot gnu dot org 2007-11-09 22:55 --- *** Bug 34046 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug target/34013] callee-save register value sometimes corrupted when __stkchk called

--- Comment #1 from acn1 at cam dot ac dot uk 2007-11-09 22:56 --- Created an attachment (id=14522) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14522&action=view) patch to gcc/config/i386/i386.c This tries to avoid saving regs before allocating the stack frame if the frame will

[Bug tree-optimization/33867] [4.3 Regression] ICE verify_flow_info failed (Wrong frequency of block)

--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-09 22:56 --- *** This bug has been marked as a duplicate of 33737 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug rtl-optimization/33737] [4.3 Regression] verify_flow_info failed: Wrong probability of edge 94->1 -6651

--- Comment #14 from rguenth at gcc dot gnu dot org 2007-11-09 22:56 --- *** Bug 33867 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug tree-optimization/33856] [4.3 Regression] Segfault in create_data_ref/compute_data_dependences_for_loop

--- Comment #9 from rguenth at gcc dot gnu dot org 2007-11-09 22:58 --- *** Bug 34047 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug tree-optimization/34047] [4.3 Regression] ice for legal code in vectorizer

--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-09 22:58 --- *** This bug has been marked as a duplicate of 33856 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/34044] OpenMP: Crashes with valid code.

--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-09 23:50 --- Ok, reading the thread in there it is clear the stack size is the problem. As it needs 16MB of memory on the stack, it should be run with ulimit -s 16384 (note that ulimit -s unlimited doesn't imply unlimited thread st

[Bug rtl-optimization/11873] inefficient use of registers induces size and time overhead

--- Comment #4 from rask at gcc dot gnu dot org 2007-11-09 23:51 --- This has improved (-O2 -fomit-frame-pointer): test: movl4(%esp), %eax # 32*movsi_1/1 [length = 4] movl8(%esp), %edx # 44*movsi_1/1 [length = 4] orl %eax, %edx

[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules

--- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-11-09 23:59 --- (In reply to comment #15) > I wrote this code originally, and I agree with your analysis. But regtesting doesn't agree with my analysis... in case of common with bind(c,name="..."), this patch hampers the diagno

[Bug rtl-optimization/15792] missed subreg optimization

--- Comment #10 from rask at gcc dot gnu dot org 2007-11-10 00:15 --- This was fixed in 4.3.0. -- rask at gcc dot gnu dot org changed: What|Removed |Added Sta

[Bug middle-end/33315] If condition not getting eliminated

--- Comment #3 from steven at gcc dot gnu dot org 2007-11-10 00:27 --- As a missed optimization, this bug adds new information. But as a regression, this is a dup of bug 30905. -- steven at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/25252] ICE on invalid code

--- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-11-10 00:53 --- The following patch clears part of the problem, for example the following testcase: module g interface i module procedure sint => sreal end interface i end module g More is needed, but I'm stuck. I've u

[Bug rtl-optimization/23813] [4.3 Regression] redundant register assignments not eliminated

--- Comment #4 from rask at gcc dot gnu dot org 2007-11-10 00:59 --- We are regressing! Number of asm lines, not counting directives: 4.1.2: 88 4.2.0: 80 4.2.1: 80 4.2.2: 80 4.3.0: 100 (revision 129967) -- rask at gcc dot gnu dot org changed: What|Removed

[Bug rtl-optimization/23813] redundant register assignments not eliminated

--- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-10 01:07 --- So the issue here is that lshiftrt and ashift is not split up. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules

--- Comment #17 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-11-10 01:16 --- Subject: Re: gfortran excessive memory usage with COMMON blocks in modules fxcoudert at gcc dot gnu dot org wrote: > --- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-11-09

  1   2   >