[Bug c++/32368] warnings from system headers not supressed.

--- Comment #3 from pluto at agmk dot net 2007-06-19 06:44 --- (In reply to comment #2) > At variance with c++/32256, this one apparently happens as "C" code too... > Probably should be not categorized as C++-only... these little bugs (PR32368, PR32256) are treated as blockers by people

[Bug target/31684] [4.3 Regression] ICE in get_attr_first_insn, at config/ia64/itanium2.md:1839 at -O2

--- Comment #4 from tbm at cyrius dot com 2007-06-19 06:39 --- (In reply to comment #3) > I tested the patch on IA64 HP-UX and Linux and verified that it fixed the bug > and caused no regressions. Jim, do you want to check this patch in? Given that Jim hasn't answered yet, maybe you ca

[Bug c/32399] ICE in build2_stat, at tree.c:3074

--- Comment #1 from marcus at jet dot franken dot de 2007-06-19 06:24 --- Created an attachment (id=13734) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13734&action=view) vertexbuffer.i gcc -O2 -c vertexbuffer.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32399

[Bug c/32399] New: ICE in build2_stat, at tree.c:3074

new regression, likely caused by pointer-plus branch merge extracted from Wine /home/marcus/projects/gcc/BIN/bin/gcc -m32 -O2 -c vertexbuffer.i vertexbuffer.i: In function 'f': vertexbuffer.i:1: internal compiler error: in build2_stat, at tree.c:3074 -- Summary: ICE in build2_s

Re: Wrong PR listed in your recent ChangeLog

Eric, Hi Paul, In your recent checkin: You list PR fortran/20082 as one of the bugs fixed. PR 20082 is a target bug for the AVR target and was resolved as invalid. So it looks like you have the wrong PR number in your ChangeLog. I saw it

[Bug tree-optimization/32390] tree-ssa-math-opts.c performs too many IL scans

--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2007-06-19 05:09 --- Subject: Re: tree-ssa-math-opts.c performs too many IL scans > We have reciprocal pass (in fact CSE recip pass) that CSEs 1.0/z from x/z, > y/z, > .../z. This is done by scanning function for RDIV_EXP

[Bug fortran/25061] procedure name conflict

--- Comment #3 from patchapp at dberlin dot org 2007-06-19 05:00 --- Subject: Bug number PR25061 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01294.html -- http://gcc.gnu.org/bugzilla/sh

[Bug middle-end/32321] [4.3 Regression] ICE in df_refs_verify with -fgcse-sm

--- Comment #4 from spark at gcc dot gnu dot org 2007-06-19 04:38 --- Fixed. -- spark at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726

--- Comment #8 from spark at gcc dot gnu dot org 2007-06-19 04:30 --- (In reply to comment #7) > Subject: Bug 32339 > > Author: spark > Date: Mon Jun 18 20:02:33 2007 > New Revision: 125825 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125825 > Log: > gcc/ChangeLog: > > 20

[Bug fortran/32386] Pure function not allowed in specification expression

--- Comment #9 from kargl at gcc dot gnu dot org 2007-06-19 03:50 --- John, With your acknowledgment of pault's comment, I think this can be closed. Thanks for the reports. These types of potential corner cases keep us on our toes. -- kargl at gcc dot gnu dot org changed:

[Bug regression/32398] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

--- Comment #1 from danglin at gcc dot gnu dot org 2007-06-19 02:39 --- This appears to be another problem in handling return pointer: 0x403e5644 :extrd,u ret0,63,32,rp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398

[Bug regression/32398] New: checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile

checking for hppa64-hp-hpux11.11-gcc... /test/gnu/gcc/objdir/./gcc/xgcc -B/test/ gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/ -B/opt /gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.3.0/ hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-

[Bug fortran/32386] Pure function not allowed in specification expression

