[Bug fortran/38883] [4.4 Regression] ICE for MVBITS with derived type argument that has run-time subscripts
--- Comment #6 from domob at gcc dot gnu dot org 2009-01-25 08:36 --- (In reply to comment #4) in gfc_conv_elemental_dependencies which then in gfc_trans_allocate_array_storage gets accessed as: tmp = TREE_TYPE (initial); /* Pointer to descriptor. */ gcc_assert (TREE_CODE (tmp) == POINTER_TYPE); tmp = TREE_TYPE (tmp); /* The descriptor itself. */ tmp = gfc_get_element_type (tmp); This is very likely the problem here; I guess 'tmp' should get integer_type instead of record_type, too, and the code above misses to do so. When I wrote this fragment, it was more or less just a trial-and-error process as I (still) don't know the backend-stuff quite well; I will try to get the correct sequence which will hopefully fix this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38883
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
--- Comment #6 from irar at il dot ibm dot com 2009-01-25 09:12 --- (In reply to comment #5) So, 4) The vectorized version sucks because we have to use peeling for niters because we need to unroll the loop once and cannot apply SLP here. What do you mean by unroll the loop once? Q1: does SLP work with reductions at all? No. SLP currently originates from groups of strided stores. Q2: does SLP do pattern recognition? Pattern recoginition is done before SLP, and SLP handles stmts that were marked as a part of a pattern. There is no SLP specific pattern recoginition. First of all we would need to recognize a complex reduction as a single vectorized reduction. Second we need to vectorize the complex multiplication with SLP, feeding the reduction with one resulting complex vector. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021
[Bug target/38547] duplicate symbols with g++ on AIX
--- Comment #19 from tammer at tammer dot net 2009-01-25 09:18 --- Hello, I second that. Bye Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38547
[Bug other/38920] throwing ex. across dlls doesn't work.
--- Comment #4 from pluto at agmk dot net 2009-01-25 09:57 ---
adding try{throw 0;}catch(...){} to main() shows that dw2-exceptions
don't work at all, so it's not related to dll crossing.
new testcase attached.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
[Bug other/38920] throwing ex. across dlls doesn't work.
--- Comment #5 from pluto at agmk dot net 2009-01-25 09:57 --- Created an attachment (id=17180) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17180action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
[Bug other/38920] dw2 exceptions don't work.
--- Comment #6 from pluto at agmk dot net 2009-01-25 10:02 --- maybe this bug is related to PR38952. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
[Bug fortran/38936] F2003: ASSOCIATE construct
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-25 10:19:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
--- Comment #7 from rguenther at suse dot de 2009-01-25 11:04 --- Subject: Re: Fortran Complex reduction / multiplication not vectorized On Sun, 25 Jan 2009, irar at il dot ibm dot com wrote: --- Comment #6 from irar at il dot ibm dot com 2009-01-25 09:12 --- (In reply to comment #5) So, 4) The vectorized version sucks because we have to use peeling for niters because we need to unroll the loop once and cannot apply SLP here. What do you mean by unroll the loop once? The vectorization factor is two, so we need two copies of the loop body (which means unrolling it once and creating an epilogue loop because niter may be odd) Q1: does SLP work with reductions at all? No. SLP currently originates from groups of strided stores. Ah, I see. In this loop we have two reductions, so to apply SLP we would need to see that we can use a group of reductions for SLP? Q2: does SLP do pattern recognition? Pattern recoginition is done before SLP, and SLP handles stmts that were marked as a part of a pattern. There is no SLP specific pattern recoginition. Ok, but with a reduction it won't help me here. Can a loop be vectorized with just pattern recognition? Hm, if I remember correctly we detect scalar patterns and then vectorize them. We don't support detecting vector patterns from scalar code, correct? Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-25 11:15 --- The self-init is of course for the case where the -Wuninitialized warning is bogus (which happens). It simply has no effect on whatever undefinedness is in your code - it was added to be a cheaper way instead of adding the usual zero-initialization which people do when they get seemingly bogus uninitialized warnings. Yes, I see the situation is somewhat unfortunate here ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug middle-end/38857] [4.4 Regression] ICE in selective scheduler
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-25 11:31 --- I think it is fine to submit the patch as is, assuming you've bootstrapped/regtested it. Please mail it to gcc-patches for review. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38857
[Bug tree-optimization/38745] [4.4 Regression] ICE: statement makes a memory store, but has no VDEFS
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-01-25 11:40 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |rguenth at gcc dot gnu dot |org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||01/msg01172.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38745
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
--- Comment #8 from irar at il dot ibm dot com 2009-01-25 12:17 --- (In reply to comment #7) Q1: does SLP work with reductions at all? No. SLP currently originates from groups of strided stores. Ah, I see. In this loop we have two reductions, so to apply SLP we would need to see that we can use a group of reductions for SLP? Yes, I think this will work. Q2: does SLP do pattern recognition? Pattern recoginition is done before SLP, and SLP handles stmts that were marked as a part of a pattern. There is no SLP specific pattern recoginition. Ok, but with a reduction it won't help me here. Can a loop be vectorized with just pattern recognition? Hm, if I remember correctly we detect scalar patterns and then vectorize them. We don't support detecting vector patterns from scalar code, correct? Yes, if I understand you correctly, we detect scalar patterns, but adding vector pattern detection does not seem to be complicated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021
[Bug target/38931] Seg fault when getting instruction latency on a *movsi_1 with an MMX target register
--- Comment #7 from uros at gcc dot gnu dot org 2009-01-25 12:26 --- Subject: Bug 38931 Author: uros Date: Sun Jan 25 12:26:15 2009 New Revision: 143663 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143663 Log: Backport from mainline: 2009-01-22 Uros Bizjak ubiz...@gmail.com PR target/38931 * config/i386/i386.md (*movsi_1): Use type mmx for alternative 2. (*movdi_1_rex64): Use type mmx for alternative 5. 2009-01-21 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/38879 * alias.c (base_alias_check): Unaligned access via AND address can alias all surrounding object types except those with sizes equal or wider than the size of unaligned access. testsuite/ChangeLog: Backport from mainline: 2009-01-22 Uros Bizjak ubiz...@gmail.com PR target/38931 * gcc.target/i386/pr38931.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr38931.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/alias.c branches/gcc-4_3-branch/gcc/config/i386/i386.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38931
[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #7 from uros at gcc dot gnu dot org 2009-01-25 12:26 --- Subject: Bug 38879 Author: uros Date: Sun Jan 25 12:26:15 2009 New Revision: 143663 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143663 Log: Backport from mainline: 2009-01-22 Uros Bizjak ubiz...@gmail.com PR target/38931 * config/i386/i386.md (*movsi_1): Use type mmx for alternative 2. (*movdi_1_rex64): Use type mmx for alternative 5. 2009-01-21 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/38879 * alias.c (base_alias_check): Unaligned access via AND address can alias all surrounding object types except those with sizes equal or wider than the size of unaligned access. testsuite/ChangeLog: Backport from mainline: 2009-01-22 Uros Bizjak ubiz...@gmail.com PR target/38931 * gcc.target/i386/pr38931.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr38931.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/alias.c branches/gcc-4_3-branch/gcc/config/i386/i386.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
[Bug target/38931] Seg fault when getting instruction latency on a *movsi_1 with an MMX target register
--- Comment #8 from ubizjak at gmail dot com 2009-01-25 12:27 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38931
[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #8 from ubizjak at gmail dot com 2009-01-25 12:28 --- Backported to 4.3 branch. -- ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|4.4.0 |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
[Bug tree-optimization/38964] New: TBAA side-effects of C++ new still missing
The TBAA side-effects of C++ operator/expression new are still not properly (read: conservatively correct) handled. The current implementation idea of dealing with that in a flow-insensitive way is going to severely pessimize optimization. See http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01212.html and followups. -- Summary: TBAA side-effects of C++ new still missing Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code, alias Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38964
[Bug tree-optimization/38964] TBAA side-effects of C++ new still missing
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-25 13:21 --- As soon as we do not have to properly represent this in the virtual use-def chains (while still being semi-precise) we can deal with this properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38964
[Bug fortran/38965] New: Fortran has a type merging problem
to keep track of the issue mentioned here http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00937.html the frontend should do the right thing here, to make TBAA work just fine. -- Summary: Fortran has a type merging problem Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk OtherBugsDependingO 36854 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38965
[Bug other/38966] New: libiberty make_relative_prefix_1 mistakes directories for executables
When GCC tries to resolve paths to executables it generates an exec prefix based on argv[0]. It does that using the make_relative_prefix_1 function in libiberty (make-relative-prefix.c). If argv[0] doesn't contain a path (i.e. it only reads gcc), make_relative_prefix_1 searches the PATH to find the full path to the current executable. When checking candidates however, it only checks the executable bit to determine whether or not it found the current executable. This means that when there is a directory with the same name as the executable in the PATH, this mechanism will produce a wrong prefix. Attached is a patch that uses stat to determine whether the candidate file is a regular file at all, hence skipping directories. -- Summary: libiberty make_relative_prefix_1 mistakes directories for executables Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mmlr at mlotz dot ch GCC host triplet: i586-pc-haiku GCC target triplet: i586-pc-haiku http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38966
[Bug other/38966] libiberty make_relative_prefix_1 mistakes directories for executables
--- Comment #1 from mmlr at mlotz dot ch 2009-01-25 14:56 --- Created an attachment (id=17181) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17181action=view) Proposed fix for make_relative_prefix_1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38966
[Bug fortran/38965] Fortran has a type merging problem
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-01-25 15:25 --- Richard already opened a PR for this :) *** This bug has been marked as a duplicate of 38913 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38965
[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-01-25 15:25 --- *** Bug 38965 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38913
[Bug tree-optimization/38964] TBAA side-effects of C++ new still missing
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-25 15:56 --- One thing to note is that the adjustment we do during inlining means that we miss that same adjustment iff inlining is disabled and the simple (placement) new wrappers are marked const (and thus do not appear as memory barriers in the virtual SSA form). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-25 15:56:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38964
[Bug tree-optimization/38964] TBAA side-effects of C++ new still missing
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-25 16:02 --- Plan for attacking the problem: 1) Write a verifier that discovers illegal code motion. 1a) Each store and load is assigned a generation count. 1b) After code motion optimizations verify that out-of-order stores/loads were validly interchanged. If not, ICE. If so, re-compute the generation counters. 2) Fix the fallout. Tree loop store motion is known to randomly interchange stores. 3) Profit. ... n) Deal with RTL (properly export alias information to RTL). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38964
[Bug boehm-gc/38967] New: gcc 4.4.0 20090125 [trunk revision 143660] - Boehm Testsuite failure is not unreported
This Bug showed up in the last few days. The script contrib/test_summary and the Testsuite scripts do not email the 'gcc-testresults' list. My build logs indicate that this Bug did _not_ occur with gcc version 4.4.0 20090122 (experimental) [trunk revision 143562], but _if_ it had occurred previously, it would not have been reported. # gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --with-long-double-128 --enable-nls --with-included-gettext --disable-gather-detailed-mem-stats --with-stabs --enable-debug --enable-initfini-array --enable-largefile --enable-symvers --enable-version-specific-runtime-libs --without-system-zlib --enable-gtk-cairo --enable-gconf-peer --enable-xmlj --enable-gtk-peer --enable-qt-peer --enable-plugin --enable-tool-wrappers --enable-portable-native-sync --enable-hash-synchronization --enable-local-sockets --enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug --enable-libgcj-debug --enable-objc-gc --disable-concept-checks --enable-libstdcxx-debug --disable-stage1-checking --enable-checking=release --without-system-libunwind --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090125 (experimental) [trunk revision 143660] (GCC) # gmake -i -k check ... gmake[4]: Entering directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/boehm-gc' GC_push_all_stacks: sp not set! /bin/sh: line 9: 28147: Abort(coredump) FAIL: gctest === 1 of 1 tests failed === gmake[4]: [check-TESTS] Error 1 (ignored) gmake[4]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/boehm-gc' gmake[3]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/boehm-gc' gmake[2]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/boehm-gc' gmake[2]: Entering directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libada' gmake[2]: Nothing to be done for `check'. gmake[2]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libada' gmake[2]: Entering directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libgomp' If we had some means to find the non-reported test failures and include them in the email to the 'gcc-testresults' list we would be better off. Here are a couple of other failures not reported or tests not reported: === acats tests === Running chapter a ... comm: file 2 is not in sorted order gmake[3]: Entering directory `/usr/share/src/gcc_build/libiberty/testsuite' ./test-demangle ../../../gcc_trunk/libiberty/testsuite/demangle-expected ./test-demangle: 775 tests, 0 failures ./test-pexecute ./test-expandargv PASS: test-expandargv-0. PASS: test-expandargv-1. PASS: test-expandargv-2. PASS: test-expandargv-3. gmake[3]: Leaving directory `/usr/share/src/gcc_build/libiberty/testsuite' Thanks, Rob -- Summary: gcc 4.4.0 20090125 [trunk revision 143660] - Boehm Testsuite failure is not unreported Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: boehm-gc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38967
[Bug middle-end/38968] New: Complex matrix product is not vectorized
As shown by the following code, the complex matrix product is not vectorized, even with the patch in http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01174.html: program mymatmul implicit none integer, parameter :: kp = 4 integer, parameter :: n = 2000 real(kp), dimension(n,n) :: rr, ri complex(kp), dimension(n,n) :: a,b,c real :: t1, t2 integer :: i, j, k call random_number (rr) call random_number (ri) a = cmplx (rr, ri) call random_number (rr) call random_number (ri) b = cmplx (rr, ri) call cpu_time (t1) c = cmplx (0._kp, 0._kp) do j = 1, n do k = 1, n do i = 1, n c(i,j) = c(i,j) + a(i,k) * b(k,j) end do end do end do call cpu_time (t2) write (*,'(F8.4)') t2-t1 end program mymatmul [ibook-dhum] bug/timing% gfc -m64 -O3 -ffast-math -funroll-loops -fomit-frame-pointer -ftree-vectorizer-verbose=2 mymatmul_v_c4.f90 mymatmul_v_c4.f90:22: note: not vectorized: can't calculate alignment for data ref. mymatmul_v_c4.f90:15: note: not vectorized: complicated access pattern. mymatmul_v_c4.f90:15: note: not vectorized: can't calculate alignment for data ref. mymatmul_v_c4.f90:12: note: not vectorized: complicated access pattern. mymatmul_v_c4.f90:12: note: not vectorized: can't calculate alignment for data ref. mymatmul_v_c4.f90:1: note: vectorized 0 loops in function. The real corresponding code is vectorized. -- Summary: Complex matrix product is not vectorized Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38968
[Bug c/38969] New: -foptimize-sibling-calls generates wrong code
gcc 4.3 on alpha generates wrong code when -foptimize-sibling-calls is
used (which is enabled at -O2). It was not the case with gcc 4.2, and
this is still reproducible with gcc from trunk from 20090106. This is
the reason why most of the complex tests of the glibc testsuite are
failing with gcc 4.3.
Here is a reduced testcase:
$ cat main.c
#include math.h
#include complex.h
__complex__ float my_print_complex (__complex__ float x);
int main()
{
__complex__ float a;
__real__ a = 9;
__imag__ a = 42;
my_print_complex(a);
return 0;
}
$ cat print.c
#include complex.h
#include math.h
#include stdio.h
__complex__ float internal_print_complex (__complex__ float x)
{
printf(%f+%fi\n, __real__ x, __imag__ x);
if (__real__ x 0)
{
__real__ x = -__real__ x;
}
return x;
}
__complex__ float my_print_complex (__complex__ float x)
{
return internal_print_complex (x);
}
$ gcc-4.3 -Wall -c main.c -o main.o
$ gcc-4.3 -O1 -foptimize-sibling-calls -Wall -c print.c -o print.o
$ gcc-4.3 -o test main.o print.o
$ ./test
0.00+0.00i
When print.o is not compiled with -foptimize-sibling-calls, the result
is:
$./test
9.00+42.00i
$
--
Summary: -foptimize-sibling-calls generates wrong code
on alpha
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aurelien at aurel32 dot net
GCC build triplet: alphaev68-unknown-linux-gnu
GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38969
[Bug fortran/38946] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #2 from rob1weld at aol dot com 2009-01-25 16:59 --- (In reply to comment #1) (In reply to comment #0) === gfortran tests === FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer execution ... Error: Symbol 'max_fld_hed' at (1) has no IMPLICIT type This error (like the others) is expected: we test that the compiler gives the expected output. Look for lines starting with FAIL for real failures. But as they are run-time, it won't help probably. Quite many of the newly-failing tests are about I/O; I suspect the following to be the culprit. Could you try before/after this? r143462 | pault | 2009-01-17 12:32:02 +0100 (sam. 17 janv. 2009) | 17 lines 2009-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/34955 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): ... Note that some of the tests require specific features (such as denormalized long doubles) and are x-failed(which means: known to fail) on some targets or have some dg-require-effective-targets conditions on them. Thus, maybe the correct behaviour for these tests is to fail on solaris. They worked last week. I am in favor of them working again and enabling, rather than disabling, as many features as possible. That includes both in gcc and in the Testsuite. I don't use Fortran but will offer a little assistance if I can. Here is my most recent test. Above you ask Could you try before/after this do you mean compile and run the Testuite on bothboth r143461 and r143463? Results for 4.4.0 20090125 (experimental) [trunk revision 143660] (GCC) testsuite on i386-pc-solaris2.11 http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02585.html Thanks for fixing this, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug tree-optimization/38968] Complex matrix product is not vectorized
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-25 17:33 --- Confirmed. Note the patch mentioned does not try to address any issue present in the testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2009-01-25 17:33:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38968
[Bug fortran/38946] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #3 from rob1weld at aol dot com 2009-01-25 17:35 --- # ./e_d_fmt.exe Abort (core dumped) # ldd ./e_d_fmt.exe libgfortran.so.3 = /usr/share/src/gcc_build/i386-pc-solaris2.11/./libgfortran/.libs/libgfortran.so.3 libm.so.2 = /usr/lib/libm.so.2 libgcc_s.so.1 = /usr/share/src/gcc_build/gcc/libgcc_s.so.1 libc.so.1 = /usr/lib/libc.so.1 # export set LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/opt/csw/lib:/usr/local/Trolltech/Qt-4.4.3/lib # ldd ./e_d_fmt.exe libgfortran.so.3 = /usr/local/lib/libgfortran.so.3 libm.so.2 = /usr/lib/libm.so.2 libgcc_s.so.1 = /usr/local/lib/libgcc_s.so.1 libc.so.1 = /usr/lib/libc.so.1 If I use the Testsuite's LD_LIBRARY_PATH then some of the Tests will load the wrong Libraries. If I use _my_ own LD_LIBRARY_PATH (as it is during configuration) then the Test programs use the correct Libraries and the programs run OK. In http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01790.html we only had array_constructor_23.f now we seem to have a few more. This is not so much an error in Fortran than it is an error in the scripting and it's ability to add it's own LD_LIBRARY_PATH components. Reducing the Severity to NORMAL. Thanks, Rob -- rob1weld at aol dot com changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug c/38969] -foptimize-sibling-calls generates wrong code on alpha
--- Comment #1 from ubizjak at gmail dot com 2009-01-25 17:39 --- Can you attach a working asm dump? -- ubizjak at gmail dot com changed: What|Removed |Added Summary|-foptimize-sibling-calls|-foptimize-sibling-calls |generates wrong code|generates wrong code on |on alpha|alpha http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38969
[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-01-25 17:54 --- Do we have a testcase for a primary platform that is affected by this bug? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740
[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-01-25 17:56 --- We seem to have a lot of similar sse performance regression P2 bugs, can someone make sure that there are no duplicates here? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug c++/38908] [4.4 regression] Unexplained 'anonymous' is used uninitialized in this function warning in cc1plus -m64
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-25 18:02 --- struct S8 D.2460; struct S8 D.2470; bb 2: # VUSE D.2460_1(D) # D.2470_3 = VDEF D.2470_2(D) D.2470 = D.2460; and struct S8 is empty. This is a dup of PR38851 which has a smaller testcase. *** This bug has been marked as a duplicate of 38851 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908
[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-01-25 18:02 --- *** Bug 38908 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||simon_baldwin at yahoo dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851
[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2009-01-25 18:02 --- Do we have a testcase for a primary platform that is affected by this bug? FWIW I haven't seen this failure mode on the SPARC yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740
[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
[Bug middle-end/38937] [4.4 Regression] dereferencing pointer 'anonymous' does break strict-aliasing
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-25 18:05 --- Does the following patch fix this? http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01245.html If so please mark this bug as a dup of PR38503. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38937
[Bug fortran/38852] UBOUND fails for negative stride triplets
--- Comment #6 from pault at gcc dot gnu dot org 2009-01-25 18:21 --- (In reply to comment #5) (In reply to comment #4) (In reply to comment #3) In the latter case, it is non-empty if ubound lbound only. Comparing ubound and lbound according to the stride to check for zero-sized arrays doesn't make sense in this case (see dimension 2 of dla). Indeed - the fix can be done in gfc_conv_intrinsic_bound. I will regtest tonight and submit accordingly. Paul Wrong! - this patch causes several regressions. I'll have to see how the code in the pointer assignment should be changed. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38852
[Bug tree-optimization/35202] [4.2/4.3/4.4 Regression] exp-expf transformation incorrect with -fmath-errno
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-01-25 18:29 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-02-15 15:50:39 |2009-01-25 18:29:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35202
[Bug middle-end/38615] [4.2/4.3 Regression] invalid promotion to static from auto
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-25 18:35 --- Fixed for 4.4.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.1 4.4.0 4.3.0 4.1.1 |4.0.1 4.4.0 4.3.0 4.1.1 |4.2.0 |4.2.0 4.3.3 Known to work|3.3.3 |3.3.3 4.4.0 Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression] invalid |invalid promotion to static |promotion to static from |from auto |auto http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38615
[Bug testsuite/38970] New: [4.4 Regression] Revision 143662 caused many failures
On Linux/ia32, revision 143662 caused: FAIL: g++.dg/ext/bitfield2.C (test for excess errors) FAIL: g++.dg/ext/bitfield4.C (test for excess errors) FAIL: gcc.dg/bitfld-15.c (test for excess errors) FAIL: gcc.dg/bitfld-17.c (test for excess errors) -- Summary: [4.4 Regression] Revision 143662 caused many failures Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38970
[Bug inline-asm/23200] [4.2/4.3/4.4 Regression] rejects i(var + 1)
--- Comment #39 from rguenth at gcc dot gnu dot org 2009-01-25 18:39 --- Even with SSA at -O0 now and forcefully trying to enable TER with -ftree-ter the testcase still fails. So, re-confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-06-18 05:52:02 |2009-01-25 18:39:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug middle-end/36359] missed optimization in some cases with PRE VRP and other passes combined together
--- Comment #19 from gcc at spatium dot org 2009-01-25 19:25 --- This thing still exists in 2.6.28.2; what do you suggest should be changed in the kernel to let it compile again? -- gcc at spatium dot org changed: What|Removed |Added CC||gcc at spatium dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor
--- Comment #14 from mmitchel at gcc dot gnu dot org 2009-01-25 19:45 --- Richard -- I don't agree that it's necessarily the FE's job to omit all stores to such types. Our general theory is that FEs get to emit dumb code and the optimizers get to fix it up. Of course, I don't object to making the FE generate simpler code, if that's easy to do; just that if our design relies on that, I think that's a mistake. I can imagine ways this could come up in other languages as well. For example, copying a C structure with an anonymous bit-field, but no other content, or an Ada record that uses Ada's layout directives to control size. Therefore, I don't think that the key here is zero-size. Instead, it's the fact that structure cannot be initialized. That's useful both for warnings and for optimization; it can't be initialized, so there's no point about warning about uninitialized uses, and there's no reason to actually generate code for the copies. That leads to something I do think is something that the FEs could be asked to do: set a bit on the type to indicate that it is uninitializable or, if you like, logically empty. I also don't see this as a P1 defect. It's certainly annoying, but, fundamentally, it limits the utility of a warning which has been known to give false positives for a long time. Important to fix, yes -- but as important as generating wrong code? -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851
[Bug c/38969] -foptimize-sibling-calls generates wrong code on alpha
--- Comment #2 from ubizjak at gmail dot com 2009-01-25 19:55 --- gcc should initialize pseudos from x variable in my_print_complex: ;; Function my_print_complex (my_print_complex) ;; Generating RTL for gimple basic block 2 ;; D.2813 = internal_print_complex (x); [tail call] (insn 17 6 18 pr38969.c:20 (set (reg:SF 48 $f16) (reg:SF 75 [ D.2870 ])) -1 (nil)) (insn 18 17 19 pr38969.c:20 (set (reg:SF 49 $f17) (reg:SF 76 [ D.2870+4 ])) -1 (nil)) (call_insn 19 18 20 pr38969.c:20 (parallel [ (set (parallel [ (expr_list:REG_DEP_TRUE (reg:SF 32 $f0) (const_int 0 [0x0])) (expr_list:REG_DEP_TRUE (reg:SF 33 $f1) (const_int 4 [0x4])) ]) (call (mem:DI (symbol_ref:DI (internal_print_complex) [flags 0x3] function_decl 0x7f203091dc00 internal_print_complex) [0 S8 A64]) (const_int 0 [0x0]))) (use (reg:DI 29 $29)) (clobber (reg:DI 26 $26)) ]) -1 (expr_list:REG_EH_REGION (const_int 0 [0x0]) (nil)) (expr_list:REG_DEP_TRUE (use (reg:SF 49 $f17)) (expr_list:REG_DEP_TRUE (use (reg:SF 48 $f16)) (nil Missing part is: (insn 7 6 8 pr38969.c:20 (set (reg:SF 75 [ D.2870 ]) (reg/v:SF 73 [ x ])) -1 (nil)) (insn 8 7 9 pr38969.c:20 (set (reg:SF 76 [ D.2870+4 ]) (reg/v:SF 74 [ x+4 ])) -1 (nil)) Since this part is missing, some later pass initializes uninitialized registers with zeros. Looking into it. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-25 19:55:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38969
[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor
--- Comment #15 from rguenther at suse dot de 2009-01-25 19:59 --- Subject: Re: [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor On Sun, 25 Jan 2009, mmitchel at gcc dot gnu dot org wrote: --- Comment #14 from mmitchel at gcc dot gnu dot org 2009-01-25 19:45 --- Richard -- I don't agree that it's necessarily the FE's job to omit all stores to such types. Our general theory is that FEs get to emit dumb code and the optimizers get to fix it up. Of course, I don't object to making the FE generate simpler code, if that's easy to do; just that if our design relies on that, I think that's a mistake. Oh, I agree. See my attempt to fix it during gimplification. I can imagine ways this could come up in other languages as well. For example, copying a C structure with an anonymous bit-field, but no other content, or an Ada record that uses Ada's layout directives to control size. Therefore, I don't think that the key here is zero-size. Instead, it's the fact that structure cannot be initialized. That's useful both for warnings and for optimization; it can't be initialized, so there's no point about warning about uninitialized uses, and there's no reason to actually generate code for the copies. Ok, I think mapping cannot be initialized to zero-size is ok, as that is the only thing we can currently query (and we even specialize this for C++ to deal with the 1 byte vs. empty case). That leads to something I do think is something that the FEs could be asked to do: set a bit on the type to indicate that it is uninitializable or, if you like, logically empty. I also don't see this as a P1 defect. It's certainly annoying, but, fundamentally, it limits the utility of a warning which has been known to give false positives for a long time. Important to fix, yes -- but as important as generating wrong code? It's a P1 defect as we didn't warn for uninitialized structure uses in any previous relelase. While we can argue that it is safe to downgrade this to P2 I think we should at least try to fix this issue for 4.4.0. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851
[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor
--- Comment #16 from mark at codesourcery dot com 2009-01-25 20:03 --- Subject: Re: [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor rguenther at suse dot de wrote: Therefore, I don't think that the key here is zero-size. Instead, it's the fact that structure cannot be initialized. That's useful both for warnings and for optimization; it can't be initialized, so there's no point about warning about uninitialized uses, and there's no reason to actually generate code for the copies. Ok, I think mapping cannot be initialized to zero-size is ok, as that is the only thing we can currently query (and we even specialize this for C++ to deal with the 1 byte vs. empty case). Yes, I think it's OK to approximate logically empty by zero-size at present. It might be worth either changing the zero-size documentation/name to reflect that it means logically empty (if we think these are the same concept) or else defining a separate LOGICALLY_EMPTY_P predicate (implemented by checking for zero size) as a hedge against separating them (if we think they are usefully distinct concepts). It's a P1 defect as we didn't warn for uninitialized structure uses in any previous relelase. While we can argue that it is safe to downgrade this to P2 I think we should at least try to fix this issue for 4.4.0. I don't mind fixing it, of course, and it would certainly be better to do so. But, at the end of the day, if everything else is ready, I'd be opposed to holding up the release for this. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851
[Bug testsuite/38970] [4.4 Regression] Revision 143662 caused many failures
--- Comment #1 from hp at gcc dot gnu dot org 2009-01-25 20:25 --- . -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38970
[Bug testsuite/35114] 731 unexpected libgomp testsuite failures due setup of test environment
--- Comment #1 from gerald at pfeifer dot com 2009-01-25 20:40 --- Since I reported this, things have improved somewhat. Per http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02566.html we now have === libgomp Summary === # of expected passes 2277 # of unexpected failures 60 # of unsupported tests2 Not sure this means the original bug has been addressed and this is another one that has been hidden originally? -- gerald at pfeifer dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-25 20:40:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35114
[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor
--- Comment #17 from rguenther at suse dot de 2009-01-25 20:45 --- Subject: Re: [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor On Sun, 25 Jan 2009, mark at codesourcery dot com wrote: --- Comment #16 from mark at codesourcery dot com 2009-01-25 20:03 --- Subject: Re: [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor rguenther at suse dot de wrote: It's a P1 defect as we didn't warn for uninitialized structure uses in any previous relelase. While we can argue that it is safe to downgrade this to P2 I think we should at least try to fix this issue for 4.4.0. I don't mind fixing it, of course, and it would certainly be better to do so. But, at the end of the day, if everything else is ready, I'd be opposed to holding up the release for this. I agree. Sometimes having one more priority inbetween P2 and P1 would be nice ;) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851
[Bug fortran/38852] UBOUND fails for negative stride triplets
--- Comment #7 from pault at gcc dot gnu dot org 2009-01-25 21:08 --- Created an attachment (id=17182) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17182action=view) A provisional patch for the PR It take back what I said previously:-) The attached bootstraps and regtests OK. I need to put some thought into the possibility that some fringe cases might fail, where the lbound is unity. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38852
[Bug middle-end/36359] missed optimization in some cases with PRE VRP and other passes combined together
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-01-25 21:10 --- The testcase from #17 does not reproduce the issue for me with recent GCC 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #18 from dave dot korn dot cygwin at gmail dot com 2009-01-25 21:36 --- Created an attachment (id=17183) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17183action=view) Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE. Now testing this patch which should fix setjmp calculations of the frame base pointer without affecting the way ordinary stack local variable slots are computed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug middle-end/36359] missed optimization in some cases with PRE VRP and other passes combined together
--- Comment #21 from bunk at stusta dot de 2009-01-25 22:00 --- (In reply to comment #20) The testcase from #17 does not reproduce the issue for me with recent GCC 4.3. This bug is a regression in gcc 4.4, it was AFAIK never present in gcc 4.3. Haven't tried more recent gcc versions, but I'm still seeing it with the 20090107-1 gcc-snapshot package (that is the SVN trunk). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-01-25 22:02 --- I am testing another patch, improving simple-DSE instead. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-01-24 09:27:19 |2009-01-25 22:02:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851
[Bug middle-end/36359] missed optimization in some cases with PRE VRP and other passes combined together
--- Comment #22 from bunk at stusta dot de 2009-01-25 22:05 --- Check my comments #10 and #11 and the definition of ilog2() in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/log2.h;h=25b808631cd92c50d10cf6a31b2d9b9942b62ac9;hb=bce7f793daec3e65ec5c5705d2457b81fe7b5725 and you'll understand why I said 8 months ago gcc has a bug regarding __builtin_constant_p(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug middle-end/36359] missed optimization in some cases with PRE VRP and other passes combined together
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-01-25 22:17 --- It doesn't reproduce for me with 4.4 either. Maybe this is a dup of PR38789? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug target/38952] [4.4 Regression] EH does not work.
--- Comment #19 from dave dot korn dot cygwin at gmail dot com 2009-01-25 23:07 --- Created an attachment (id=17184) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17184action=view) Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE *correctly*. Dur. Corrected patch for return type thinko. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added Attachment #17183|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
[Bug middle-end/36359] missed optimization in some cases with PRE VRP and other passes combined together
--- Comment #24 from bunk at stusta dot de 2009-01-26 00:49 --- (In reply to comment #23) It doesn't reproduce for me with 4.4 either. Maybe this is a dup of PR38789? Seems so: I've confirmed that the 4.4-20090109 snapshot is broken, and the 4.4-20090123 snapshot is fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug driver/38911] RFE - Need verbose gcc to show cloog , ppl and pwl + more (and trivial fix)
--- Comment #1 from rob1weld at aol dot com 2009-01-26 02:40 --- This might become more important when you build gcc with cloog and without ppl . Note: A major upcoming improvement is the support of multiple backends, not only PolyLib. CLooG will support PPL and already supports in the development version the isl (Integer Set Library) backend that should become the default backend. Because isl does not rely on rationals, CLooG is able to generate significantly better codes, with low control overhead. CLooG Development Version (improvements, including new isl backend support). http://www.bastoul.net/cloog/download.php#DEV Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38911
[Bug bootstrap/38971] New: RFE - Cloog .git is version 0.14.0 but gcc requires 0.15.0 (and our other problems with the cloog trunk)
+++ This bug was initially created as a clone of Bug #38911 +++ I'm compiling gcc revision 143664 on F10. The cloog website recommends it's .git for best results: http://www.bastoul.net/cloog/download.php#DEV The '.git' version (newest) creates version.h with this content: #define CLOOG_HEAD 0.14.0-148-gdccf6cb Gcc's ./configure requires cloog 0.15 as a minimum. The Instructions for cloog DEV have this as one of the things you must do: ./configure --without-polylib --with-isl=bundled --with-gmp-prefix=/path/to/gmp/installation If you configure in that manner gcc's ./configure will see that you do not use PPL but do have Cloog and will allow gcc to configure and build, failing here: gcc -ffloat-store -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc_trunk/gcc -I../../gcc_trunk/gcc/. -I../../gcc_trunk/gcc/../include -I./../intl -I../../gcc_trunk/gcc/../libcpp/include -I../../gcc_trunk/gcc/../libdecnumber -I../../gcc_trunk/gcc/../libdecnumber/bid -I../libdecnumber -I/usr/local/include -DCLOOG_PPL_BACKEND ../../gcc_trunk/gcc/graphite.c -o graphite.o In file included from ../../gcc_trunk/gcc/graphite.c:60: ../../gcc_trunk/gcc/graphite.h:119: error: expected specifier-qualifier-list before CloogMatrix ../../gcc_trunk/gcc/graphite.h: In function gbb_nb_loops: ../../gcc_trunk/gcc/graphite.h:227: error: const struct graphite_bb has no member named domain ../../gcc_trunk/gcc/graphite.h:230: error: const struct graphite_bb has no member named domain ../../gcc_trunk/gcc/graphite.h:231: warning: control reaches end of non-void function ../../gcc_trunk/gcc/graphite.h: In function gbb_loop_at_index: ../../gcc_trunk/gcc/graphite.h:239: error: struct graphite_bb has no member named loops ../../gcc_trunk/gcc/graphite.h:239: error: struct graphite_bb has no member named loops ../../gcc_trunk/gcc/graphite.h: In function gbb_loop_index: ../../gcc_trunk/gcc/graphite.h:250: error: struct graphite_bb has no member named loops ../../gcc_trunk/gcc/graphite.h:250: error: struct graphite_bb has no member named loops ../../gcc_trunk/gcc/graphite.h: In function loop_domain_dim: ../../gcc_trunk/gcc/graphite.h:482: warning: implicit declaration of function cloog_domain_dim ../../gcc_trunk/gcc/graphite.h:482: warning: implicit declaration of function cloog_loop_domain ../../gcc_trunk/gcc/graphite.c: At top level: ../../gcc_trunk/gcc/graphite.c:67: error: expected declaration specifiers or ... before Value ../../gcc_trunk/gcc/graphite.c: In function gmp_cst_to_tree: ../../gcc_trunk/gcc/graphite.c:69: warning: implicit declaration of function value_get_si ../../gcc_trunk/gcc/graphite.c:69: error: v undeclared (first use in this function) ../../gcc_trunk/gcc/graphite.c:69: error: (Each undeclared identifier is reported only once ../../gcc_trunk/gcc/graphite.c:69: error: for each function it appears in.) ../../gcc_trunk/gcc/graphite.c: In function debug_loop_vec: ../../gcc_trunk/gcc/graphite.c:101: error: struct graphite_bb has no member named loops ../../gcc_trunk/gcc/graphite.c:101: error: struct graphite_bb has no member named loops ../../gcc_trunk/gcc/graphite.c: In function gcc_type_for_cloog_iv: ../../gcc_trunk/gcc/graphite.c:331: error: struct graphite_bb has no member named cloog_iv_types ../../gcc_trunk/gcc/graphite.c: In function loop_iv_stack_patch_for_consts: ../../gcc_trunk/gcc/graphite.c:350: warning: implicit declaration of function cloog_statement_usr ../../gcc_trunk/gcc/graphite.c:365: error: too many arguments to function gmp_cst_to_tree ... ../../gcc_trunk/gcc/graphite.c: In function graphite_transform_loops: ../../gcc_trunk/gcc/graphite.c:6071: warning: implicit declaration of function cloog_initialize ../../gcc_trunk/gcc/graphite.c:6133: warning: implicit declaration of function cloog_finalize make[3]: *** [graphite.o] Error 1 make[3]: Leaving directory `/mnt/drive2/gcc_build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/mnt/drive2/gcc_build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/mnt/drive2/gcc_build' make: *** [all] Error 2 Thanks, Rob -- Summary: RFE - Cloog .git is version 0.14.0 but gcc requires 0.15.0 (and our other problems with the cloog trunk) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-redhat-linux-gnu GCC host triplet: i386-redhat-linux-gnu GCC target triplet: i386-redhat-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38971
[Bug bootstrap/38971] RFE - Cloog .git is version 0.14.0 but gcc requires 0.15.0 (and our other problems with the cloog trunk)
--- Comment #1 from spop at gcc dot gnu dot org 2009-01-26 03:09 --- You are not supposed to use Cloog trunk, for GCC 4.4 you have to use this: ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.tar.gz and follow the install instructions either from GCC's docs or from the wiki page: http://gcc.gnu.org/wiki/Graphite_Build Sebastian -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38971
[Bug other/38920] dw2 exceptions don't work.
--- Comment #7 from dannysmith at users dot sourceforge dot net 2009-01-26 03:30 --- AFAICT DW2 unwind has never worked on x86_64-mingw32, which is why Kai made sjlj the default EH model for that target. http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00273.html -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
[Bug driver/38911] RFE - Need verbose gcc to show cloog , ppl and pwl + more (and trivial fix)
--- Comment #2 from spop at gcc dot gnu dot org 2009-01-26 03:32 --- Again, you are not supposed to use other versions of CLooG than the one documented: CLooG-PPL. Sebastian -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38911
[Bug fortran/38657] [4.3 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #17 from pault at gcc dot gnu dot org 2009-01-26 05:12 --- Subject: Bug 38657 Author: pault Date: Mon Jan 26 05:12:03 2009 New Revision: 143669 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143669 Log: 2009-01-26 Paul Thomas pa...@gcc.gnu.org PR fortran/38657 * module.c (write_common_0): Add argument 'this_module' and check that non-use associated common blocks are written first. (write_common): Call write_common_0 twice, once with true and then with false. 2009-01-26 Paul Thomas pa...@gcc.gnu.org PR fortran/38657 * gfortran.dg/module_commons_3.f90: Reapply. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/module_commons_3.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug fortran/38657] [4.3 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #18 from pault at gcc dot gnu dot org 2009-01-26 05:13 --- Fixed on trunk and 4.3 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug fortran/38859] [4.3 Regression] ubound and lbound treat structure component references as whole arrays
--- Comment #8 from pault at gcc dot gnu dot org 2009-01-26 05:43 --- Subject: Bug 38859 Author: pault Date: Mon Jan 26 05:43:44 2009 New Revision: 143670 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143670 Log: 2009-01-26 Mikael Morin mikael.mo...@tele2.fr PR fortran/38859 Backport from trunk * simplify.c (simplify_bound): Don't use array specification if variable or component has subsequent references. 2009-01-26 Mikael Morin mikael.mo...@tele2.fr PR fortran/38859 Backport from trunk * gfortran.dg/bound_5.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/bounds_5.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/simplify.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38859
[Bug fortran/38859] [4.3 Regression] ubound and lbound treat structure component references as whole arrays
--- Comment #9 from pault at gcc dot gnu dot org 2009-01-26 05:44 --- Closed on trunk and 4.3. Once again, thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38859
[Bug fortran/38907] [4.3 Regression ] ICE when contained function has same name as module function and used in expression
--- Comment #10 from pault at gcc dot gnu dot org 2009-01-26 06:15 --- Subject: Bug 38907 Author: pault Date: Mon Jan 26 06:15:41 2009 New Revision: 143671 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143671 Log: 2009-01-26 Paul Thomas pa...@gcc.gnu.org PR fortran/38907 Backport from trunk * resolve.c (check_host_association): Remove the matching to correct an incorrect host association and use manipulation of the expression instead. 2009-01-26 Paul Thomas pa...@gcc.gnu.org PR fortran/38907 Backport from trunk * gfortran.dg/host_assoc_function_7.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/host_assoc_function_7.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38907
[Bug fortran/38907] [4.3 Regression ] ICE when contained function has same name as module function and used in expression
--- Comment #11 from pault at gcc dot gnu dot org 2009-01-26 06:16 --- Fixed on trunk and 4.3 Thanks for the report and thanks to Mikael for the fix. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38907
