[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.
--- Comment #7 from gnu_andrew at member dot fsf dot org 2008-03-01 09:14 --- Created an attachment (id=15250) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15250&action=view) Patch to add CPStringBuilder -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
[Bug middle-end/19020] libcalls are removed (-ftrapv does not work)
--- Comment #7 from steven at gcc dot gnu dot org 2008-03-01 10:50 ---
With trunk as of today, the test case of comment #0 does trap if optimization
is disabled. At -O, the libcall is optimized away, but the call to iaddv() from
main() is also optimized away because iaddv is found to be pure. You must use
the result of iaddv() to avoid this:
#include
int __attribute__((noinline))
iaddv (int a, int b)
{
return a + b;
}
int main(void)
{
return iaddv (INT_MAX, 1);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
[Bug libfortran/35063] Clean up use of destroy_unit_mutex()
--- Comment #41 from jb at gcc dot gnu dot org 2008-03-01 10:52 --- Subject: Bug 35063 Author: jb Date: Sat Mar 1 10:46:31 2008 New Revision: 132800 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132800 Log: gcc: 2008-03-01 Janne Blomqvist <[EMAIL PROTECTED]> PR gcc/35063 * gthr.h: Add __gthread_mutex_destroy as a function that must be implemented. * gthr-vxworks.h (__gthread_mutex_destroy): Null implementation. * gthr-single.h (__gthread_mutex_destroy): Likewise. * gthr-rtems.h (__gthread_mutex_destroy): Likewise. * gthr-mipssde.h (__gthread_mutex_destroy): Likewise. * gthr-nks.h (__gthread_mutex_destroy): Likewise. * gthr-solaris.h (__gthread_mutex_destroy): Call mutex_destroy. * gthr-win32.h (__GTHREAD_MUTEX_DESTROY_FUNCTION): Remove. (__gthread_mutex_destroy_function): Rename to __gthread_mutex_destroy. * gthr-dce.h (__gthread_mutex_destroy): Call pthread_mutex_destroy. * gthr-tpf.h (__gthread_mutex_destroy): Likewise. * gthr-posix.h (__gthread_mutex_destroy): Likewise. * gthr-posix95.h (__gthread_mutex_destroy): Likewise. libgfortran: 2008-03-01 Janne Blomqvist <[EMAIL PROTECTED]> PR libfortran/35063 * io/unit.c (destroy_unit_mutex): Call __gthread_mutex_destroy instead of macro kludge. Modified: trunk/gcc/ChangeLog trunk/gcc/gthr-dce.h trunk/gcc/gthr-mipssde.h trunk/gcc/gthr-nks.h trunk/gcc/gthr-posix.h trunk/gcc/gthr-posix95.h trunk/gcc/gthr-rtems.h trunk/gcc/gthr-single.h trunk/gcc/gthr-solaris.h trunk/gcc/gthr-tpf.h trunk/gcc/gthr-vxworks.h trunk/gcc/gthr-win32.h trunk/gcc/gthr.h trunk/libgfortran/ChangeLog trunk/libgfortran/io/unit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
[Bug libstdc++/35417] New: testsuite assign/shared_ptr_neg.cc (including tr1) has started to fail
Running target unix FAIL: abi_check FAIL: 20_util/shared_ptr/assign/shared_ptr_neg.cc (test for excess errors) XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors) FAIL: tr1/2_general_utilities/shared_ptr/assign/shared_ptr_neg.cc (test for excess errors) === libstdc++ Summary === # of expected passes4965 # of unexpected failures3 # of unexpected successes 1 # of expected failures 60 # of unsupported tests 326 Compiler version: 4.4.020080301(experimental)(GCC) Platform: i686-pc-linux-gnu configure flags: -v --enable-languages=c,c++,fortran --enable-shared --with-system-zlib --without-included-gettext --enable-threads=posix --enable-nls --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release --with-arch=core2 -- Summary: testsuite assign/shared_ptr_neg.cc (including tr1) has started to fail Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jrp at dial dot pipex dot com GCC build triplet: 4.4.0 20080301 (experimental) (GCC) GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35417
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2008-03-01 12:08 --- (In reply to comment #7) > I tried the attached change. It results in the correct configure > results. However, the test still fails. By my reading, this patch will change nothing: it's OK for HAVE_BROKEN_ISFINITE not be defined if isfinite is not defined, because we then have: #if defined(HAVE_BROKEN_ISFINITE) || defined(__CYGWIN__) #undef isfinite #endif #if !defined(isfinite) // define isfinite #endif So, in your case, when isfinite and fpclassify are both functions (and not macros), we're going to simply define isfinite as: #define isfinite(x) ((x) - (x) == 0) David, when you have time, can you test the two following replacements: #define isnan(x)__builtin_expect ((x) != (x), 0) #define isfinite(x) __builtin_expect (!isnan((x) - (x)), 1) #define isinf(x) __builtin_expect (!isnan(x) & !isfinite(x), 0) and #define isnan(x)__builtin_isnan (x) #define isfinite(x) __builtin_isfinite (x) #define isinf(x)__builtin_isinf (x) (they should go in libgfortran/libgfortran.h and replace the following block of code: #if defined(HAVE_BROKEN_ISFINITE) || defined(__CYGWIN__) ... #define isnan(x) (fpclassify(x) == FP_NAN) #endif /* !defined(fpclassify) */ #endif /* !defined(isfinite) */ Thanks, FX -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug fortran/34770] Incorrect array indexing through pointer when array does not start at 1
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-03-01 12:20 --- Subject: Bug 34770 Author: fxcoudert Date: Sat Mar 1 12:19:04 2008 New Revision: 132801 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132801 Log: PR fortran/34770 * gfortran.dg/pointer_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pointer_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34770
[Bug fortran/34770] Incorrect array indexing through pointer when array does not start at 1
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-03-01 12:21 --- Confirm it was apparently fixed between 4.2 and 4.3.0. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Known to work|4.3.0 |4.3.0 4.4.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34770
[Bug libfortran/35063] Clean up use of destroy_unit_mutex()
--- Comment #42 from fxcoudert at gcc dot gnu dot org 2008-03-01 12:22 --- Now fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2008-03-01 13:42 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution > So, in your case, when isfinite and fpclassify are both functions (and not > macros), we're going to simply define isfinite as: > #define isfinite(x) ((x) - (x) == 0) This is not correct. isfinite and fpclassify are both macros on HP-UX 11. However, they are broken because they only support float and double, and not long double. The function implementations are _Isfinitef, _Isfinite, _Fpclassifyf and _Fpclassify. There's also _Fpclassifyfd where the float argument is cast to double in math.h. On HP-UX 10, there is no isfinite macro or function. There are functions finite and finitef. Likewise, there are fpclassify and fpclassifyf functions. As with HP-UX 11, there is no long double support. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug middle-end/19020] libcalls are removed (-ftrapv does not work)
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-03-01 13:52 --- On the expand side it is just wrong (and asking for trouble) to go the usual expand_binop way for expanding trapping arithmetic. At least we would need to pass down a flag. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2008-03-01 13:57 --- (In reply to comment #11) > This is not correct. isfinite and fpclassify are both macros on > HP-UX 11. However, they are broken because they only support float > and double, and not long double. I was focusing on hpux10, because it's what it's in the target field of the bugzilla. But, long double shouldn't be a problem because the testcase only uses float and double (and, while we used to cast everything to long double in libgfortran, we don't do it anymore because of the problems that raised). > On HP-UX 10, there is no isfinite macro or function. There are > functions finite and finitef. Likewise, there are fpclassify and > fpclassifyf functions. So, on hpux10 my point still stands, doesn't it? We don't need the _BROKEN macros set, because is the macros aren't defined, we're gonna use their own (whether there are functions or not). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug middle-end/19020] libcalls are removed (-ftrapv does not work)
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-01 14:29 ---
If you remove libcall notes around all binops then the following testcase
passes in dg-torture:
/* { dg-do run { target hppa*-*-hpux* *-*-linux* powerpc*-*-darwin*
*-*-darwin[912]* } } */
/* { dg-options "-ftrapv" } */
#include
#include
#include
int ok;
void handle_abort (int sig)
{
if (sig == SIGABRT)
{
ok = 1;
exit (0);
}
}
int __attribute__((noinline))
iaddv (int a, int b)
{
return a + b;
}
volatile int x;
int main(void)
{
struct sigaction sa;
sigemptyset (&sa.sa_mask);
sa.sa_handler = handle_abort;
sa.sa_flags = SA_RESETHAND;
if (sigaction (SIGABRT, &sa, NULL) == -1)
return 0;
/* ??? iaddv is analyzed to be pure, so use the result. */
x = iaddv (INT_MAX, 1);
sa.sa_handler = SIG_DFL;
if (sigaction (SIGABRT, &sa, NULL) == -1)
return 0;
if (!ok)
abort ();
return 0;
}
but I get a build failure of libjava then:
gnu/java/nio/natVMSelector.cc: In static member function 'static jint
gnu::java::nio::VMSelector::select(JArray<__java_int>*, JArray<__java_int>*,
JArray<__java_int>*, jlong)':
gnu/java/nio/natVMSelector.cc:127: error: unable to find a register to spill in
class 'AD_REGS'
gnu/java/nio/natVMSelector.cc:127: error: this is the insn:
(insn 58 57 59 6 gnu/java/nio/natVMSelector.cc:82 (parallel [
(set (reg:DI 4 si [165])
(mult:DI (zero_extend:DI (reg:SI 0 ax))
(zero_extend:DI (reg:SI 2 cx [166]
(clobber (reg:CC 17 flags))
]) 304 {*umulsidi3_insn} (expr_list:REG_DEAD (reg:SI 2 cx [166])
(expr_list:REG_DEAD (reg:SI 0 ax)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (mult:DI (zero_extend:DI (reg:SI 0 ax))
(const_int 1000 [0x3e8]))
(nil))
gnu/java/nio/natVMSelector.cc:127: internal compiler error: in spill_failure,
at reload1.c:2000
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
with the following patch
Index: optabs.c
===
--- optabs.c(revision 132790)
+++ optabs.c(working copy)
@@ -2148,12 +2148,9 @@ expand_binop (enum machine_mode mode, op
insns = get_insns ();
end_sequence ();
+ emit_insn (insns);
- target = gen_reg_rtx (mode);
- emit_libcall_block (insns, target, value,
- gen_rtx_fmt_ee (binoptab->code, mode, op0, op1));
-
- return target;
+ return value;
}
delete_insns_since (last);
I'll test forcing value to a register.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
[Bug middle-end/19020] libcalls are removed (-ftrapv does not work)
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-03-01 15:24 --- Doesn't help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
[Bug c++/35415] [4.4 Regression] 20_util/shared_ptr/assign/shared_ptr_neg.cc
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-01 15:28 --- *** Bug 35417 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jrp at dial dot pipex dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35415
[Bug libstdc++/35417] testsuite assign/shared_ptr_neg.cc (including tr1) has started to fail
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-01 15:28 --- *** This bug has been marked as a duplicate of 35415 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35417
[Bug fortran/35355] Result of call cpu_time(x) can decrease or give non credible values with repeated calls
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-03-01 16:06 --- Are you using your own build of gfortran on mingw or one obtained from elsewhere and where? Are the time intervals so short that you could be seeing roundoff? Could the time intervals be wrapping around? The last modification to cpu_time was in 12-25-2007. Do you have an idea when this last worked for you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35355
[Bug fortran/35339] Improve translation of implied do loop in transfer
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-03-01 16:22 --- OK, I see your point. Would it be possible to create a hidden iterator function that could be called internally by the I/O library to return the index into the array? In the meantime, I am thinking through a different approach for aio that avoids the issue here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35339
[Bug c++/35315] [4.4 regression] ICE with attribute transparent_union
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-03-01 16:29 --- Fixed on mainline and 4.3 branch. -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315
[Bug other/28322] GCC new warnings and compatibility
--- Comment #15 from manu at gcc dot gnu dot org 2008-03-01 16:36 --- (In reply to comment #13) > Thanks a lot for taking the time to write a patch for this. I do have one > question: if I'm reading the patch correctly, this postpones warnings about > unrecognised options not just for -Wno-* but also for -fno-* and -mno-*. Was > that deliberate? Updated patches for older branches have been posted here: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00057.html They have testcases and have been regression tested. Nonetheless, they won't be reviewed nor applied to GCC branches. (Only the fix for trunk will be reviewed and applied to GCC 4.4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
[Bug libfortran/35355] Result of call cpu_time(x) can decrease or give non credible values with repeated calls
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-03-01 16:49 --- I've built new binaries today and I can also see it :( $ cat a.f90 implicit none integer, parameter :: pr = selected_real_kind (6,37) real(kind=pr) :: t integer ,parameter :: n = 1000 real :: x(n,n), y(n,n), z(n,n) call cpu_time(t) print *, t call flush() z = matmul(x,y) call cpu_time(t) print *, t call flush() z = matmul(x,y) call cpu_time(t) print *, t call flush() z = matmul(x,y) call cpu_time(t) print *, t call flush() end $ gfortran.exe a.f90 && a 0.46875000 8.5625000 8.5937500 17.00 I've spotted the issue: the Windows FILETIME structure stores time as a "number of 100-nanosecond intervals". So, to get to our usual microseconds, we need to divide by 10 (we're not loosing any precision, because Windows doesn't have 100ns resolution anyway). But, Daniel's 2007-12-25 patch reworked the code and remove the division by 10. Thus, we're now storing tens of microseconds in the usec variables, which leads to wrong results in the end. A possible patch is: Index: time_1.h === --- time_1.h(revision 132800) +++ time_1.h(working copy) @@ -104,10 +104,10 @@ &kernel_time.ft, &user_time.ft); *user_sec = user_time.ulltime / 1000; - *user_usec = user_time.ulltime % 1000; + *user_usec = (user_time.ulltime % 1000) / 10; *system_sec = kernel_time.ulltime / 1000; - *system_usec = kernel_time.ulltime % 1000; + *system_usec = (kernel_time.ulltime % 1000) / 10; return 0; } -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org, fxcoudert at gcc dot ||gnu dot org Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed|0 |1 GCC target triplet||i586-pc-mingw32 Keywords||patch, wrong-code Last reconfirmed|-00-00 00:00:00 |2008-03-01 16:49:05 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35355
[Bug libfortran/35355] [4.3/4.4 regression] CPU_TIME gives wrong values on mingw
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-03-01 16:52 --- This change is built and tested on i586-pc-mingw32. If approved, we should try to get it into 4.3.0 if it's still possible. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 4.4.0 Known to work||4.2.0 Summary|Result of call cpu_time(x) |[4.3/4.4 regression] |can decrease or give non|CPU_TIME gives wrong values |credible values with|on mingw |repeated calls | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35355
[Bug libfortran/35063] Clean up use of destroy_unit_mutex()
--- Comment #43 from jvdelisle at gcc dot gnu dot org 2008-03-01 17:13 --- Subject: Bug 35063 Author: jvdelisle Date: Sat Mar 1 17:12:52 2008 New Revision: 132802 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132802 Log: 2008-03-01 Janne Blomqvist <[EMAIL PROTECTED]> PR gcc/35063 * gthr-posix.h (__gthread_mutex_destroy): Remove extra declarations. * gthr-posix95.h (__gthread_mutex_destroy): Likewise. Note this fixes regression from previous patch. Modified: trunk/gcc/ChangeLog trunk/gcc/gthr-posix.h trunk/gcc/gthr-posix95.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
[Bug c++/35401] [4.3/4.4 Regression] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2008-03-01 17:26 --- Created an attachment (id=15251) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15251&action=view) complete diff between build with and without r131198 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35401
[Bug c++/35401] [4.3/4.4 Regression] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2008-03-01 17:28 --- I have attached a diff file between the build logs for gcc 4.3 branch with and without r131198. Hopefully this will provide some clues as to why darwin is linking in the wrong (system) libgcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35401
[Bug libfortran/35355] [4.3/4.4 regression] CPU_TIME gives wrong values on mingw
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-03-01 18:02 --- Patch is approved for trunk. I agree it should go to 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35355
[Bug c++/35401] [4.3/4.4 Regression] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2008-03-01 19:43 --- Created an attachment (id=15252) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15252&action=view) compressed full build log with r131198 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35401
[Bug c++/35401] [4.3/4.4 Regression] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2008-03-01 19:58 --- One other observation. If I make a file list of the darwin_objdir for the build with and with r131198, they are identical. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35401
[Bug c++/35401] [4.3/4.4 Regression] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2008-03-01 20:43 --- As far as I can tell, the shared libraries are being linked in the same way with and without r131198. I am inclined to think that the problem stems from the fact that xgcc with r131198 ends up being linked to the system libgcc. Without the r131198 change, only the stage1-gcc is linked to the system libgcc. With r131198, both the xgcc in the gcc and prev-gcc subdirectories are linked to the system libgcc as well as that in stage1-gcc. This all brings up the question of why xgcc on darwin isn't linked to the static copy of libgcc like on x86_64-unknown-linux-gnu? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35401
[Bug target/34497] failures on i686-apple-darwin9 in sse4 testcases
--- Comment #6 from ismail at namtrac dot org 2008-03-01 21:18 --- Jack, Did Apple give any reply on this. Is this their bug? If so we better close the gcc bug as invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34497
[Bug target/34497] failures on i686-apple-darwin9 in sse4 testcases
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-03-01 21:36 --- No official response yet although Mike Stump agrees that it is probably a bug in their assembler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34497
[Bug target/34497] failures on i686-apple-darwin9 in sse4 testcases
--- Comment #8 from ismail at namtrac dot org 2008-03-01 21:41 --- I think its reasonable to close this bug as invalid, do you agree? Meanwhile we can bug Apple Gcc guys to take a stab at this. Thanks, ismail -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34497
[Bug libfortran/35355] [4.3/4.4 regression] CPU_TIME gives wrong values on mingw
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-03-01 22:11 --- Subject: Bug 35355 Author: jvdelisle Date: Sat Mar 1 22:10:30 2008 New Revision: 132807 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132807 Log: 2008-03-01 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR libfortran/35355 * intrinsics/time_1.h (__time_1): Fix calculation of user_usec for mingw. Modified: branches/gcc-4_3-branch/libgfortran/ChangeLog branches/gcc-4_3-branch/libgfortran/intrinsics/time_1.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35355
[Bug fortran/35418] New: [4.4 Regression]: Revision 132592 miscompiles 172.mgrid
On Linux/Intel64, gcc 4.4 revision 132592 miscompiles 172.mgrid in SPEC CPU 2K with -O2 -ffast-math. This part of change: Index: gcc/fortran/trans-array.c === --- gcc/fortran/trans-array.c (revision 132591) +++ gcc/fortran/trans-array.c (revision 132592) @@ -3937,10 +3949,10 @@ gfc_trans_array_bounds (tree type, gfc_s /* Make sure that negative size arrays are translated to being zero size. */ - tmp = build2 (GE_EXPR, boolean_type_node, - stride, gfc_index_zero_node); - tmp = build3 (COND_EXPR, gfc_array_index_type, tmp, - stride, gfc_index_zero_node); + tmp = fold_build2 (GE_EXPR, boolean_type_node, +stride, gfc_index_zero_node); + tmp = fold_build3 (COND_EXPR, gfc_array_index_type, tmp, +stride, gfc_index_zero_node); gfc_add_modify_expr (pblock, stride, tmp); } miscompiles RESID, which has nested loops on 3-d arrays. Does it ring a bell? -- Summary: [4.4 Regression]: Revision 132592 miscompiles 172.mgrid Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran 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=35418
[Bug libfortran/35355] [4.3/4.4 regression] CPU_TIME gives wrong values on mingw
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-03-01 22:16 --- Subject: Bug 35355 Author: jvdelisle Date: Sat Mar 1 22:15:31 2008 New Revision: 132808 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132808 Log: 2008-03-01 Francois-Xavier Coudert <[EMAIL PROTECTED]> PR libfortran/35355 * intrinsics/time_1.h (__time_1): Fix calculation of user_usec for mingw. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/time_1.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35355
[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-01 22:50 --- The code looks like SUBROUTINE RESID(U,V,R,N,A) INTEGER N REAL*8 U(N,N,N),V(N,N,N),R(N,N,N),A(0:3) INTEGER I3, I2, I1 DO 600 I3=2,N-1 DO 600 I2=2,N-1 DO 600 I1=2,N-1 N is a 4 byte integer and gcc uses 8byte integer for array bound. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35418
[Bug c++/35401] [4.3/4.4 Regression] libstdc++ linked to system /usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2008-03-01 22:51 --- The multilib builds in general seem to have some broken elements. For both linux and darwin, when linking libgfortran one gets something like... libtool: link: /sw/src/fink.build/gcc43-4.3.0-20080228/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc43-4.3.0-20080228/darwin_objdir/./gcc/ -B/sw/lib/gcc4.3/i686-apple-darwin9/bin/ -B/sw/lib/gcc4.3/i686-apple-darwin9/lib/ -isystem /sw/lib/gcc4.3/i686-apple-darwin9/include -isystem /sw/lib/gcc4.3/i686-apple-darwin9/sys-include -dynamiclib -Wl,-single_module -Wl,-undefined -Wl,dynamic_lookup where /sw/lib/gcc4.3/i686-apple-darwin9/lib/ and /sw/lib/gcc4.3/i686-apple-darwin9/include are directories that don't exist under darwin or linux (where is is something like)... libtool: link: rm -fr .libs/libgfortran.a .libs/libgfortran.la .libs/libgfortran.lai .libs/libgfortran.so.3 .libs/libgfortran.so.3.0.0 libtool: link: /home/howarth/src/linux_obj/./gcc/xgcc -B/home/howarth/src/linux_obj/./gcc/ -B/home/howarth/work/gcc43/i686-pc-linux-gnu/bin/ -B/home/howarth/work/gcc43/i686-pc-linux-gnu/lib/ -isystem /home/howarth/work/gcc43/i686-pc-linux-gnu/include -isystem /home/howarth/work/gcc43/i686-pc-linux-gnu/sys-include -shared where /home/howarth/work/gcc43/i686-pc-linux-gnu/include and /home/howarth/work/gcc43/i686-pc-linux-gnu/lib/ don't exist. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35401
[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid
--- Comment #2 from kargl at gcc dot gnu dot org 2008-03-01 22:59 --- Define "miscompiles"? Remove -ffast-math? Add -fbounds-check? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35418
[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid
--- Comment #3 from tobi at gcc dot gnu dot org 2008-03-01 23:15 --- I checked the code leading up to this, and if I didn't miss a codepath, stride will always be of type gfc_array_index_type, so I'm inclined to believe that the bug, if any, is in fold. It is of course possible that folding allowed for a valid optimization that broke 172.mgrid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35418
[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid
--- Comment #4 from hjl dot tools at gmail dot com 2008-03-02 01:11 --- I got Running 172.mgrid ref base o2 default *** Miscompare of mgrid.out, see /export/gnu/import/rrs/spec/2000/spec/benchspec /CFP2000/172.mgrid/run/0002/mgrid.out.mis Invalid run; unable to continue. If you wish to ignore errors please use '-I' o r ignore_errors Remove -ffast-math fixes the problem. -fbounds-check doesn't make a difference. I'd like to know why --- old/c.f.003t.original 2008-03-01 14:15:12.0 -0800 +++ new/c.f.003t.original 2008-03-01 14:14:53.0 -0800 @@ -36,39 +36,39 @@ resid (u, v, r, n, a) ubound.0 = (integer(kind=8)) *n; stride.2 = NON_LVALUE_EXPR ; - stride.2 = stride.2 >= 0 ? stride.2 : 0; + stride.2 = MAX_EXPR ; ubound.1 = (integer(kind=8)) *n; stride.4 = stride.2 * NON_LVALUE_EXPR ; - stride.4 = stride.4 >= 0 ? stride.4 : 0; + stride.4 = MAX_EXPR ; ubound.3 = (integer(kind=8)) *n; size.6 = stride.4 * NON_LVALUE_EXPR ; - size.6 = size.6 >= 0 ? size.6 : 0; + size.6 = MAX_EXPR ; D.965 = size.6 - 1; D.966 = (bit_size_type) size.6 * 64; D.967 = () size.6 * 8; offset.5 = ~NON_LVALUE_EXPR - NON_LVALUE_EXPR ; ubound.14 = (integer(kind=8)) *n; stride.16 = NON_LVALUE_EXPR ; - stride.16 = stride.16 >= 0 ? stride.16 : 0; + stride.16 = MAX_EXPR ; ubound.15 = (integer(kind=8)) *n; stride.18 = stride.16 * NON_LVALUE_EXPR ; - stride.18 = stride.18 >= 0 ? stride.18 : 0; + stride.18 = MAX_EXPR ; ubound.17 = (integer(kind=8)) *n; size.20 = stride.18 * NON_LVALUE_EXPR ; - size.20 = size.20 >= 0 ? size.20 : 0; + size.20 = MAX_EXPR ; D.962 = size.20 - 1; D.963 = (bit_size_type) size.20 * 64; D.964 = () size.20 * 8; offset.19 = ~NON_LVALUE_EXPR - NON_LVALUE_EXPR ; ubound.7 = (integer(kind=8)) *n; stride.9 = NON_LVALUE_EXPR ; - stride.9 = stride.9 >= 0 ? stride.9 : 0; + stride.9 = MAX_EXPR ; ubound.8 = (integer(kind=8)) *n; stride.11 = stride.9 * NON_LVALUE_EXPR ; - stride.11 = stride.11 >= 0 ? stride.11 : 0; + stride.11 = MAX_EXPR ; ubound.10 = (integer(kind=8)) *n; size.13 = stride.11 * NON_LVALUE_EXPR ; - size.13 = size.13 >= 0 ? size.13 : 0; + size.13 = MAX_EXPR ; D.959 = size.13 - 1; D.960 = (bit_size_type) size.13 * 64; D.961 = () size.13 * 8; makes such a big differece. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35418
[Bug fortran/35418] [4.4 Regression]: Revision 132592 miscompiles 172.mgrid
--- Comment #5 from kargl at gcc dot gnu dot org 2008-03-02 01:33 --- (In reply to comment #4) > I got > > Running 172.mgrid ref base o2 default > *** Miscompare of mgrid.out, see > /export/gnu/import/rrs/spec/2000/spec/benchspec > /CFP2000/172.mgrid/run/0002/mgrid.out.mis > Invalid run; unable to continue. If you wish to ignore errors please use '-I' > o > r ignore_errors > > Remove -ffast-math fixes the problem. -fbounds-check doesn't make > a difference. I'd like to know why > > --- old/c.f.003t.original 2008-03-01 14:15:12.0 -0800 > +++ new/c.f.003t.original 2008-03-01 14:14:53.0 -0800 > @@ -36,39 +36,39 @@ resid (u, v, r, n, a) > >ubound.0 = (integer(kind=8)) *n; >stride.2 = NON_LVALUE_EXPR ; > - stride.2 = stride.2 >= 0 ? stride.2 : 0; > + stride.2 = MAX_EXPR ; This looks like a middle-end problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35418
[Bug libfortran/35355] [4.3/4.4 regression] CPU_TIME gives wrong values on mingw
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-03-02 02:20 --- Fixed on 4.3 and 4.4 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35355