--- Comment #8 from John dot Harper at mcs dot vuw dot ac dot nz 2007-06-19 01:13 --- Subject: Re: Pure function not allowed in specification expression On Tue, 18 Jun 2007, pault at gcc dot gnu dot org wrote: > Date: 18 Jun 2007 22:49:37 - > From: pault at gcc dot gnu dot org <

[Bug c/32397] New: wrong instruction order generated

this C code line {(((Cyg_libm_ieee_double_shape_type *)&x)->parts.msw) = (hx&0x800f)|(k<<20); return x;} causes this assembler code to be generated: bic r3, ip, #2130706432 bic r3, r3, #15728640 ldmia sp, {r0-r1} orr r3, r3, r2, asl #20 str r3, [r5, #0] b .L6 The ldmi

Wrong PR listed in your recent ChangeLog

Hi Paul, In your recent checkin: You list PR fortran/20082 as one of the bugs fixed. PR 20082 is a target bug for the AVR target and was resolved as invalid. So it looks like you have the wrong PR number in your ChangeLog. Thanks, Eric Weddin

[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288

--- Comment #7 from pault at gcc dot gnu dot org 2007-06-18 23:10 --- Fixed on trunk Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236

[Bug fortran/20882] PURE procedure containing pointer assignment to dummy with pointer component

--- Comment #4 from pault at gcc dot gnu dot org 2007-06-18 23:09 --- Fixed on trunk Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20882

[Bug fortran/20863] Pointer problems in PURE procedures

--- Comment #6 from pault at gcc dot gnu dot org 2007-06-18 23:08 --- Fixed on trunk Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20863

[Bug fortran/20882] PURE procedure containing pointer assignment to dummy with pointer component

--- Comment #3 from pault at gcc dot gnu dot org 2007-06-18 23:07 --- Subject: Bug 20882 Author: pault Date: Mon Jun 18 23:07:32 2007 New Revision: 125832 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125832 Log: 2007-06-19 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288

--- Comment #6 from pault at gcc dot gnu dot org 2007-06-18 23:04 --- Subject: Bug 32236 Author: pault Date: Mon Jun 18 23:04:28 2007 New Revision: 125831 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125831 Log: 2007-06-19 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug fortran/20863] Pointer problems in PURE procedures

--- Comment #5 from pault at gcc dot gnu dot org 2007-06-18 23:04 --- Subject: Bug 20863 Author: pault Date: Mon Jun 18 23:04:28 2007 New Revision: 125831 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125831 Log: 2007-06-19 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug target/20082] unrecognizable insn

--- Comment #6 from pault at gcc dot gnu dot org 2007-06-18 23:04 --- Subject: Bug 20082 Author: pault Date: Mon Jun 18 23:04:28 2007 New Revision: 125831 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125831 Log: 2007-06-19 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug fortran/32386] Pure function not allowed in specification expression

--- Comment #7 from pault at gcc dot gnu dot org 2007-06-18 22:49 --- John, 5.1 .many snips. If a specification-expr involves a reference to a specification function (7.1.6.2), the expression is considered to be a nonconstant expression. If the data object being declared dep

[Bug rtl-optimization/32374] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396

--- Comment #4 from ubizjak at gmail dot com 2007-06-18 22:36 --- (In reply to comment #3) > I don't know if this is data flow related any more, due to the reporting of PR > 32389. No, this one is caused by dataflow. -- ubizjak at gmail dot com changed: What|Removed

[Bug target/32389] [4.1/4.2 Regression] ICE in extract_constrain_insn_cached when using -msse

--- Comment #3 from ubizjak at gmail dot com 2007-06-18 22:35 --- Fixed in mainline. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigne

[Bug target/32389] [4.1/4.2/4.3 Regression] ICE in extract_constrain_insn_cached when using -msse

--- Comment #2 from uros at gcc dot gnu dot org 2007-06-18 22:33 --- Subject: Bug 32389 Author: uros Date: Mon Jun 18 22:32:56 2007 New Revision: 125830 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125830 Log: PR target/32389 * config/i386/i386.h (enum ix86_sta

[Bug c++/31923] g++ accepts a storage-class-specifier on a template explicit specialization

--- Comment #3 from simonb at gcc dot gnu dot org 2007-06-18 22:09 --- Subject: Bug 31923 Author: simonb Date: Mon Jun 18 22:09:14 2007 New Revision: 125829 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125829 Log: gcc/cp/ChangeLog 2007-06-15 Simon Baldwin <[EMAIL PROTECTED]>

[Bug c/31331] ICE on invalid function attribute syntax for main()

--- Comment #3 from eweddington at cso dot atmel dot com 2007-06-18 22:01 --- The attached patch, written by Anatoly Sokolov, fixes the bug. -- eweddington at cso dot atmel dot com changed: What|Removed |Added -

[Bug c/31331] ICE on invalid function attribute syntax for main()

--- Comment #2 from eweddington at cso dot atmel dot com 2007-06-18 22:00 --- Created an attachment (id=13733) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13733&action=view) Patch to fix bug, written by Anatoly Sokolov -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31331

[Bug middle-end/32396] [PPC/Altivec, regression?] gcc uses 0 as altivec load/store index

--- Comment #1 from sparky at pld-linux dot org 2007-06-18 21:11 --- Created an attachment (id=13732) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13732&action=view) simple testcase and benchmark on 1.3GHz iBook built without USE_ASM runs in 2.335s, with USE_ASM runs in 1.815s

[Bug fortran/32393] gfortran - incorrect run time results

--- Comment #9 from burnus at gcc dot gnu dot org 2007-06-18 21:04 --- > valid test case(?) > I have removed the dummy subroutines and type mismatch. Still not fully valid as NAG f95 complains Error: yyy.f: Argument IVG (no. 2) in reference to VR2 from MAIN is not an array [...] However,

[Bug middle-end/32396] New: [PPC/Altivec, regression?] gcc uses 0 as altivec load/store index

In altivec load/store instructions (lvx, stvx, ...) and lsvl/lsvr, when address is supplied as pointer + well-known constant, gcc always calculates the actual address in scalar unit and does not use sum in those instructions (puts 0 as index). This slows-down some simple altivec loops. Sample code

[Bug middle-end/32321] [4.3 Regression] ICE in df_refs_verify with -fgcse-sm

--- Comment #3 from spark at gcc dot gnu dot org 2007-06-18 20:49 --- Subject: Bug 32321 Author: spark Date: Mon Jun 18 20:49:23 2007 New Revision: 125827 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125827 Log: 2007-06-18 Seongbae Park <[EMAIL PROTECTED]> PR rtl-op

[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu

--- Comment #14 from kargl at gcc dot gnu dot org 2007-06-18 20:47 --- (In reply to comment #13) > The '-ffloat-store' option works! Thank you. > > However that gave me some quenstions; > > Is that feature or bug? It is a 'feature' of the i386 class of cpu. See PR 323 for detail

Size of C/C++ data type from GNU GCC/g++ compiled ELF 64-bit LSB executable, AMD x86-64 vs. ELF 32-bit LSB executable, Intel 80386

Hi, I need experts to shed light on C/C++ data type size inconsistencies when running 64-bit and 32-bit ELF executables compiled by GNU/GCC g++/gcc Following are results of C/C++ data type size from code " cout << "data type" << sizeof(data type) << endl " : | 32-bit | 64-

[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu

--- Comment #13 from sunjoong at gmail dot com 2007-06-18 20:24 --- The '-ffloat-store' option works! Thank you. However that gave me some quenstions; Is that feature or bug? There is many floating point operations of course. Why the only one specific resion make problem?

[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726

--- Comment #7 from spark at gcc dot gnu dot org 2007-06-18 20:02 --- Subject: Bug 32339 Author: spark Date: Mon Jun 18 20:02:33 2007 New Revision: 125825 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125825 Log: gcc/ChangeLog: 2007-06-18 Seongbae Park <[EMAIL PROTECTED]>

[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.

--- Comment #13 from daney at gcc dot gnu dot org 2007-06-18 19:39 --- This is the same problem as: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01165.html I am currently bootstrapping the patch in that e-mail thread and will probably commit that version. -- http://gcc.gnu.org/bug

[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.

--- Comment #12 from daney at gcc dot gnu dot org 2007-06-18 19:35 --- That fix was incorrect. Sorry. -- daney at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.

--- Comment #11 from daney at gcc dot gnu dot org 2007-06-18 19:35 --- Subject: Bug 32313 Author: daney Date: Mon Jun 18 19:35:05 2007 New Revision: 125824 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125824 Log: Revert: 2007-06-18 David Daney <[EMAIL PROTEC

[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu

--- Comment #12 from kargl at gcc dot gnu dot org 2007-06-18 19:16 --- (In reply to comment #11) > Yes, I agree that program is not beautiful > and I know the the array 'w' of 'u3b' subroutine problem; > I think the author of u3b use w(1) as pointer. Change the 1 to *. > However, > the

[Bug fortran/20373] INTRINSIC symbols can be given the wrong type

--- Comment #14 from dfranke at gcc dot gnu dot org 2007-06-18 19:02 --- Updated patch. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added URL

[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu

--- Comment #11 from sunjoong at gmail dot com 2007-06-18 18:47 --- Yes, I agree that program is not beautiful and I know the the array 'w' of 'u3b' subroutine problem; I think the author of u3b use w(1) as pointer. However, the wrong generation of optimized code occurs in 'DP' subrouti

[Bug fortran/32393] gfortran - incorrect run time results

--- Comment #8 from dominiq at lps dot ens dot fr 2007-06-18 18:46 --- Created an attachment (id=13731) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13731&action=view) valid test case(?) I have removed the dummy subroutines and type mismatch. -- http://gcc.gnu.org/bugzilla/s

[Bug fortran/32393] gfortran - incorrect run time results

--- Comment #7 from dominiq at lps dot ens dot fr 2007-06-18 18:44 --- > I do ... I am not in the position to argue about what f90 compilers are supposed to do with the original code. I just attach a modified one I hope is valid: g95 does not complain and gives: karma] f90/bug% bg95 pr

[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu

--- Comment #10 from kargl at gcc dot gnu dot org 2007-06-18 18:36 --- There are literal hundreds of warning given by ftnchek, and there appears to be an array bounds problem. troutmask:sgk[231] gfc4x -o z -O -fbounds-check TMalign.f troutmask:sgk[232] ./z 1aquA.pdb 1avaC.pdb | grep RMS

[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu

--- Comment #9 from sunjoong at gmail dot com 2007-06-18 18:31 --- I cut the bellow and made a new subroutine, then another part did not change on '-O0' and '-O1'; D=VAL(i-1,j-1)+SCORE(i,j) H=VAL(i-1,j) if(DIR(i-1,j))H=H+GAP_OPEN V=VAL(i,j-1)

[Bug fortran/32393] gfortran - incorrect run time results

--- Comment #6 from dir at lanl dot gov 2007-06-18 18:13 --- > Now I don't know how the compiler is supposed to behave when there is a > mismatch between the arguments in the subroutines and their call. I do - since the beginning of FORTRAN, well, at least since FORTRAN 2, it simply pa

[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.

--- Comment #10 from daney at gcc dot gnu dot org 2007-06-18 17:41 --- The ability to bootstrap is fixed by the patch. There are other dataflow regressions that will be fixed by follow up patches. -- daney at gcc dot gnu dot org changed: What|Removed

[Bug tree-optimization/32390] tree-ssa-math-opts.c performs too many IL scans

--- Comment #3 from ubizjak at gmail dot com 2007-06-18 17:40 --- (In reply to comment #2) > We need a better explanation than this. Uros agreed to summarize the > IRC discussion to close this issue. It'd be useful if we keep that same > discussion on the source code itself. The need

[Bug target/32313] [4.3 Regression] Bootstrap failure running gengtype in stage 2.

--- Comment #9 from daney at gcc dot gnu dot org 2007-06-18 17:36 --- Subject: Bug 32313 Author: daney Date: Mon Jun 18 17:36:42 2007 New Revision: 125818 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125818 Log: PR target/32313 * config/mips/mips.c (mips_expand

[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu

--- Comment #8 from sunjoong at gmail dot com 2007-06-18 17:26 --- I checked which part of TMalign.f make optimizaton wrong; In DP subroutine, DO j=1,NSEQ2 DO i=1,NSEQ1 D=VAL(i-1,j-1)+SCORE(i,j) H=VAL(i-1,j) if(DIR(i-1,j))H=H+GAP_OPEN

[Bug c++/32395] false positive warning about use of uninitialized variable.

--- Comment #1 from pluto at agmk dot net 2007-06-18 17:25 --- Created an attachment (id=13730) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13730&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395

[Bug c++/32395] New: false positive warning about use of uninitialized variable.

gcc-4.1 produces a warning for the following testcase. (testcase uses headers from boost-1.34.0). $ cat multi_index_test.cpp #include #include #include #include #include using namespace boost; using namespace boost::multi_index; struct X { int value; bool operator < ( X con

[Bug rtl-optimization/32394] New: some operations to not work properly in df_deferred_rescan mode.

At least one of these three calls do not work properly in deferred rescanning mode. > delete_trivially_dead_insns > rebuild_jump_labels > cleanup_cfg The most likely cause of the failure is that we are not keeping enough information around in the deferred scanning mode to properly track all of th

[Bug rtl-optimization/32355] [4.3 Regression] ICE in df_lr_verify_transfer_functions, at df-problems.c:1924

--- Comment #5 from zadeck at naturalbridge dot com 2007-06-18 16:50 --- fixed,revision 125812 -- zadeck at naturalbridge dot com changed: What|Removed |Added

[Bug rtl-optimization/32355] [4.3 Regression] ICE in df_lr_verify_transfer_functions, at df-problems.c:1924

--- Comment #4 from zadeck at naturalbridge dot com 2007-06-18 16:48 --- Subject: Re: [4.3 Regression] ICE in df_lr_verify_transfer_functions, at df-problems.c:1924 committed as revision 125812 zadeck at naturalbridge dot com wrote: > --- Comment #1 from zadeck at naturalbridge

[Bug rtl-optimization/32355] [4.3 Regression] ICE in df_lr_verify_transfer_functions, at df-problems.c:1924

--- Comment #3 from zadeck at gcc dot gnu dot org 2007-06-18 16:47 --- Subject: Bug 32355 Author: zadeck Date: Mon Jun 18 16:47:05 2007 New Revision: 125812 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125812 Log: 2007-06-18 Kenneth Zadeck <[EMAIL PROTECTED]> PR midd

[Bug fortran/32391] Wrong code with optimization on i686-pc-linux-gnu

se) (SUSE Linux) and with FX's Target: i386-pc-linux-gnu gcc version 4.3.0 20070618 (experimental) Interestingly, it works on x86_64-unknown-linux-gnu even with -m32. (I somehow fail to run FX's i386 compiler on x86-64.) I think this could be a middle-end or target problem as it is that t

[Bug fortran/20441] -finit-local-zero is missing from gfortran

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

[Bug fortran/32393] gfortran - incorrect run time results

--- Comment #5 from burnus at gcc dot gnu dot org 2007-06-18 16:15 --- > Now I don't know how the compiler is supposed to behave when there is a > mismatch between the arguments in the subroutines and their call. Well it is always said that it may do anything such as starting the third

[Bug fortran/32391] Generate wrong optimization code on fortran 77

n compiler or c compiler? 2007/6/19, Tobias Burnus <[EMAIL PROTECTED]>: > As said: It works here with 4.1.3 20070521, 4.2.1 20070604 and 20070618, > 4.3.0 20070618. It also work with my g95, Intel Fortran and sunf95 > compilers. In all cases I get: > > Aligned length= 91, RM

[Bug fortran/32391] Generate wrong optimization code on fortran 77

--- Comment #5 from dominiq at lps dot ens dot fr 2007-06-18 15:38 --- I did not make as many tests as Tobias, but it "works" for me on PPC with g77, xlf, g95, and gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391

[Bug fortran/32393] gfortran - incorrect run time results

--- Comment #4 from dominiq at lps dot ens dot fr 2007-06-18 15:29 --- > The only subroutine actually used is prmx. The rest are dummies to make the > linker happy. One thing which is obviously wrong is that 't' is declared as integer in vr2, but is real in the calling program and in t

[Bug fortran/32391] Generate wrong optimization code from fortran 77

--- Comment #4 from sunjoong at gmail dot com 2007-06-18 15:08 --- Thank you, Tobias I had missunderstood the default optimization level for gfortran but the issue exists, I think. I had traced side effects of optimization levels for the legacy program; -O0 level and -O1 level were

[Bug fortran/32393] gfortran - incorrect run time results

--- Comment #3 from dir at lanl dot gov 2007-06-18 15:05 --- The only subroutine actually used is prmx. The rest are dummies to make the linker happy. With g95, you get the correct results with -g and incorrect results with -O3 - [QuadG5:~/junk] dir% g95 -O3 -d8 -fstatic -Wno=121,155,15

[Bug target/32392] Support using -mrecip w/o additional Newton-Raphson run

--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-18 15:03 --- Initial suggestion, see: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01068.html Richard's remark: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01224.html > Two NR steps don't make sense, they wouldn't improve accura

[Bug other/32351] Wrong DFP format is used in libdecnumber

--- Comment #1 from hjl at lucon dot org 2007-06-18 15:02 --- Fixed by http://gcc.gnu.org/ml/gcc-cvs/2007-06/msg00569.html -- hjl at lucon dot org changed: What|Removed |Added ---

[Bug fortran/32393] gfortran - incorrect run time results

--- Comment #2 from dominiq at lps dot ens dot fr 2007-06-18 14:52 --- Compiling your code with g95 gives a lot of warnings. You should probably check the use of the different subroutines. In file pr32393.f:189 subroutine clect2 1 In file pr32393.f:155 cal

[Bug fortran/32393] gfortran - incorrect run time results

--- Comment #1 from dir at lanl dot gov 2007-06-18 14:48 --- Here are the mingw32 results - $ gfortran -g -o g95Test01 g95Test01.f [EMAIL PROTECTED] ~/tests $ g95Test01 1 lower triangular matrix with 3 rows row 10.8000E+01 row 20.9000E+01 0.1000E+02 row 30.1

[Bug fortran/32393] New: gfortran - incorrect run time results

This program runs Ok on the Macintosh versions of gfortran. It runs Ok on the i386-pc-mingw32 version of gfortran using -g, but fails using -O3. It always fails on the cygwin version of gfortran - > gfortran -o g95Test01 g95Test01.f > ./g95Test01 1 lower triangular matrix with 3 rows row 1

[Bug target/32392] New: Support using -mrecip w/o additional Newton-Raphson run

Paolo Bonzini wrote: >> That said, there is a whole bunch of applications that would kill for >> -mrecip, > even for 11bit ones. Games are one of them, for sure ;) > What about -mrecip=0/1/2 for the number of NR steps? Or would two steps be > slower than divss? > > I was thinking of adding this

[Bug fortran/32391] Default optimization (level 1) bug of loop optimization (maybe)

--- Comment #3 from sunjoong at gmail dot com 2007-06-18 14:20 --- Created an attachment (id=13729) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13729&action=view) A input data file of TMalign -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391

[Bug fortran/32391] Default optimization (level 1) bug of loop optimization (maybe)

--- Comment #2 from sunjoong at gmail dot com 2007-06-18 14:19 --- Created an attachment (id=13728) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13728&action=view) A input data file of TMalign -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391

[Bug fortran/32391] Default optimization (level 1) bug of loop optimization (maybe)

--- Comment #1 from sunjoong at gmail dot com 2007-06-18 14:18 --- Created an attachment (id=13727) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13727&action=view) A legacy fortran77 program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391

[Bug c/25575] some uninitialized warning disappear when compile without -O

--- Comment #2 from matze at braunis dot de 2007-06-18 14:17 --- Why don't you turn on dataflow computation to get the warning even with -O0? -O0 is typically used for developing/debugging, so as a user I want to see all possible warnings... -- http://gcc.gnu.org/bugzilla/show_bug.c

[Bug fortran/32391] New: Default optimization (level 1) bug of loop optimization (maybe)

This bug occurs on gfortran 4.1 and 4.2 . I think it is not a gfortran specific bug; I checked g77 and g95 on gcc 3.4.6.. I had compiled a legacy fortran77 code and foud a bug; $ gfortran -o TMalign TMalign.f $ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali Aligned length= 89, RMSD= 6.4

[Bug tree-optimization/32390] tree-ssa-math-opts.c performs too many IL scans

--- Comment #2 from dnovillo at google dot com 2007-06-18 14:00 --- Subject: Re: tree-ssa-math-opts.c performs too many IL scans On 6/18/07 9:56 AM, rguenth at gcc dot gnu dot org wrote: > --- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-18 13:56 > --- > All three

[Bug tree-optimization/32390] tree-ssa-math-opts.c performs too many IL scans

--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-18 13:56 --- All three transformations are done at different stages of the optimization pipeline due to various reasons. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32390

[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508

--- Comment #8 from aesok at gcc dot gnu dot org 2007-06-18 13:33 --- Im working on patch for avr target. Anatoly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335

[Bug target/32369] [frv] macro "DF_LIVE_IN" passed 2 arguments, but takes just 1

--- Comment #3 from zadeck at naturalbridge dot com 2007-06-18 13:18 --- Subject: Re: [frv] macro "DF_LIVE_IN" passed 2 arguments, but takes just 1 :reviewmail: patchapp at dberlin dot org wrote: > --- Comment #2 from patchapp at dberlin dot org 2007-06-18 09:55 --- > Subje

[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508

--- Comment #7 from patchapp at dberlin dot org 2007-06-18 12:40 --- Subject: Bug number PR target/32335 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01233.html -- http://gcc.gnu.org/bug

[Bug rtl-optimization/32372] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065

--- Comment #2 from zadeck at naturalbridge dot com 2007-06-18 12:35 --- s/cse/cse1/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372

[Bug rtl-optimization/32372] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065

--- Comment #1 from zadeck at naturalbridge dot com 2007-06-18 12:33 --- I believe that the failure is due to a an insn illegally sharing with a reg_equal note. Insn 8 is modified in regmove. When this happens, the reg_equal note in insn 22 magically changes. That reg_equal note was

[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code

--- Comment #25 from dnovillo at gcc dot gnu dot org 2007-06-18 12:30 --- Fixed symptoms with http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01081.html. Real fix still being discussed. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Adde

[Bug tree-optimization/32390] New: tree-ssa-math-opts.c performs too many IL scans

In tree-ssa-math-opts.c we already had a pass to cse sin and cos. The new reciprocal sqrt pass is mechanically similar to that one. It does a linear scan over the CFG applying these peephole transformations. This new pass should not be doing a separate IL scan to do its job. Perhaps it would be

[Bug rtl-optimization/32366] [4.3 Regression] Segfault in significand_size with -ftree-vectorize

--- Comment #6 from rguenth at gcc dot gnu dot org 2007-06-18 11:28 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug tree-optimization/32353] [4.1/4.2 Regression] Miscompilation with RESULT_DECL

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

[Bug c++/32350] Very high compile times for template code

--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-18 11:26 --- Execution times (seconds) preprocessing : 0.09 ( 0%) usr 0.07 (20%) sys 0.18 ( 0%) wall 376 kB ( 1%) ggc parser: 0.26 ( 0%) usr 0.12 (34%) sys 0.45 ( 0%) wall 33574 kB (81%

[Bug tree-optimization/32378] can't determine dependence (distinct sections of an array)

--- Comment #4 from dorit at il dot ibm dot com 2007-06-18 11:08 --- I see this in the vectorizer dump file (with mainline from a few days ago): (compute_affine_dependence (stmt_a = D.1423_50 = (*a_49(D))[D.1422_48]) (stmt_b = (*a_49(D))[D.1420_51] = D.1425_54) Data ref a: (Data Ref

[Bug tree-optimization/32075] can't determine dependence between p->a[x+i] and p->a[x+i+1] where x is invariant but defined in the function

--- Comment #2 from dorit at il dot ibm dot com 2007-06-18 11:03 --- I see this in the vectorizer dump file (with mainline from a few days ago): (compute_affine_dependence (stmt_a = D.3027_19 = p_7->a[D.3026_18]) (stmt_b = p_7->a[D.3025_17] = D.3027_19) Data ref a: (Data Ref: stmt

[Bug tree-optimization/18219] [4.0/4.1/4.2/4.3 Regression] bloats code by 31%

--- Comment #25 from ubizjak at gmail dot com 2007-06-18 10:17 --- (In reply to comment #24) > MEM[index: ivtmp.39, offset: 0x0fffc] = (MEM[index: ivtmp.35, offset: > 0x0fffc] + 1 << 1) - MEM[index: ivtmp.39, offset: 0x0fffc]; > > > We still get an offset of -4. PR targe

[Bug target/32369] [frv] macro "DF_LIVE_IN" passed 2 arguments, but takes just 1

--- Comment #2 from patchapp at dberlin dot org 2007-06-18 09:55 --- Subject: Bug number PR target/32369 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01225.html -- http://gcc.gnu.org/bug

[Bug middle-end/31723] Use reciprocal and reciprocal square root with -ffast-math

--- Comment #29 from ubizjak at gmail dot com 2007-06-18 08:56 --- Patch was committed to SVN, so closing as fixed. -- ubizjak at gmail dot com changed: What|Removed |Added ---

[Bug tree-optimization/32383] [4.3 regression] ICE with reciprocals and -ffast-math

--- Comment #4 from ubizjak at gmail dot com 2007-06-18 08:33 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED

[Bug tree-optimization/32383] [4.3 regression] ICE with reciprocals and -ffast-math

--- Comment #3 from uros at gcc dot gnu dot org 2007-06-18 08:31 --- Subject: Bug 32383 Author: uros Date: Mon Jun 18 08:30:47 2007 New Revision: 125790 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125790 Log: PR tree-optimization/32383 * targhooks.c (default_b

[Bug fortran/20373] INTRINSIC symbols can be given the wrong type

--- Comment #13 from patchapp at dberlin dot org 2007-06-18 08:00 --- Subject: Bug number PR20373 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01216.html -- http://gcc.gnu.org/bugzilla/s

[Bug tree-optimization/30175] [4.3 Regression] Runtime regressions with mem-ssa merge in Polyhedron and tramp3d-v4

--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-18 07:54 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRM

[Bug bootstrap/32334] Bootstrap comparison failure when comparing stage 2 and 3

--- Comment #2 from redriver at korea dot ac dot kr 2007-06-18 07:40 --- (In reply to comment #1) > What version of GCC are you starting with? > This works for me on an i686-linux-gnu machine (a pentium 4D). > I think I found the problem. Previously, I use the gcc-3.2.2 to bootstrap th