[Bug fortran/32955] New: gfortran.dg/value_4.f90 gives a compiling error with -fdefault-integer-8
Compiling gfortran.dg/value_4.f90 with -fdefault-integer-8 gives the following error: /opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/value_4.f90:76.6: if (delta ((3 * i), j)) call abort () 1 Error: There is no specific function for the generic 'delta' at (1) gcc version 4.3.0 20070731 (experimental) -- Summary: gfortran.dg/value_4.f90 gives a compiling error with - fdefault-integer-8 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32955
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-01 08:21 --- (In reply to comment #1) > This should fix it. This patch is pre-approved (as well as small variations and improvements of it), though it might be worth opening an enhancement PR to note that if the user code has carefully used an array mask of logical(kind=1) to spare memory, we end just wasting memory by converting it all to a default logical kind, don't we? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #23 from rakdver at kam dot mff dot cuni dot cz 2007-08-01 09:55 --- Subject: Re: Bootstrap with vectorization enabled fails with ICE on PPC > Zdenek, do you have the access to a ppc64 machine to work on the bootstrap > problem? I do; however, I got stuck with another bootstrap problem at the moment (vectorization changes alignment of variables, which causes a misscompilation of crtend.o on my machine; once I fix that, I should hopefully be able to reproduce the problem described in this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #22 from victork at il dot ibm dot com 2007-08-01 09:21 --- Zdenek, do you have the access to a ppc64 machine to work on the bootstrap problem? Can I provide an useful assistance? -- Victor -- victork at il dot ibm dot com changed: What|Removed |Added CC||victork at il dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug regression/32582] Bootstrap with vectorization enabled fails with ICE on PPC
--- Comment #24 from dorit at gcc dot gnu dot org 2007-08-01 10:08 --- > I do; however, I got stuck with another bootstrap problem at the moment > (vectorization changes alignment of variables, which causes a > misscompilation of crtend.o on my machine; I wonder if this is related to PR32893? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
[Bug fortran/32945] [4.3 regression] ICE with initialization expressions
--- Comment #2 from patchapp at dberlin dot org 2007-08-01 11:05 --- Subject: Bug number PR32945 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-08/msg00022.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32945
[Bug middle-end/32269] [4.3 Regression] 403.gcc miscompiled
--- Comment #1 from victork at il dot ibm dot com 2007-08-01 11:24 --- I've tried to build and run SPEC2006 403.gcc using r126903 and it did *not* fail. I've used following optimization flags in configuration file: # # Optimization # ## Base is low opt default=base=default=default: COPTIMIZE= -O3 -funroll-loops -fpeel-loops -ftree-vectorize CXXOPTIMIZE = -O3 -funroll-loops -fpeel-loops -ftree-vectorize FOPTIMIZE= -O3 -funroll-loops -fpeel-loops -ftree-vectorize % uname -a Linux lnx-yaakov 2.6.16.21-0.8-smp #1 SMP Mon Jul 3 18:25:39 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32269
[Bug target/32893] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-01 11:57 --- Ryan, I wonder what happens if you force alignment in the source code, like so: unsigned short count[MAXBITS+1] __attribute__ ((__aligned__(16))) ; In this case the vectorizer does not change the alignment of the array. I wonder if the compiler honors the alignment attribute when the user asks for it, rather than the vectorizer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893
[Bug target/32893] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #4 from dorit at gcc dot gnu dot org 2007-08-01 11:36 --- Also just for the record - the testcase for this PR is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413#c14 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893
[Bug target/30961] [4.1/4.2 regression] redundant reg/mem stores/moves
--- Comment #16 from pluto at agmk dot net 2007-08-01 11:30 --- (In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > Created an attachment (id=13550) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13550&action=view) [edit] > > > An experimental patch > > > > > > This patch works for the testcase. > > > > i've applied this patch to 4.2.1 and compile testcases: > > > > convert/m32/m64 look fine. load/m32/m64 still look unoptimal. > > > > Gcc 4.3 works: naturally but its not even been released yet. users awaiting regression fixes for released compilers ;) -- pluto at agmk dot net changed: What|Removed |Added Known to fail|4.0.2 4.1.2 4.2.0 4.3.0 |4.0.2 4.1.2 4.2.1 Summary|[4.1/4.2/4.3 regression]|[4.1/4.2 regression] |redundant reg/mem |redundant reg/mem |stores/moves|stores/moves http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug fortran/32945] [4.3 regression] ICE with initialization expressions
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-08-01 12:53 --- Subject: Bug 32945 Author: dfranke Date: Wed Aug 1 12:52:48 2007 New Revision: 127124 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127124 Log: gcc/fortran: 2007-08-01 Daniel Franke <[EMAIL PROTECTED]> PR fortran/32945 * expr.c (check_specification_function): Skip check if no symtree is available. gcc/testsuite: 2007-08-01 Daniel Franke <[EMAIL PROTECTED]> PR fortran/32945 * gfortran.dg/initialization_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/initialization_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32945
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #3 from dominiq at lps dot ens dot fr 2007-08-01 13:51 --- The first test of PR32770, i.e.: program main real, dimension(2) :: a call random_number(a) print *,maxloc(a,mask=.true.) end program main with -fdefault-integer-8 and your patch, gives (PPC Darwin8): pr32770.f90:5.16: end program main 1 Internal Error at (1): pr32770.f90:4.24: print *,maxloc(a,mask=.true.) 1 Can't convert LOGICAL(8) to LOGICAL(8) at (1) Anything wrong on my side? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug fortran/32945] [4.3 regression] ICE with initialization expressions
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-08-01 13:55 --- Florian, thanks for the report! Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32945
[Bug testsuite/32956] New: Compiling equiv_7_db.f90 gives an error with -fdefault-integer-8
Compiling equiv_7_db.f90 with -fdefault-integer-8 gives: /opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/equiv_7.f90:89.38: data large(1),large(2) /2146435071,-1/ 1 Error: Overlapping unequal initializers in EQUIVALENCE at (1) /opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/equiv_7.f90:79.30: data large(1),large(2) /-1,2146435071/ 1 Error: Overlapping unequal initializers in EQUIVALENCE at (1) The following patch fix the problem: [karma] f90/bug% diff -u /opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/equiv_7.f90 equiv_7_db.f90 --- /opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/equiv_7.f90 2007-07-30 10:50:18.0 +0200 +++ equiv_7_db.f90 2007-08-01 16:15:12.0 +0200 @@ -72,21 +72,23 @@ function d1mach_little(i) result(d1mach) implicit none double precision d1mach,dmach(5) -integer i,large(4),small(4) +integer(4) large(4),small(4) +integer i equivalence ( dmach(1), small(1) ) equivalence ( dmach(2), large(1) ) -data small(1),small(2) / 0, 1048576/ -data large(1),large(2) /-1,2146435071/ +data small(1),small(2) / 0_4, 1048576_4/ +data large(1),large(2) /-1_4,2146435071_4/ d1mach = dmach(i) end function d1mach_little function d1mach_big(i) result(d1mach) implicit none double precision d1mach,dmach(5) -integer i,large(4),small(4) +integer(4) large(4),small(4) +integer i equivalence ( dmach(1), small(1) ) equivalence ( dmach(2), large(1) ) -data small(1),small(2) /1048576,0/ -data large(1),large(2) /2146435071,-1/ +data small(1),small(2) /1048576_4,0_4/ +data large(1),large(2) /2146435071_4,-1_4/ d1mach = dmach(i) end function d1mach_big subroutine derived_types -- Summary: Compiling equiv_7_db.f90 gives an error with -fdefault- integer-8 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32956
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #4 from dominiq at lps dot ens dot fr 2007-08-01 14:28 --- gfortran.dg/minmaxloc_1.f90 gives the same error in my build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug fortran/32957] New: C/Fortran interoperability and -fdefault-integer-8
Many failures in the test suite with -fdefault-integer-8 come from tests mixing C and Fortran. While definitively not an expert in this area, I find pretty obvious that changing the default integer/real type on one side and not the other is asking for troubles. Apparently gfortran, but not the test suite, is finding some of them as in gfortran.dg/c_loc_tests_2.f03: [karma] f90/bug% gfc -fdefault-integer-8 /opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/c_loc_tests_2.f03 /opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/c_loc_tests_2.f03:53.37: if(test_array_address(my_c_ptr_1, 100) .ne. 1) then 1 Error: Type/rank mismatch in argument 'num_elements' at (1) /opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.dg/c_loc_tests_2.f03:83.19: use c_loc_tests_2 1 Fatal Error: Can't open module file 'c_loc_tests_2.mod' for reading at (1): No such file or directory Using -fdefault-integer-8 with 'intrinsic :: iso_c_binding' should probably trigger an error or at least a warning. -- Summary: C/Fortran interoperability and -fdefault-integer-8 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32957
[Bug fortran/32957] C/Fortran interoperability and -fdefault-integer-8
--- Comment #1 from kargl at gcc dot gnu dot org 2007-08-01 15:04 --- At this point, the easiest fix is probably going to be to document that -fdefault-integer-8 should not be used with bind(c) code. A check of this option can be inserted at various locations during the parsing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32957
[Bug testsuite/32956] Compiling equiv_7_db.f90 gives an error with -fdefault-integer-8
--- Comment #1 from dominiq at lps dot ens dot fr 2007-08-01 15:10 --- A similar problem occurs with gfortran.fortran-torture/execute/equiv_5.f which hangs (does not stop, but no CPU time used). The following patch makes the test pass: [karma] f90/bug% diff /opt/gcc/gcc-4.3-work/gcc/testsuite/gfortran.fortran-torture/execute/equiv_5.f equiv_5_db.f 17,21c17,21 < INTEGER SMALL(2) < INTEGER LARGE(2) < INTEGER RIGHT(2) < INTEGER DIVER(2) < INTEGER LOG10(2) --- > INTEGER(4) SMALL(2) > INTEGER(4) LARGE(2) > INTEGER(4) RIGHT(2) > INTEGER(4) DIVER(2) > INTEGER(4) LOG10(2) 212c212,213 < INTEGER A, A1, B, C, D --- > INTEGER(4) A > INTEGER A1, B, C, D The reason why it works is pretty obvious, but I don't have any idea on how gfortran can detect the problem with the original test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32956
[Bug other/32958] New: tgmath.h includes non-existant header file complex.h
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-1.c -std=iso9899:1999 -fno-show -column -E -o c99-tgmath-1.i(timeout = 300) In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-1.c:7: /test/gnu/gcc/objdir/gcc/include/tgmath.h:38: error: complex.h: No such file or directory compiler exited with status 1 output is: In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-1.c:7: /test/gnu/gcc/objdir/gcc/include/tgmath.h:38: error: complex.h: No such file or directory FAIL: gcc.dg/c99-tgmath-1.c (test for excess errors) Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c -std=iso9899:1999 -fno-show -column -S -o c99-tgmath-2.s(timeout = 300) In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:7: /test/gnu/gcc/objdir/gcc/include/tgmath.h:38: error: complex.h: No such file or directory /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c: In function 'foo': /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: implicit decl aration of function 'csinl' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: incompatible implicit declaration of built-in function 'csinl' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: error: 'csin' undeclar ed (first use in this function) /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: error: (Each undeclare d identifier is reported only once /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: error: for each functi on it appears in.) /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: implicit decl aration of function 'csinf' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: incompatible implicit declaration of built-in function 'csinf' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: implicit decl aration of function 'sinl' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: incompatible implicit declaration of built-in function 'sinl' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: implicit decl aration of function 'sinf' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: incompatible implicit declaration of built-in function 'sinf' compiler exited with status 1 output is: In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:7: /test/gnu/gcc/objdir/gcc/include/tgmath.h:38: error: complex.h: No such file or directory /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c: In function 'foo': /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: implicit decl aration of function 'csinl' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: incompatible implicit declaration of built-in function 'csinl' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: error: 'csin' undeclar ed (first use in this function) /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: error: (Each undeclare d identifier is reported only once /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: error: for each functi on it appears in.) /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: implicit decl aration of function 'csinf' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: incompatible implicit declaration of built-in function 'csinf' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: implicit decl aration of function 'sinl' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: incompatible implicit declaration of built-in function 'sinl' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: implicit decl aration of function 'sinf' /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-2.c:11: warning: incompatible implicit declaration of built-in function 'sinf' FAIL: gcc.dg/c99-tgmath-2.c (test for excess errors) Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-3.c -std=iso9899:1999 -fno-show -column -S -o c99-tgmath-3.s(timeout = 300) In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-3.c:7: /test/gnu/gcc/objdir/gcc/include/tgmath.h:38: error: complex.h: No such file or directory /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-3.c:9: error: expected '=', ', ', ';', 'asm' or '__attribute__' before 'double' compiler exited with status 1 output is: In file included from /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-3.c:7: /test/gnu/gcc/objdir/gcc/include/tgmath.h:38: error: complex.h: No such file or directory /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/c99-tgmath-3.c:9: error: expected '=', ', ', ';', 'asm' or '__attribute__' before 'double' FAIL: gcc.dg/c99-tgmath-3.c (test for excess errors) Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gc
[Bug c/29493] -masm=intel - does not emit right asm code
--- Comment #1 from ungala_le_babou at hotmail dot com 2007-08-01 15:26 --- I'm making an internship so i cannot change my version of gcc (which 4.1.1). Since the bug is still unconfirmed, I wonder if it was fixed in the latest version of gcc... -- ungala_le_babou at hotmail dot com changed: What|Removed |Added CC||ungala_le_babou at hotmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29493
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #5 from dominiq at lps dot ens dot fr 2007-08-01 15:36 --- I have had a nonexpert look at the patch and I wonder if + ts.kind = gfc_default_logical_kind; should not be + ts.kind = newkind; ??? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug bootstrap/32959] New: msgfmt fails on file libcpp/po/fr.po
My build of gcc fails with an error running msgfmt. If I do /usr/bin/msgfmt --statistics libcpp/po/fr.po -o /dev/null I get failure with the current gcc (rev 127119) but if I use the file fr.po from rev 111982 the command works. Does the fix need to happen to fr.po or to my msgfmt binary? I have Fedora Core 6 installed, with gettext RPM 0.14.6-4. -- Summary: msgfmt fails on file libcpp/po/fr.po Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32959
[Bug tree-optimization/32919] [4.3 Regression] SSA corruption because of abnormal edges and PRE
--- Comment #4 from drow at gcc dot gnu dot org 2007-08-01 16:53 --- Subject: Bug 32919 Author: drow Date: Wed Aug 1 16:53:01 2007 New Revision: 127132 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127132 Log: PR tree-optimization/32919 * tree-ssa-sccvn.c (visit_phi): Do not visit abnormal PHIs. * tree-ssa-coalesce.c (ssa_conflicts_dump): New. (coalesce_ssa_name): Call it. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32919.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-coalesce.c trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32919
[Bug tree-optimization/32919] [4.3 Regression] SSA corruption because of abnormal edges and PRE
--- Comment #5 from drow at gcc dot gnu dot org 2007-08-01 16:58 --- This is fixed now. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32919
[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #16 from danglin at gcc dot gnu dot org 2007-08-01 16:30 --- A similar error appeared in revision 127096 on hppa-unknown-linux-gnu: /home/dave/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bits/stl_algo.h: In fu nction '_ForwardIterator std::__search_n(_ForwardIterator, _ForwardIterator, _In teger, const _Tp&, std::forward_iterator_tag) [with _ForwardIterator = __gnu_tes t::forward_iterator_wrapper, _Integer = int, _Tp = Y]': /home/dave/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bits/stl_algo.h:754: e rror: definition in block 21 does not dominate use in block 24 for SSA_NAME: __i$D55786$SharedInfo_40 in statement: if (__i$D55786$SharedInfo_40 != D.56866_41) /home/dave/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bits/stl_algo.h:754: i nternal compiler error: verify_ssa failed ... FAIL: 25_algorithms/search_n/check_type.cc (test for excess errors) I'm also seeing on hpux FAIL: 25_algorithms/search_n/iterator.cc execution test Program received signal SIGBUS, Bus error. __gnu_test::forward_iterator_wrapper std::__search_n<__gnu_test::forward_iterator_wrapper, int, int, bool (*)(int, int)>(__gnu_test::forward_iterator_wrapper, __gnu_test::forward_iterator_wrapper, int, int const&, bool (*)(int, int), std::forward_iterator_tag) ([EMAIL PROTECTED], [EMAIL PROTECTED], __count=2, [EMAIL PROTECTED], [EMAIL PROTECTED]: 0x3140 <_Z4predii>) at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/util/testsuite_iterators.h:195 195 : ptr(in.ptr), SharedInfo(in.SharedInfo) (gdb) bt #0 __gnu_test::forward_iterator_wrapper std::__search_n<__gnu_test::forward_iterator_wrapper, int, int, bool (*)(int, int)>(__gnu_test::forward_iterator_wrapper, __gnu_test::forward_iterator_wrapper, int, int const&, bool (*)(int, int), std::forward_iterator_tag) ([EMAIL PROTECTED], [EMAIL PROTECTED], __count=2, [EMAIL PROTECTED], [EMAIL PROTECTED]: 0x3140 <_Z4predii>) at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/util/testsuite_iterators.h:195 #1 0x3b50 in __gnu_test::forward_iterator_wrapper std::search_n<__gnu_test::forward_iterator_wrapper, int, int, bool (*)(int, int)>(__gnu_test::forward_iterator_wrapper, __gnu_test::forward_iterator_wrapper, int, int const&, bool (*)(int, int)) ([EMAIL PROTECTED], [EMAIL PROTECTED], __count=1073747616, [EMAIL PROTECTED], [EMAIL PROTECTED]: 0x3140 <_Z4predii>) at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/util/testsuite_iterators.h:195 #2 0x5e7c in main () at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/25_algorithms/search_n/iterator.cc:87 The bus error doesn't occur at -O0 and -O1. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #6 from kargl at gcc dot gnu dot org 2007-08-01 17:16 --- (In reply to comment #5) > I have had a nonexpert look at the patch and I wonder if > > + ts.kind = gfc_default_logical_kind; > > should not be > > + ts.kind = newkind; > Yes, I believe you are correct. Thomas, can you update your patch? -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #17 from danglin at gcc dot gnu dot org 2007-08-01 17:27 --- Looking at the hpux failure, it seems _ZSt8search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiPFbiiEET_S5_S5_T0_RKT 1_T2_ is miscompiled. The problem is probably the same as reported in PR32878. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug testsuite/32956] Compiling equiv_7_db.f90 gives an error with -fdefault-integer-8
--- Comment #2 from kargl at gcc dot gnu dot org 2007-08-01 17:29 --- These two examples are the poster child for 1) Why -fdefault-integer-8 is a bad option and should only be used by people who are prepared to have broken results. 2) Why EQUIVALENCE is a horribly abused construct. In fact, from equiv_7.f90, this is invalid function d1mach_big(i) result(d1mach) implicit none double precision d1mach,dmach(5) integer i,large(4),small(4) equivalence ( dmach(1), small(1) ) equivalence ( dmach(2), large(1) ) data small(1),small(2) /1048576,0/ data large(1),large(2) /2146435071,-1/ d1mach = dmach(i) end function d1mach_big -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32956
[Bug target/32264] gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
--- Comment #9 from pluto at agmk dot net 2007-08-01 17:37 --- (In reply to comment #7) > i have tracked down module by module of the kernel > and after all i found the module which caused the > kernel crash - its arch/i386/kernel/i8259.c diffing assembly dumps for these objects shows that 4.2 output doesn't contain common_interrupt, call_do_IRQ and IRQ0x$_interrupt code. could you provide the preprocessed i8259.i file? (hint: --save-temps gcc option). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32264
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #7 from tkoenig at alice-dsl dot net 2007-08-01 17:46 --- Subject: Re: mask and -fdefault-integer-8 On Wed, 2007-08-01 at 15:36 +, dominiq at lps dot ens dot fr wrote: > > --- Comment #5 from dominiq at lps dot ens dot fr 2007-08-01 15:36 > --- > I have had a nonexpert look at the patch and I wonder if > > + ts.kind = gfc_default_logical_kind; > > should not be > > + ts.kind = newkind; You are entirely correct. I've updated the patch and will commit the corrected version once the regression-test has passed and I've written up a ChangeLog entry. I'll use minmaxloc_1.f90 with "-fdefault-integer-8" as the test case. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug c/32960] New: no warning for conflicting attributes on separate decls
Compile this: extern void f(void); extern void g(void) __attribute__ ((hot)) __attribute__((cold)); extern void f(void) __attribute__ ((hot)); extern void f(void) __attribute__ ((cold)); I see a warning for the conflicting attributes on 'g', but not for 'f'. The problem here is that the attribute handler is not called for the smashed decl, only for the one currently being constructed. -- Summary: no warning for conflicting attributes on separate decls Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32960
[Bug fortran/32936] ALLOCATE: "STAT expression ... must be a variable" - but it is one
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-01 17:55 --- Subject: Bug 32936 Author: burnus Date: Wed Aug 1 17:55:24 2007 New Revision: 127135 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127135 Log: 2007-08-01 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/32936 * match.c (gfc_match_allocate): Better check that STAT is a variable. * check.c (gfc_check_allocated): Reorder checks to improve error message. 2007-08-01 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/32936 * gfortran.dg/allocate_stat.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/allocate_stat.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32936
[Bug fortran/32936] ALLOCATE: "STAT expression ... must be a variable" - but it is one
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-01 18:00 --- FIXED in GCC 4.3; as it is not regression [and no wrong-code bug either] I will not backport it to 4.2.x or 4.1.x -> mark as fixed. Note: GCC gfortran 4.3.0 nightly builds are e.g. available at http://gcc.gnu.org/wiki/GFortranBinaries -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32936
[Bug fortran/32795] allocatable components are nullified prematurely
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-01 18:39 --- > Could somebody test the patch below, please? Build (/= bootstrapped) and check-gfortran'ed (-m64) on x86-64-Linux. I get an ICE (segmentation fault) for gfortran.dg/derived_comp_array_ref_1.f90: ==26501== Invalid read of size 8 ==26501==at 0x482610: structure_alloc_comps (trans-array.c:5158) ==26501==by 0x4AB106: generate_loop_for_temp_to_lhs (trans-stmt.c:1737) Analogously for gfortran.dg/forall_char_dependencies_1.f90 except that valgrind does not show an error. gdb shows: Program received signal SIGSEGV, Segmentation fault. structure_alloc_comps (der_type=0x0, decl=0x2abe5b14b000, dest=0x0, rank=0, purpose=1)at trans-array.c:5158 5158 for (c = der_type->components; c; c = c->next) #1 0x004ab107 in generate_loop_for_temp_to_lhs (expr=0xf57ff0, tmp1=0x2abe5b129f20, count3=0x0, count1=0x2abe5b129e70, wheremask=0x0, invert=0 '\0') at trans-stmt.c:1737 The problem is that expr->ts.derived == NULL in + falselhs = gfc_deallocate_alloc_comp (expr->ts.derived, falselhs, 0); and that gfc_deallocate_alloc_comp simply accesses expr->ts.derived->component without ever checking if expr->ts.derived is NULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32795
[Bug c/32961] New: GCC 4.2 has different requirements for x86 shift xmm intrinsics
I have some code that uses _mm_slli_epi32 intrinsics and some other shift ones.
This code compiles fine in GCC 4.1/4.0 and ICC 9.1.
I tried compiling it with GCC 4.2 and I get the error
testt.c:4: error: shift must be an immediate
_mm_slli_epi32 is defined as:
__m128i _mm_slli_epi32 (__m128i m, int count)
Unfortunately, it seems like GCC 4.2 is requiring count to be an immediate. If
an immediate were intended to be required I believe it would be named "int imm"
instead of "int count" like how _mm_slli_si128 is defined.
Here's a test case that compiles with ICC 9.1, GCC 4.0, and GCC 4.1, but not
GCC 4.2:
#include
void a( int n ) {
__m128i a;
a = _mm_slli_epi32( a, n );
}
I've also tried different flags, including both -m32 and -m64 to see if it was
an issue with that. Nothing fixed it.
--
Summary: GCC 4.2 has different requirements for x86 shift xmm
intrinsics
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikelikespie at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-08-01 18:49 --- Even with the correction, the patch didn't pass regression-testing. It's a good thing we do this. I'll continue my investigations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug c/32961] GCC 4.2 has different requirements for x86 shift xmm intrinsics
--- Comment #1 from mikelikespie at gmail dot com 2007-08-01 18:50 --- I forgot to mention, I'm running the latest gentoo with amd64, and gcc (GCC) 4.2.0 (Gentoo 4.2.0 p1.4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32961
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #9 from dominiq at lps dot ens dot fr 2007-08-01 19:05 --- With the change my tests now compile (regtesting!-), but gfortran.dg/zero_sized_1.f90 aborts. BTW I don't understand the error: Can't convert LOGICAL(8) to LOGICAL(8) at (1) How can a "no operation" trigger an error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #10 from dominiq at lps dot ens dot fr 2007-08-01 19:08 --- Sorry it was a "Bus error" and not an abort: Host Name: pbook Date/Time: 2007-08-01 20:54:37.875 +0200 OS Version: 10.4.10 (Build 8R218) Report Version: 4 Command: a.out Path:a.out Parent: tcsh [16119] Version: ??? (???) PID:2084 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0004 Thread 0 Crashed: 0 libgfortran.3.dylib 0x00473cf4 pack_internal + 468 (pack_generic.c:240) 1 a.out 0xc0ac test_pack_ + 3124 2 a.out 0xf380 MAIN__ + 68 3 a.out 0xf3c8 main + 48 (fmain.c:26) 4 a.out 0x25dc _start + 760 5 a.out 0x22e0 start + 48 Thread 0 crashed with PPC Thread State 64: srr0: 0x00473cf4 srr1: 0x1000f030 vrsave: 0x cr: 0x42084024 xer: 0x lr: 0x00473ee8 ctr: 0x90003f28 r0: 0x r1: 0xbfffdba0 r2: 0x r3: 0x006005e0 r4: 0x0040 r5: 0xbfffdfac r6: 0x0007 r7: 0x000a r8: 0x0070200f r9: 0x003c r10: 0x007b r11: 0x42080022 r12: 0x90003938 r13: 0x r14: 0xbfffdd50 r15: 0xbfffdd38 r16: 0xbfffdc14 r17: 0x0008 r18: 0x r19: 0x0008 r20: 0x0008 r21: 0x r22: 0x0008 r23: 0x r24: 0x006005e0 r25: 0x0002 r26: 0x r27: 0xbfffdc2c r28: 0xbfffdbf4 r29: 0x006005d0 r30: 0x0004 r31: 0x00473b30 Binary Images Description: 0x1000 - 0x a.out /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out 0x15000 -0x20fff libgcc_s.1.dylib /opt/gcc/gcc4.3w/lib/libgcc_s.1.dylib 0x7f000 -0x8afff libgcc_s.1.dylib/libgcc_s.1.dylib 0x405000 - 0x481fff libgfortran.3.dylib /opt/gcc/gcc4.3w/lib/libgfortran.3.dylib 0x8fe0 - 0x8fe52fff dyld 46.12 /usr/lib/dyld 0x9000 - 0x901bcfff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x90214000 - 0x90219fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #12 from tkoenig at gcc dot gnu dot org 2007-08-01 19:21 --- Created an attachment (id=14003) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14003&action=view) proposed patch (second try) This one should be better. Currently regtesting. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #14002|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #11 from dominiq at lps dot ens dot fr 2007-08-01 19:11 --- The problem is with PACK. If I comment the line call test_pack the test pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug target/32264] gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
--- Comment #10 from axel at freakout dot de 2007-08-01 19:25 --- Subject: Re: gcc 4.2.0 compiled vanilla kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3 According to pluto at agmk dot net: > diffing assembly dumps for these objects shows that > 4.2 output doesn't contain common_interrupt, call_do_IRQ > and IRQ0x$_interrupt code. could you provide the preprocessed > i8259.i file? (hint: --save-temps gcc option). > attached i8259.tar.gz with i8259.[ciso] compiled with gcc-4.2.1 --save-temps and kernel 2.4.35. Axel --- Comment #11 from axel at freakout dot de 2007-08-01 19:25 --- Created an attachment (id=14004) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14004&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32264
[Bug c++/32400] [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
--- Comment #5 from falk at debian dot org 2007-08-01 20:15 ---
Actually, two lines suffice:
template static inline void f() { }
template<> inline void f<5>() { }
This also breaks inkscape.
--
falk at debian dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #13 from dominiq at lps dot ens dot fr 2007-08-01 20:17 --- I still have the "Bus error". From the backtrace I think the culprit is libgfortran/intrinsics/pack_generic.c. Probably around the lines: pack_internal (gfc_array_char *ret, const gfc_array_char *array, const gfc_array_l4 *mask, const gfc_array_char *vector, index_type size) and const GFC_LOGICAL_4 *mptr; and may be other places I may have missed. What makes pack_internal special? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-01 20:01 --- Confirmed with 4.3.0 of today on PPC Darwin8: original = ( 2.00 , 0.00 ) ( 3.00 , 0.00 ) ( 7.00 , 0.00 ) ( 11.0 , 0.00 ) WRONG conjg(transpose(a)) = (-1.506281629186761E-154, 1.506293009711558E-154) ( 1.382417208487872E+306,-1.382417208482782E+306) (-1.506293009711557E-154, 1.506293009711558E-154) ( 2.00 , -0.00 ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- Comment #1 from wirawan0 at gmail dot com 2007-08-01 20:00 --- Created an attachment (id=14006) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14006&action=view) Failing testcase with higher-dimensional b array I found that the result of conjg(transpose(a)) is also wrong if b is a part of higher-dimensional array (see testcase): b(:,:,i) = conjg(transpose(a)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
[Bug target/32963] ICE in failed_reload, could not find a spill register
--- Comment #1 from sje at cup dot hp dot com 2007-08-01 19:54 --- Created an attachment (id=14005) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14005&action=view) test program that will ICE at -O2 Attached is a Fortran test program that will ICE if compiled at -O2 on IA64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32963
[Bug c++/32658] Supposedly illegal conversion compiles without errors
--- Comment #5 from nathan at gcc dot gnu dot org 2007-08-01 19:42 --- The standard is unclear about exactly why this is ill-defined. Does the conversion operator take part in overload resolution (and then be rejected, if it is selected), or is it never entered into the overload set. I shall query CWG. -- nathan at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-01 19:42:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32658
[Bug fortran/32962] New: b = conjg(transpose(a)) is erroneous if b is an allocatable array
It turns out that bug #31994 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994) has not been fully resolved! I found another testcase that would fail gcc 4.2.1, namely if the destination of the expression is an allocatable array. Use the following testcase: program testcase complex(kind=8), allocatable :: a(:,:), b(:,:) allocate(a(2,2)) allocate(b(2,2)) a(1,1) = 2 a(2,1) = 3 a(1,2) = 7 a(2,2) = 11 b = conjg(transpose(a)) ! This does NOT work with gcc 4.2.1 print *, 'original = ', a print *, 'WRONG conjg(transpose(a)) = ', b end program OBSERVATIONS: * The bug appears regardless whether a is allocatable or not. * The bug does not appear if b is NOT an allocatable array, e.g. a complex(kind=8),dimension(2,2) in the testcase above. * The bug does not appear if we reverse the order of expression to: b = transpose(conjg(a)) . -- Summary: b = conjg(transpose(a)) is erroneous if b is an allocatable array Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wirawan0 at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
[Bug target/32963] New: ICE in failed_reload, could not find a spill register
I believe this is due to the new floating point division code that I put it in. I am looking at changing the convert functions in div.md back to UNSPECs and I believe this will fix the problem. I will attach a test program. -- Summary: ICE in failed_reload, could not find a spill register Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com GCC host triplet: ia64-*-* GCC target triplet: ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32963
[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- Comment #3 from wirawan0 at gmail dot com 2007-08-01 20:02 --- Created an attachment (id=14007) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14007&action=view) Magically successful testcase! And by the way, if BOTH b and a are part of higher-dimensional arrays (see testcase), then b(:,:,1) = conjg(transpose(a(:,:,1))) magically works again! Wirawan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #15 from tkoenig at gcc dot gnu dot org 2007-08-01 20:44 --- (In reply to comment #13) > I still have the "Bus error". From the backtrace I think the culprit is > libgfortran/intrinsics/pack_generic.c. Probably around the lines: Hi Dominique, I just committed a corrected version of the patch. Does the failure persist? I'm leaving this open for the moment, to catch anything that may have gone wrong (or that still hasn't been corrected). BTW, internal_pack is called by the compiler itself to pack array slices etc. where necessary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #14 from tkoenig at gcc dot gnu dot org 2007-08-01 20:27 --- Subject: Bug 32954 Author: tkoenig Date: Wed Aug 1 20:27:27 2007 New Revision: 127137 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127137 Log: 2007-08-01 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/32954 * intrinsic.c (resolve_mask_arg): New function. (gfc_resolve_maxloc): Use resolve_mask_arg for mask resolution. (gfc_resolve_maxval): Likewise. (gfc_resolve_minloc): Likewise. (gfc_resolve_minval): Likewise. (gfc_resolve_pack): Likewise. (gfc_resolve_product): Likewise. (gfc_resolve_sum): Likewise. (gfc_resolve_unpack): Likewise. 2007-08-01 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/32954 * minmaxloc_3.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/minmaxloc_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug libfortran/32954] mask and -fdefault-integer-8
--- Comment #16 from dominiq at lps dot ens dot fr 2007-08-01 21:19 ---
As far as I can tell, I have applied correctly your latest patch. But the
following reduced test
! { dg-do run }
! Transformational functions for zero-sized array and array sections
! Contributed by Francois-Xavier Coudert <[EMAIL PROTECTED]>
integer,allocatable :: foo(:,:)
allocate(foo(0,1:7))
foo = 1
if (size(pack(foo,foo/=0,(/1,3,4,5,1,0,7,9/))) /= 8 ) call abort
deallocate(foo)
end
gives a "Bus error" with -fdefault-integer-8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
[Bug c++/32400] [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-01 21:29 --- (In reply to comment #5) > Actually, two lines suffice: I don't remember if template functions can be static. I really think they cannot. Which is one of the reasons why this bug was not marked as confirmed or have a keyword assigned to it. Note PR 32596 is definitely valid code, anonymous namespaces templates. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug tree-optimization/32964] New: union cause ineffient code inside loops
Testcase:
union A
{
float a;
};
float t(float a)
{
union A a1, a2, a3;
a1.a = a;
for(int i =0;i<100;i++)
{
a2 = a1;
a2.a += a;
a1 = a2;
}
a3 = a1;
return a3.a;
}
--
We currently get on powerpc-linux-gnu in the inner loop:
.L2:
stw 0,8(1)
lfs 0,8(1)
fadds 0,1,0
stfs 0,8(1)
lwz 0,8(1)
bdnz .L2
Notice how we are storing and loading from the same address twice in the loop.
That is bad news for the Cell.
This also happens on x86:
.L2:
flds-4(%ebp) <--- load a1.a
addl$1, %eax
fadd%st(1), %st
cmpl$100, %eax
fstps -8(%ebp) <--- store a2.a
movl-8(%ebp), %edx <--- load a2.a
movl%edx, -4(%ebp) <--- store a1.a
jne .L2
--
Summary: union cause ineffient code inside loops
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32964
[Bug tree-optimization/32964] [4.3 Regression] union cause ineffient code inside loops
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-01 23:16 --- Hmm, the trunk is worse than the 4.2 branch for -msse2 -mfpmath=sse. Trunk: .L2: movss -4(%ebp), %xmm1 addl$1, %eax cmpl$100, %eax addss %xmm0, %xmm1 movss %xmm1, -8(%ebp) movl-8(%ebp), %edx movl%edx, -4(%ebp) jne .L2 4.2.0: .L2: movaps %xmm2, %xmm0 addl$1, %eax addss %xmm1, %xmm0 cmpl$100, %eax movaps %xmm0, %xmm1 jne .L2 So I guess I can mark this as a regression :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|union cause ineffient code |[4.3 Regression] union cause |inside loops|ineffient code inside loops Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32964
[Bug tree-optimization/32964] [4.3 Regression] union cause ineffient code inside loops
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-01 23:18 --- One should note the original testcase included a vector float and a struct inside the union and used C++, this is just a reduced testcase of the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32964
[Bug tree-optimization/32653] [4.3 Regression] Bootstrap failure with excessive memory consumption in tree-ssa-pre compiling libjava/interperter.c
--- Comment #1 from daney at gcc dot gnu dot org 2007-08-02 00:38 --- Still happens in: revision 127079 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32653
[Bug middle-end/32940] REG_POINTER attribute on DECL_ARTIFICIAL pointers
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-02 00:37 --- Created an attachment (id=14008) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14008&action=view) Patch which needs full testing still Hi, this reverts Jeff's patch in both stmt.c and cfgexpand.c (I don't know how much code of stmt.c's function is still used though). This patch has not been bootstrapped and tested yet and after it gets done, it still needs an extra test on hppa-hpux as that is what Jeff's patch was trying to fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32940
[Bug middle-end/32940] REG_POINTER attribute on DECL_ARTIFICIAL pointers
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-02 00:31 --- .L4: slwi 0,3,2 lwzx 0,9,0 add 3,3,4 addi 4,4,-1 bdnz .L4 Much better correct? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32940
[Bug other/29049] possible problem: building gcc >= 4.2 on i686 GNU/Linux|SMP (non-64bit) platform fails
--- Comment #30 from lauras at gcc dot gnu dot org 2007-08-02 01:13 --- For the record, this was caused by obsolete awk version, please upgrade if you experience this problem. The need to document awk prerequisite is tracked in PR 30739. -- lauras at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
[Bug other/29049] possible problem: building gcc >= 4.2 on i686 GNU/Linux|SMP (non-64bit) platform fails
--- Comment #31 from lauras at gcc dot gnu dot org 2007-08-02 01:14 --- Closing. -- lauras at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
[Bug c/32960] no warning for conflicting attributes on separate decls
--- Comment #2 from tromey at gcc dot gnu dot org 2007-08-02 02:17 --- Yeah -- I looked at the other bugs before filing this one. The issue here is that the hot/cold code already checks for the conflict; but we merge without calling the handlers, so the check is never triggered. I didn't look to see if the inline stuff does the same. One possible fix might be to re-run the handlers when merging. I don't know if that would have undesirable side effects. Another fix would be to move consistency checking into a separate function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32960
[Bug c/32960] no warning for conflicting attributes on separate decls
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-02 02:10 --- I have filed other bug reports about stuff like this, we currently accept noinline and alwaysinline which are more conflicting than hot and cold. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32960
[Bug web/32965] New: missing documentation for -ftree-dse
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html shows -ftree-dse as an optimization enabled by -O / -O1, but doesn't document it below. via http://tinyurl.com/3cdlnu Per tree-ssa-dce.c: A dead store is a store into a memory location which will later be overwritten by another store without any intervening loads. In this case the earlier store can be deleted. -- Summary: missing documentation for -ftree-dse Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmoore-gcc at plaxo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32965
[Bug middle-end/32668] The type-generic builtins apply default promotions
--- Comment #7 from ghazi at gcc dot gnu dot org 2007-08-02 02:57 --- Subject: Bug 32668 Author: ghazi Date: Thu Aug 2 02:57:26 2007 New Revision: 127146 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127146 Log: gcc/cp: PR middle-end/32668 * call.c (magic_varargs_p): Honor the "type generic" attribute. gcc/testsuite: * g++.dg/torture/type-generic-1.C: New. * gcc.dg/pr28796-2.c: Move tests ... * gcc.dg/tg-tests.h: ... here. * gcc.dg/torture/type-generic-1.c: New. Added: trunk/gcc/testsuite/g++.dg/torture/type-generic-1.C trunk/gcc/testsuite/gcc.dg/torture/type-generic-1.c Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr28796-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32668
[Bug web/32965] missing documentation for -ftree-dse
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-02 02:33 --- Confirmed. This was listed on PR 13756. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||13756 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-02 02:33:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32965
[Bug c++/32966] New: bad diagnostic
This:
#include
class system { system() {} };
int foo(system* p) {}
gets you:
~/ootbc/systemspec/build$ g++ foo.cc
foo.cc:4: error: 'p' was not declared in this scope
foo.cc:4: error: expected ',' or ';' before '{' token
The problem is that the function int system(...) is in scope so "system" on
line 4 is not recognized as a type and I guess the compiler is trying to parse
it as an expression (with "*" as the multiply operator). However, there's no
language construction " ()" that I know of.
--
Summary: bad diagnostic
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32966
[Bug c++/32966] bad diagnostic
--- Comment #1 from igodard at pacbell dot net 2007-08-02 05:32 --- Doh! a constructor. Sorry to trouble you. -- igodard at pacbell dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32966
[Bug fortran/32962] b = conjg(transpose(a)) is erroneous if b is an allocatable array
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-08-02 05:42 --- Confirmed. Paul, I'm putting you on the CC list because you fixed PR 31994, the original conjg(transpose()) bug. Maybe you can do something about this one :-) Thomas -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot ||org, tkoenig at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-02 05:42:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32962
