[Bug fortran/28809] [gfortran] internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1265
--- Comment #1 from kargl at gcc dot gnu dot org 2006-08-22 20:53 --- Upgrade your compiler to at least 4.1.1, and try again. Also, you need an explicit interface for the recursive function in your main program interface recursive real function det(a) result(res) real, dimension(:,:), intent(in) :: a end function det end interface -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28809
[Bug fortran/28818] C/Fortran interoperability: variable number of arguments passed from fortran to C causes Illegal instruction
--- Comment #5 from kargl at gcc dot gnu dot org 2006-08-25 16:38 --- I don't understand what you mean. The fortran code calls the test function, which is written in C (called test_ due to name mangling). test_ is indeed a variable-args function: void test_(int *test, ...). Fortran has no concept of a varargs function. It does not build an appropriate interface for the function. Also, this code works as expected on 32-bit x86 machines. NO, it *appears* to work, and this is most likely due to sizeof(int) == sizeof(void *). This is not true on x86_64, so your stack alignment is FUBAR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28818
[Bug fortran/28866] New: [Regression] Simple if statements are not so simple
The following program fails to compile because the commit
noted in the comment broke the processing of a chain of
matchers.
! { dg-do compile }
! Test fix for regression caused by
! 2006-06-23 Steven G. Kargl [EMAIL PROTECTED]
!PR fortran/27981
!* match.c (gfc_match_if): Handle errors in assignment in simple if.
!
module read
integer i, j, k
contains
subroutine a
if (i .eq. 0) read(j,*) k
end subroutine a
end module read
I'm currently testing a patch to fix the problem. Note, this effects only 4.2.
--
Summary: [Regression] Simple if statements are not so simple
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: kargl at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28866
[Bug fortran/28866] [Regression] Simple if statements are not so simple
--- Comment #1 from kargl at gcc dot gnu dot org 2006-08-27 22:44 --- Since I have a patch, I might as well confirm the bug. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-27 22:44:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28866
[Bug fortran/28874] gfortran confuses 'cycle' keyword for subroutine call in subroutine called 'cycle'
--- Comment #1 from kargl at gcc dot gnu dot org 2006-08-28 17:55 --- This is my screw. *** This bug has been marked as a duplicate of 28866 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28874
[Bug fortran/28866] [Regression] Simple if statements are not so simple
--- Comment #2 from kargl at gcc dot gnu dot org 2006-08-28 17:55 --- *** Bug 28874 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||drewmccormack at mac dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28866
[Bug fortran/28866] [Regression] Simple if statements are not so simple
--- Comment #3 from kargl at gcc dot gnu dot org 2006-08-29 19:47 --- Subject: Bug 28866 Author: kargl Date: Tue Aug 29 19:47:31 2006 New Revision: 116570 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116570 Log: 2006-08-29 Steven G. Kargl [EMAIL PROTECTED] PR fortran/28866 * match.c: Wrap copyright. (gfc_match_assignment): Return MATCH_NO for failed lvalue. Remove gotos. Move error handling of FL_PARAMETER to ... * gfc_match_if: Deal with MATCH_NO from above. * primary.c: Wrap copyright. (match_variable): ... here. Improve error messages. 2006-08-29 Steven G. Kargl [EMAIL PROTECTED] PR fortran/28866 * gfortran.dg/simpleif_2.f90: New test. * gfortran.dg/pr19936_1.f90: Adjust dg-error message. * gfortran.dg/enum_5.f90: Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/enum_5.f90 trunk/gcc/testsuite/gfortran.dg/pr19936_1.f90 trunk/gcc/testsuite/gfortran.dg/simpleif_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28866
[Bug fortran/28866] [Regression] Simple if statements are not so simple
--- Comment #4 from kargl at gcc dot gnu dot org 2006-08-29 19:49 --- Patch committed. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28866
[Bug fortran/25252] ICE on invalid code
--- Comment #3 from kargl at gcc dot gnu dot org 2006-08-29 21:39 --- We no longer get an ICE with GNU F95 version 4.2.0 20060828 (experimental) (x86_64-unknown-freebsd7.0) gfortran -o z ji.f90 In file ji.f90:6 MODULE PROCEDURE sreal, schar, sint = sreal 1 Error: Syntax error in MODULE PROCEDURE statement at (1) In file ji.f90:9 SUBROUTINE sreal(a,b) 1 Error: Procedure 'b' in generic interface 'swap' at (1) is neither function nor subroutine In file ji.f90:19 USE gswap 1 Fatal Error: Can't open module file 'gswap.mod' for reading at (1): No such file or directory Can we close this PR? -- 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=25252
[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers
--- Comment #1 from kargl at gcc dot gnu dot org 2006-08-31 02:06 --- Upgrade gfortran to at least 4.1.1. The code works fine with gfortran 4.2. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28914
[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers
--- Comment #2 from kargl at gcc dot gnu dot org 2006-08-31 02:47 --- Well, you do need to upgrade your compiler, but there appears to be a bug :( If n = 65000, the program works fine. For larger n, the combination of do i = 1, 1 a = (/ (i, i = 1, n) /) end do i as the do-loop index and i as the implied-do-loop index is causing problems. Normally, one cannot alter the do-loop index within the body of the loop. ISTR from the F95 standard, that the i in the implied-do-loop has the scope of only the implied-do-loop. Thus, the above code is legal. Why there is a change in behavior at i = 65000 (or so), I have no idea. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2006-08-31 02:47:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28914
[Bug fortran/28971] ICE: Segmentation fault on valid code
--- Comment #3 from kargl at gcc dot gnu dot org 2006-09-07 16:58 --- Paul, the code fails with troutmask:kargl[205] gfc --version GNU Fortran 95 (GCC) 4.2.0 20060711 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. but works with troutmask:sgk[248] gfc4x --version GNU Fortran 95 (GCC) 4.2.0 20060906 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. On a quick scan of ChangeLog, I did not see an entry that jumps out that fixed/caused the problem. Oskar, Can you update to a newer version and verify the code works? -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28971
[Bug fortran/29053] Consecutive STREAM I/O file positions mixed up
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-13 02:45 --- It fails at all optimization levels on FreeBSD. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29053
[Bug fortran/29060] spread causes ICE in gfc_trans_array_constructor
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-13 20:11 --- Yes, it appears to be related to spread. If you comment out the spread() in the subroutine the compiles. Additionally, if you change x%position(:,1:2) to x%position(1:3,1:2), then the code compiles. So, it looks like gfortran isn't interpreting the index ranges from spread correctly if the lefthand side doesn't have explicit ranges of indicies. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 20:11:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29060
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-13 20:17 --- This compiles with gfortran 4.2, so you may want to update to a newer compiler. Does this file contain any TAB characters? -- 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=29067
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #3 from kargl at gcc dot gnu dot org 2006-09-13 21:42 --- This compiles with both troutmask:sgk[265] gfc41 --version GNU Fortran 95 (GCC) 4.1.2 20060913 (prerelease) Copyright (C) 2006 Free Software Foundation, Inc. troutmask:sgk[266] gfc4x --version GNU Fortran 95 (GCC) 4.2.0 20060911 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. Can you upgrade and confirm that the code compiles? -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
-- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|WAITING |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-13 21:44:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
[Bug fortran/29240] optional argument for signal intrinsic not supported
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-26 22:29 --- gfortran supports an intrinsic function and an intrinsic subroutine as defined by g77. See the g77 documentation. These routines are provided solely for backwards compatibility with g77, and I doubt anyone will update code (unless you do it). -- 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=29240
[Bug fortran/27021] Problem with nearest(tiny(o),-1.0)/2.0
--- Comment #3 from kargl at gcc dot gnu dot org 2006-09-27 20:15 --- Subject: Bug 27021 Author: kargl Date: Wed Sep 27 20:15:22 2006 New Revision: 117257 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117257 Log: * configure.in: Check for GMP 4.1 or newer. Check for MPFR 2.2.0 or newer. * configure: Regenerated. * doc/install.texi: Document required versions of GMP and MPFR. * fortran/arith.c: Conditionally include arctangent2(). (gfc_check_real_range): Use mpfr_subnormalize in preference to local hack. * fortran/trans-intrinsic.c (gfc_get_intrinsic_lib_fndecl): Append l for long double functions. * fortran/simplify.c: Wrap Copyright to new line. (gfc_simplify_atan2): Use mpfr_atan2 in preference to arctangent2(). (gfc_simplify_log): Ditto. PR fortran/28276 * fortran/simplify.c (gfc_simplify_exponent): Use mpfr_get_exp in preference to broken local hack. PR fortran/27021 * fortran/simplify.c (gfc_simplify_nearest): Use mpfr_nexttoward and mpfr_subnormalize to handle numbers near zero in preference to broken local hack. PR fortran/28276 * testsuite/gfortran.dg/exponent_1.f90: New test. PR fortran/27021 * testsuite/gfortran.dg/nearest_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/exponent_1.f90 trunk/gcc/testsuite/gfortran.dg/nearest_1.f90 Modified: trunk/ChangeLog trunk/configure trunk/configure.in trunk/gcc/ChangeLog trunk/gcc/doc/install.texi trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27021
[Bug fortran/28276] EXPONENT() broken for real constants
--- Comment #9 from kargl at gcc dot gnu dot org 2006-09-27 20:15 --- Subject: Bug 28276 Author: kargl Date: Wed Sep 27 20:15:22 2006 New Revision: 117257 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117257 Log: * configure.in: Check for GMP 4.1 or newer. Check for MPFR 2.2.0 or newer. * configure: Regenerated. * doc/install.texi: Document required versions of GMP and MPFR. * fortran/arith.c: Conditionally include arctangent2(). (gfc_check_real_range): Use mpfr_subnormalize in preference to local hack. * fortran/trans-intrinsic.c (gfc_get_intrinsic_lib_fndecl): Append l for long double functions. * fortran/simplify.c: Wrap Copyright to new line. (gfc_simplify_atan2): Use mpfr_atan2 in preference to arctangent2(). (gfc_simplify_log): Ditto. PR fortran/28276 * fortran/simplify.c (gfc_simplify_exponent): Use mpfr_get_exp in preference to broken local hack. PR fortran/27021 * fortran/simplify.c (gfc_simplify_nearest): Use mpfr_nexttoward and mpfr_subnormalize to handle numbers near zero in preference to broken local hack. PR fortran/28276 * testsuite/gfortran.dg/exponent_1.f90: New test. PR fortran/27021 * testsuite/gfortran.dg/nearest_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/exponent_1.f90 trunk/gcc/testsuite/gfortran.dg/nearest_1.f90 Modified: trunk/ChangeLog trunk/configure trunk/configure.in trunk/gcc/ChangeLog trunk/gcc/doc/install.texi trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28276
[Bug fortran/27021] Problem with nearest(tiny(o),-1.0)/2.0
--- Comment #4 from kargl at gcc dot gnu dot org 2006-09-27 20:37 --- Fixed on trunk. Won't be fixed on 4.1. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27021
[Bug fortran/28276] EXPONENT() broken for real constants
--- Comment #10 from kargl at gcc dot gnu dot org 2006-09-27 20:38 --- Fixed on trunk. Won't be fixed on 4.1. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28276
[Bug fortran/29259] crash when reading from standard input after writing/reading unformatted file
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-28 04:06 --- Please see section 9.3.1, 9.3.3, and 9.3.4 of the Fortran 95 Standard. You're first open statement closes the preconnected standard input unit, so your second and third read *, n is fucked up. Hint use inquire to find an unused unit number or simply don't use a unit number of 5 or 6. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29259
[Bug fortran/29275] fortran added to language build list even when known buggy version of mpfr found
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-28 18:40 --- gfortran will work with the buggy mpfr. You simply will not get the bug fixes for 27021 and 28276. You have not installed gmp-4.1.4 as distributed by the GMP developers. The mpfr.h header file in the version of mpfr included in gmp-4.1.4 does included /* Define MPFR version number */ #define MPFR_VERSION_MAJOR 2 #define MPFR_VERSION_MINOR 1 #define MPFR_VERSION_PATCHLEVEL 1 In fact it does not include any of these. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29275
[Bug fortran/29275] fortran added to language build list even when known buggy version of mpfr found
--- Comment #2 from kargl at gcc dot gnu dot org 2006-09-28 18:48 --- Crap. Re-open. mpfr_subnormalized() first appeared in 2.2.0. I'll fix this in a few minutes. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29275
[Bug fortran/29275] fortran added to language build list even when known buggy version of mpfr found
--- Comment #3 from kargl at gcc dot gnu dot org 2006-09-28 19:36 --- This should be fixed by the patch I just committed. Note, you'll see two gfortran testsuite programs fail because your version of mpfr is too old. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29275
[Bug fortran/29147] Bad overflow check in DATA statements
--- Comment #2 from kargl at gcc dot gnu dot org 2006-09-29 00:25 --- (In reply to comment #1) Created an attachment (id=12299) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12299action=view) [edit] Legacy code example Compiles fine with every other compiler out there. That's because every other compiler out there is broken :-) The standard is quite clear that the BOZ is converted to an integer with the kind type with the largest decimal range. In your case that integer is kind=8, and Z'' = 4294967295 which over flows the range of an integer(kind=4) constant. -- 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=29147
[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #8 from kargl at gcc dot gnu dot org 2006-09-29 00:30 --- Paul, Jakub, Is the patch in comment #7 considered to be the right approach? I tried applying to my local tree, but a few chunks were rejected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug fortran/29147] Bad overflow check in DATA statements
-- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-29 03:26:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29147
[Bug fortran/29147] Bad overflow check in DATA statements
--- Comment #3 from kargl at gcc dot gnu dot org 2006-09-29 04:30 --- I failed to not that your assertion that the error message is misleading is incorrect. The error message is actually quite concise and accurate. See section 5.2.10 of the F95 standard. I submitted a patch that will allow you to do gfortran -fno-range-check nonportable_code.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29147
[Bug fortran/29147] Bad overflow check in DATA statements
--- Comment #4 from kargl at gcc dot gnu dot org 2006-09-29 04:55 --- Fixed on trunk. Although the patch would work on 4.1, it isn't needed because I never fixed range checking on 4.1. Use -fno-range-check option. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29147
[Bug libfortran/29121] CPU_TIME subroutine missing for REAL(kind=10) argument
--- Comment #3 from kargl at gcc dot gnu dot org 2006-09-29 20:34 --- I have a patch that adds real(10) and real(16) versions of cpu_time. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-09-20 04:47:23 |2006-09-29 20:34:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29121
[Bug fortran/24828] Z and negative integers
--- Comment #4 from kargl at gcc dot gnu dot org 2006-09-29 20:52 --- Can this PR be closed? How BOZ constants are interpreted is in accordance with the F95 standard's DATA statement. The extension of BOZs in assignments does change the intrepretation. With a slightly modified program, I see troutmask:sgk[455] cat k.f90 program z integer(4) i integer(8) j i = Z'80203040' j = Z'80203040' print *, i, j if (i .ne. Z'80203040') call abort end troutmask:sgk[456] gfc -o z k.f90 In file k.f90:4 i = Z'80203040' 1 Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1) troutmask:sgk[457] gfc -o z -fno-range-check k.f90 troutmask:sgk[458] ./z -2145374144 2149593152 Abort (core dumped) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24828
[Bug libfortran/29121] CPU_TIME subroutine missing for REAL(kind=10) argument
--- Comment #4 from kargl at gcc dot gnu dot org 2006-09-29 22:23 --- Fixed on trunk. I'll commit to 4.1 after a regression test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29121
[Bug libfortran/29121] CPU_TIME subroutine missing for REAL(kind=10) argument
--- Comment #5 from kargl at gcc dot gnu dot org 2006-09-29 23:39 --- Fixed on 4.1 branch. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29121
[Bug target/29292] configure produces strange gmp, mpfr lib directories.
--- Comment #1 from kargl at gcc dot gnu dot org 2006-09-30 01:56 --- This looks like a target problem. The 4.1 branch built fine on amd64-*-freebsd with --with-gmp=/usr/local. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29292
[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4
--- Comment #6 from kargl at gcc dot gnu dot org 2006-10-01 00:40 --- (In reply to comment #5) Jerry, I've run this with guardmalloc... Jack, This is an Apple library problem. Please report the inappropriate use of strtol_l to Apple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
[Bug fortran/29312] Errors in subnormal calculation
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-01 23:52 --- I believe the bugs with the various intrinsics are all related. The problem stems from some confusion over the meaning of emin and emax in gfortran, the IEEE 754 standard, and mpfr. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-01 23:52:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29312
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #8 from kargl at gcc dot gnu dot org 2006-10-02 16:47 --- Remove reject-valid keyword, again! Return this to enhancement. This is NOT a bug. g77 compatibility and the Fortran 95 standard have a conflict, and so IMNSHO the Fortran 95 standard wins. See comment #3. The Fortran 95 standard has quite explicit language concerning how a BOZ is handled in a DATA statement, and that is what gfortran implements. A BOZ is handled consistently so that the gfortran extension of allowing a BOZ in an assignment gives the same result as the DATA statement. troutmask:kargl[204] cat a.f90 PROGRAM GFCBUG19 DOUBLE PRECISION y, x DATA x / Z'7FF0' / ! Conforms to Fortran 95 standard y = Z'7FF0' ! gfortran extension print *, x, y END troutmask:kargl[205] gfc -o z a.f90 troutmask:kargl[206] ./z 9.218868437227405E+018 9.218868437227405E+018 If someone wants to create a patch to implement a -fbroken-boz-behavior option, then that's fine. OTOH, the user can use the bit manipulation functions and TRANSFER to create whatever bit pattern the user wants. Or, the user can use the -fno-range-check option and simply compute inf = 1./0. and nan = 0. / .0. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Severity|normal |enhancement Keywords|rejects-valid | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug target/17174] Fortran nearest broken on AIX
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-03 19:14 --- (In reply to comment #1) I think ia64-hp-hpux11.23 is having a problem here too. I get a failure with the test gfortran.dg/large_real_kind_form_io_2.f90, which uses the nearest intrinsic. I use mpfr 2.2 to build. I think the bug may be with mpfr 2.2 only. gfc_simplify_nearest is ifdef'ed to do something different when using mpfr 2.2 than with older mpfr's. The ifdef appeared long after David's initial bug report, which suggests the problem is with AIX's libm's nextafter routine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17174
[Bug fortran/29343] (Regression) Error on valid specification variables in same call to ALLOCATE
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-04 14:17 --- *** Bug 29344 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||martin at mpa-garching dot ||mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29343
[Bug fortran/29344] [gfortran,4.2.0 regression] valid ALLOCATE-statement rejected
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-04 14:17 --- *** This bug has been marked as a duplicate of 29343 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29344
[Bug fortran/15441] RRSPACING broken for denormals
--- Comment #8 from kargl at gcc dot gnu dot org 2006-10-04 17:20 --- gfortran still gets rrspacing of subnormal wrong. troutmask:sgk[215] ./z s = 4.4081038E-39 -- Subnormal named constant x = 4.4081038E-39 -- Subnormal variable rrspacing(s)= 1.2582912E+07 -- Constant folding my_rrspacing(x) = 1.2582912E+07 -- Fortran code rrspacing(x)=NaN -- gfortran inline program h real, parameter :: s = 0.375 * tiny(1.) real x x = s print *, 's =', s, ' -- Subnormal named constant' print *, 'x =', x, ' -- Subnormal variable' print *, 'rrspacing(s)=', rrspacing(s), ' -- Constant folding' print *, 'my_rrspacing(x) =', my_rrspacing(x), ' -- Fortran code' print *, 'rrspacing(x)=', rrspacing(x), ' -- gfortran inline' contains function my_rrspacing(x) implicit none real my_rrspacing real, intent(in) :: x real y y = abs(x) if (y == 0.) then my_rrspacing = 0. else my_rrspacing = scale(scale(y, - exponent(y)), digits(y)) end if end function my_rrspacing end program h The F95 standard says that rrspacing(x) = | x * b**(-e) | 2**p where b, e, and p are the radix, exponent of x, and prcision. trans-intrinsics.c (gfc_conv_intrinsic_rrspacing) appears to mutilate the mathematical expression. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15441
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-05 17:54 ---
(In reply to comment #0)
1. Whether a certain minimum version of GMP/MPFR is required to avoid known
bugs, etc.
See my recent patch to toplevel configure.in. THe minimum required
versions should be gmp-4.1.x and mpfr-2.2.0.
2. Whether we should include GMP/MPFR in the svn archive like we do for intl
and zlib.
I think that gmp and mpfr would need to be imported into GCC. If you read the
gmp webpage, it often contains warnings about using newer versions of GCC to
gmp because of bugs.
3. Whether GMP/MPFR works on all the platforms/configurations that GCC
supports. Are we ready to require a GMP/MPFR port for every port of GCC?
4. If we don't do #2 and there is no system GMP/MPFR or the system lib is too
old, or if we trip over #3 and can't have GMP/MPFR, then what? Do we require
the user to go get/port it, or silently eliminate this optimization during the
build process?
I could be mistaken, but I believe one can configure gmp for a generic library
that does not use any machine (ie., cpu) specific assembly.
If you haven't read fortran/{arith.c,simplify.c}, then I'd suggest
that you take a look to see what gmp/mpfr can do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug fortran/15441] RRSPACING broken for denormals
--- Comment #9 from kargl at gcc dot gnu dot org 2006-10-06 00:33 ---
I have a patch, but it requires libm to have ldexp{f,l}.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org
|dot org |
Status|REOPENED|ASSIGNED
Last reconfirmed|2004-05-14 17:32:55 |2006-10-06 00:33:10
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15441
[Bug fortran/25850] real kind=16 failures on powerpc-darwin
--- Comment #7 from kargl at gcc dot gnu dot org 2006-10-06 03:04 ---
(In reply to comment #6)
The last work on this by Andrew was to propose the code fragment
below for remapping the functions...
static void
darwin_patch_builtin (int fncode)
{
}
It is unclear to me where you intend to put this function.
If it is in the gfortran frontend, I will outright reject
the patch and lobby to have it removed if anyone applies.
Mike Stump provide a list of functions to be remapped...
(Over 150 functions to remap).
You got to be kidding. Apple has no long double library
support, and so you plan to remap the functions just to
compile REAL(16) programs. I fear that this is going to
lead to too many superfluous bug reports. If anything,
in trans-types.h, the inclusion of REAL(16) shoudl be
disabled for darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug fortran/24398] invalid module file gives weird error
--- Comment #9 from kargl at gcc dot gnu dot org 2006-10-06 03:08 --- Paul, I read the patch, and think that you can commit it. gfortran certainly can't recover for a mangled module. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24398
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-06 14:40 ---
(In reply to comment #3)
(In reply to comment #2)
(In reply to comment #0)
1. Whether a certain minimum version of GMP/MPFR is required to
avoid known bugs, etc.
See my recent patch to toplevel configure.in. THe minimum required
versions should be gmp-4.1.x and mpfr-2.2.0.
I see that, but when configure detects the broken mpfr, it just prints
out a message and proceeds happily. It doesn't disable anything. (???)
It's simply a warning to a user that there are known problems with the
version of MPFR on the system. gfortran will work correctly with the
buggy mpfr with the exception of some corner cases and PRs that I've
fixed using newer features. In particular, there are problems with
the old hackish way that gfortran handled subnormal numbers. gfortran
also uses functions that are in 2.2.0 that are not available in some
of the older versions.
See simplify.c(gfc_simplify_nearest).
If you haven't read fortran/{arith.c,simplify.c}, then I'd suggest
that you take a look to see what gmp/mpfr can do.
I looked through those and read through the mpfr docs so I think I have a good
idea of what mpfr can do. My main area of concern right now is converting
between gcc's REAL_VALUE_TYPE and mpfr_t. I found gfc_conv_mpfr_to_tree() in
trans-const.c which uses a string as an intermediate type, is that the most
efficient way to convert?
I didn't write that function, and so I have experimented with a replacement.
There is mpfr_get_ld(), which converts to a long double. If the data type
never exceeds the properties of long double, then one may be able to
use mpfr_get_ld() and then fold_convert() the result to the proper type.
Also where is the function that does the reverse,
i.e. tree or REAL_VALUE_TYPE to mpfr_t?
gfortran doesn't have a need of going in the opposite direction.
gmp/mpfr are used in the frontend for the internal representation
of data types. By the time gfortran reaches the functions in
trans-*.c, it has done all the constant folding and manipulation
of the data types that it can. The trans-*.c functions simply
convert gfortran's black and red trees into the tree-ssa form.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #6 from kargl at gcc dot gnu dot org 2006-10-06 17:03 --- There is mpfr_get_ld(), which converts to a long double. If the data type never exceeds the properties of long double, then one may be able to use mpfr_get_ld() and then fold_convert() the result to the proper type. I think using long double defeats the whole purpose of using mpfr. It appears you misread what I wrote (or meant to write). If the data type never exceeds the properties of long double applies to a cross compiler as well where data type is on the target and long double is on the host. We're supposed to avoid relying on the properties of the host's floating point for cross-compilers where the target format is different. The host's long double is simply an intermediate representation of the value. It is the responsibility of the fold_convert to get the right target representation. This is no different than using strings as the intermediate. I was hoping there was an easy was to extract the exponent and mantissa from one of (REAL_VALUE_TYPE/mpft_t) and put them back into the other in a way that preserves everything clean in both directions. See trans-intrinsics.c (prepare_arg_info), although I'm get ready to submit a patch that removes that function. Also where is the function that does the reverse, i.e. tree or REAL_VALUE_TYPE to mpfr_t? gfortran doesn't have a need of going in the opposite direction. gmp/mpfr are used in the frontend for the internal representation of data types. By the time gfortran reaches the functions in trans-*.c, it has done all the constant folding and manipulation of the data types that it can. The trans-*.c functions simply convert gfortran's black and red trees into the tree-ssa form. Okay I hacked up something in the other direction using strings again. If someone comes up with something better, then great. But it's not strictly necessary. I can put the two conversion functions into real.[ch]. I would be interested in seeing the functions because gfortran currently can't constant fold a TRANSFER() of the form real, parameter :: x = transfer(1234,x) This is a bitwise copy of the integer 1234 into x. In gfortran 1235 is a gmp mpz_t type and x is an mpfr mpfr_t type. Emulating the bitwise copy will require strings manipulations. -- 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=29335
[Bug fortran/29312] Errors in subnormal calculation
--- Comment #3 from kargl at gcc dot gnu dot org 2006-10-09 20:55 --- Subject: Bug 29312 Author: kargl Date: Mon Oct 9 20:55:29 2006 New Revision: 117584 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117584 Log: 2006-10-06 Steven G. Kargl [EMAIL PROTECTED] * gfortran.h: Define GFC_MPFR_TOO_OLD via mpfr version info. * arith.c (arctangent, gfc_check_real_range): Use it. * simplify.c (gfc_simplify_atan2, gfc_simplify_exponent, gfc_simplify_log, gfc_simplify_nearest): Use it. PR fortran/15441 PR fortran/29312 * iresolve.c (gfc_resolve_rrspacing): Give rrspacing library routine hidden precision argument. (gfc_resolve_spacing): Give spacing library routine hidden precision, emin - 1, and tiny(x) arguments. * simplify.c (gfc_simplify_nearest): Remove explicit subnormalization. (gfc_simplify_rrspacing): Implement formula from Fortran 95 standard. (gfc_simplify_spacing): Implement formula from Fortran 2003 standard. * trans-intrinsic.c (gfc_intrinsic_map_t) Declare rrspacing and spacing via LIBF_FUNCTION (prepare_arg_info, call_builtin_clz, gfc_conv_intrinsic_spacing, gfc_conv_intrinsic_rrspacing): Remove functions. (gfc_conv_intrinsic_function): Remove calls to gfc_conv_intrinsic_spacing and gfc_conv_intrinsic_rrspacing. * f95-lang.c (gfc_init_builtin_functions): Remove __builtin_clz, __builtin_clzl and __builtin_clzll 2006-10-06 Steven G. Kargl [EMAIL PROTECTED] PR fortran/15441 PR fortran/29312 * configure.ac: Add HAVE_LDEXPF, HAVE_LDEXP, and HAVE_LDEXPL * m4/spacing.m4: New file. Use new HAVE_* defines. * m4/rrspacing.m4: Ditto. * Makefile.am: Handle new files. * configure: Regenerated. * Makefile.in: Ditto. * config.h.in: Ditto. * generated/spacing_r4.c: Generated. * generated/spacing_r8.c: Ditto. * generated/spacing_r10.c: Ditto. * generated/spacing_r16.c: Ditto. * generated/rrspacing_r4.c: Ditto. * generated/rrspacing_r8.c: Ditto. * generated/rrspacing_r10.c: Ditto. * generated/rrspacing_r16.c: Ditto. Added: trunk/libgfortran/generated/rrspacing_r10.c trunk/libgfortran/generated/rrspacing_r16.c trunk/libgfortran/generated/rrspacing_r4.c trunk/libgfortran/generated/rrspacing_r8.c trunk/libgfortran/generated/spacing_r10.c trunk/libgfortran/generated/spacing_r16.c trunk/libgfortran/generated/spacing_r4.c trunk/libgfortran/generated/spacing_r8.c trunk/libgfortran/m4/rrspacing.m4 trunk/libgfortran/m4/spacing.m4 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-intrinsic.c trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29312
[Bug fortran/15441] RRSPACING broken for denormals
--- Comment #10 from kargl at gcc dot gnu dot org 2006-10-09 20:55 --- Subject: Bug 15441 Author: kargl Date: Mon Oct 9 20:55:29 2006 New Revision: 117584 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117584 Log: 2006-10-06 Steven G. Kargl [EMAIL PROTECTED] * gfortran.h: Define GFC_MPFR_TOO_OLD via mpfr version info. * arith.c (arctangent, gfc_check_real_range): Use it. * simplify.c (gfc_simplify_atan2, gfc_simplify_exponent, gfc_simplify_log, gfc_simplify_nearest): Use it. PR fortran/15441 PR fortran/29312 * iresolve.c (gfc_resolve_rrspacing): Give rrspacing library routine hidden precision argument. (gfc_resolve_spacing): Give spacing library routine hidden precision, emin - 1, and tiny(x) arguments. * simplify.c (gfc_simplify_nearest): Remove explicit subnormalization. (gfc_simplify_rrspacing): Implement formula from Fortran 95 standard. (gfc_simplify_spacing): Implement formula from Fortran 2003 standard. * trans-intrinsic.c (gfc_intrinsic_map_t) Declare rrspacing and spacing via LIBF_FUNCTION (prepare_arg_info, call_builtin_clz, gfc_conv_intrinsic_spacing, gfc_conv_intrinsic_rrspacing): Remove functions. (gfc_conv_intrinsic_function): Remove calls to gfc_conv_intrinsic_spacing and gfc_conv_intrinsic_rrspacing. * f95-lang.c (gfc_init_builtin_functions): Remove __builtin_clz, __builtin_clzl and __builtin_clzll 2006-10-06 Steven G. Kargl [EMAIL PROTECTED] PR fortran/15441 PR fortran/29312 * configure.ac: Add HAVE_LDEXPF, HAVE_LDEXP, and HAVE_LDEXPL * m4/spacing.m4: New file. Use new HAVE_* defines. * m4/rrspacing.m4: Ditto. * Makefile.am: Handle new files. * configure: Regenerated. * Makefile.in: Ditto. * config.h.in: Ditto. * generated/spacing_r4.c: Generated. * generated/spacing_r8.c: Ditto. * generated/spacing_r10.c: Ditto. * generated/spacing_r16.c: Ditto. * generated/rrspacing_r4.c: Ditto. * generated/rrspacing_r8.c: Ditto. * generated/rrspacing_r10.c: Ditto. * generated/rrspacing_r16.c: Ditto. Added: trunk/libgfortran/generated/rrspacing_r10.c trunk/libgfortran/generated/rrspacing_r16.c trunk/libgfortran/generated/rrspacing_r4.c trunk/libgfortran/generated/rrspacing_r8.c trunk/libgfortran/generated/spacing_r10.c trunk/libgfortran/generated/spacing_r16.c trunk/libgfortran/generated/spacing_r4.c trunk/libgfortran/generated/spacing_r8.c trunk/libgfortran/m4/rrspacing.m4 trunk/libgfortran/m4/spacing.m4 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-intrinsic.c trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15441
[Bug fortran/15441] RRSPACING broken for denormals
--- Comment #11 from kargl at gcc dot gnu dot org 2006-10-09 20:57 --- Fixed on trunk (until someone tells me ldexp doesn't exist). -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15441
[Bug fortran/29312] Errors in subnormal calculation
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-09 20:58 --- Fixed on trunk (until someone tells me ldexp doesn't exist) -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29312
[Bug libfortran/29423] FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-10 22:34 --- Update your source directory and rebuild in a clean obj directory. -- 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=29423
[Bug fortran/29446] New: VRP ICE in compare_names
troutmask:kargl[206] gfc -m32 -O3 -fbounds-check -c vrp.f90 vrp.f90: In function 'abc': vrp.f90:1: internal compiler error: in compare_names, at tree-vrp.c:3645 The Fortran code is function abc(n) integer :: xsd(n), abc(size(xsd),n), i, j, n do i=1,2 do j=1,3 if (i /= j) then abc(1,1) = 0 else abc(1,j) = xsd(1) end if end do end do end function abc -- Summary: VRP ICE in compare_names Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29446
[Bug libfortran/29423] FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90
--- Comment #10 from kargl at gcc dot gnu dot org 2006-10-13 20:14 --- Committed the patch. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29423
[Bug fortran/29403] print ('(a)') not working, print '(a) works
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-14 04:48 --- I may have a patch for this. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-14 04:48:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29403
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #10 from kargl at gcc dot gnu dot org 2006-10-15 01:20 --- (In reply to comment #9) I managed to trim it down to: implicit none integer :: n, i character(len=16),parameter :: s = if (s(9:16) == 90123456) then endif if (i 0) then write (i,*) n call foo(0) endif do i = 1, n end do end This trimmed down example is invalid code. The if (i0) statement tries to use before it is defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type
--- Comment #11 from kargl at gcc dot gnu dot org 2006-10-15 01:53 --- I can't reproduce this, so drop assign status. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kargl at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29067
[Bug fortran/29403] print ('(a)') not working, print '(a) works
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-16 00:51 --- Subject: Bug 29403 Author: kargl Date: Mon Oct 16 00:51:46 2006 New Revision: 117764 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117764 Log: 2006-10-15 Steven G. Kargl [EMAIL PROTECTED] PR fortran/29403 * io.c (match_io): Check for a default-char-expr for PRINT format. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29403
[Bug fortran/29403] print ('(a)') not working, print '(a) works
--- Comment #3 from kargl at gcc dot gnu dot org 2006-10-16 00:54 --- Subject: Bug 29403 Author: kargl Date: Mon Oct 16 00:54:01 2006 New Revision: 117765 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117765 Log: 2006-10-15 Steven G. Kargl [EMAIL PROTECTED] PR fortran/29403 * gfortran.dg/print_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/print_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29403
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-16 16:51 --- This is going to be difficult to fix. In fact, it will require a complete rewrite on how BOZ are handled. Fortran 2003: a = real(z'F') = 2.1019477E-44 Are you sure this is the only correct value? The F2003 says nothing about the other 28 bits. It also says nothing about whether z'F' applies to most significant bits or least significant bits of the 32-bit real. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29403] [4.1 only] print ('(a)') not working, print '(a) works
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-16 16:58 ---
Fixed on trunk. Testing for 4.1.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Summary|print ('(a)') not working, |[4.1 only] print ('(a)') not
|print '(a) works|working, print '(a) works
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29403
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-16 17:23 --- Forgot to add myself to cc listing. Tobias, the only place the handling on a BOZ (other the data-stmt handling) is discussed in the description REAL() intrinsic procedure. It contains the dreaded processor-dependent language. -- 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=29471
[Bug fortran/29403] [4.1 only] print ('(a)') not working, print '(a) works
--- Comment #5 from kargl at gcc dot gnu dot org 2006-10-16 18:37 --- Subject: Bug 29403 Author: kargl Date: Mon Oct 16 18:37:39 2006 New Revision: 117789 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117789 Log: 2006-10-15 Steven G. Kargl [EMAIL PROTECTED] PR fortran/29403 * io.c (match_io): Check for a default-char-expr for PRINT format. * gfortran.dg/print_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/print_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/io.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29403
[Bug fortran/29403] [4.1 only] print ('(a)') not working, print '(a) works
--- Comment #6 from kargl at gcc dot gnu dot org 2006-10-16 19:18 --- Fixed on 4.1, now. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29403
[Bug fortran/29507] New: INDEX in an array initialization causes ICE
This code:
module z
character(8), parameter :: a(1:3)=(/'nint() ', 'log10() ', 'sqrt() '/)
integer, parameter :: b(1:3) = index(a, '(')
end module z
causes
troutmask:sgk[415] gfc4x -o z z.f90
z.f90:0: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:3470
--
Summary: INDEX in an array initialization causes ICE
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29507
[Bug fortran/29505] Should give an error when using: real :: r; r(j) = ...
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-18 20:52 --- Tobias, The code is valid fortran in that del(j) = sin(10) is a statement function. Putting any executable line before that line (such as j = 1) causes an error to be emitted. If you look at the -fdump-parse-tree you'll see symtree: del Ambig 0 symbol del (REAL 4)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS STATEMENT-PROC FUNCTION) value: -5.44021130e-1 result: del Formal arglist: j I think the bug should be closed as INVALID. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29505
[Bug fortran/29537] ICE in gfc_match_common
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-21 22:04 --- First, I agree there is a bug because gfortran should not have an ICE. However, I believe the code is invalid. The Fortran 95 standard specifically mentions named common blocks in the description of block data. common c is a blank common block. -- 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=29537
[Bug fortran/29561] hexadecimal constant problem
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-23 17:10 --- Please the audit trail for Pr 18026. It gives the details. Also, the difference in the earlier version of gfortran to the newer version is due to this patch. 2006-09-07 Steven G. Kargl [EMAIL PROTECTED] * gfortran.h (gfc_integer_info): Eliminate max_int. * arith.c (gfc_arith_init_1): Remove initialization of max_int. (gfc_arith_done_1): Remove clearing of max_int. (gfc_check_integer_range): Fix range chekcing of overflow. * simplify.c (gfc_simplify_not): Construct mask that was max_int. *** This bug has been marked as a duplicate of 18026 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29561
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #11 from kargl at gcc dot gnu dot org 2006-10-23 17:10 --- *** Bug 29561 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kloedej at knmi dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-23 19:49 --- Thomas, Have you written Adrain about his plans concerning his patch? BTW, I think the Intel subrecord approach is probably the best solution to the large record problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug fortran/29580] integer -2147483648 out of range: bug or feature?
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-24 14:47 --- It is not a bug. i = - 2147483648 is a unary minus operation on the number 2147483648. This number overflows the range. If you want the most negative number for an integer use i = - huge(i) - 1. I've already pointed you the to the commit that fixed range checking. There is a very long email in the fortran@ mailing list that explains the problem and why it was fixed. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29580
[Bug fortran/29580] integer -2147483648 out of range: bug or feature?
--- Comment #3 from kargl at gcc dot gnu dot org 2006-10-24 15:25 --- (In reply to comment #2) In my simple view as a physicist the minus sign is an integral part of the number and not an operation on it, but then I didn't have a formal computer science education. As a gfortran programmer you have a choice here I would say. You'll find that I'm a physicist, too. I have no formal CS training other than reading books and the Fortran standard. It does not matter if you consider the minus a part of the number. It is a unary minus operation according to the Fortran Standard, and that is how gfortran implements its behavior. You are relying on nonportable processor dependent behavior. I've told you how to make your code portable. It is up to you to use the advice or ignore it. BTW, http://gcc.gnu.org/ml/fortran/2006-08/msg00371.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29580
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-27 19:33 --- DSYEV is expecting double precision arrays. You are giving it default real kind arrays. This is a bug in your code. If you want gfortran to detect this type of problem, use LAPACK95. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-27 21:47 --- What compiler option did you use to compile BLAS and LAPACK? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #6 from kargl at gcc dot gnu dot org 2006-10-27 22:07 --- I can't make this go into an infinite loop on FreeBSD. Can you rebuild blas and lapack with -O1 and see if the problem still occurs? I'm not sure if this is an optimization problem or a target problem (cygwin or mingW?) -- 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=29621
[Bug fortran/29621] lapack runs into infinite loop with -03
--- Comment #16 from kargl at gcc dot gnu dot org 2006-10-28 03:07 --- One final note. This behavior is described in the lapack FAQ. http://www.netlib.org/lapack/faq.html#1.25 -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29621
[Bug target/29660] get 'internal compiler error' when building numerical recipes
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-31 04:46 --- See Andrew's comment. Using gfortran 4.0.1 is guaranteed not to compile NR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29660
[Bug fortran/29677] minimally informative gfortran -fbounds-check
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-31 21:38 --- Upgrade to the a 4.2 pre-release version of gfortran or the mainline version. Please report back if you find a problem. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29677
[Bug libfortran/29810] ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl
--- Comment #2 from kargl at gcc dot gnu dot org 2006-11-12 16:22 --- Just curious. Do you file bug reports with HP about the lack of C99 long double libm functions? You need to add a fmodl function to c99_functions.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug libfortran/29810] ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl
--- Comment #3 from kargl at gcc dot gnu dot org 2006-11-12 16:36 ---
Here's an untested patch.
Index: configure.ac
===
--- configure.ac(revision 118613)
+++ configure.ac(working copy)
@@ -235,6 +249,7 @@ AC_CHECK_LIB([m],[cexpl],[AC_DEFINE([HAV
AC_CHECK_LIB([m],[fabsf],[AC_DEFINE([HAVE_FABSF],[1],[libm includes fabsf])])
AC_CHECK_LIB([m],[fabs],[AC_DEFINE([HAVE_FABS],[1],[libm includes fabs])])
AC_CHECK_LIB([m],[fabsl],[AC_DEFINE([HAVE_FABSL],[1],[libm includes fabsl])])
+AC_CHECK_LIB([m],[fmodl],[AC_DEFINE([HAVE_FMODL],[1],[libm includes fmodl])])
AC_CHECK_LIB([m],[cabsf],[AC_DEFINE([HAVE_CABSF],[1],[libm includes cabsf])])
AC_CHECK_LIB([m],[cabs],[AC_DEFINE([HAVE_CABS],[1],[libm includes cabs])])
AC_CHECK_LIB([m],[cabsl],[AC_DEFINE([HAVE_CABSL],[1],[libm includes cabsl])])
Index: intrinsics/c99_functions.c
===
--- intrinsics/c99_functions.c (revision 118613)
+++ intrinsics/c99_functions.c (working copy)
@@ -1159,3 +1159,17 @@ ctanl (long double complex a)
}
#endif
+#if !defined(HAVE_FMODL)
+#define HAVE_FMODL 1
+long double
+fmodl (long double x, long double y)
+{
+ if (y == 0)
+return 0;
+
+ /* Need to check that the result has the same sign as x and magnitude
+ less than the magnitude of y. */
+ return (x - floorl(x / y) * y;
+}
+#endif
+
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug fortran/29837] INTERFACE overloading INTENT problem - valid code is rejected
--- Comment #2 from kargl at gcc dot gnu dot org 2006-11-15 00:18 --- The trivial workaround is to assign MAXVAL(X) to an integer. SUBROUTINE T(X) INTEGER, INTENT(IN) :: X(:) INTEGER Y, Z z = maxval(x) CALL A(z,Y) END SUBROUTINE T I need to look at the standard with regards to conformance issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29837
[Bug libfortran/20085] iargc returns wrong count for number of program arguments
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-20 15:37 --- Patch applied. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20085
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 20085, which changed state. Bug 20085 Summary: iargc returns wrong count for number of program arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20085 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/20058] Error on kind 16 hex data statement
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-21 18:23 --- For a patch see http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01253.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20058
[Bug libfortran/20156] gfortran - bus error on backspace
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-26 06:28 --- Dale, I believe Bud Davis or Thomas Koening are the logical people to look at your patch. If either one doesn't pursue your patch within the next week drop me an email. One thing to keep in mind. The patch here is fairly minimal so it probably doesn't need copyright assignment paperwork on file with FSF. However, if you send additional patches (which I strongly encourage :-) and if you don't have paperwork on file with the FSF, please consider pursuing assignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20156
[Bug fortran/20224] gfortran - flags error on strange, but correct f77 program
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-26 19:44 --- This is illegal code with respect to F77. From ansi-x3dot9-1978-Fortran77.pdf 11.10.8 Transfer into the Range of a Do-Loop Transfer of control into the range of a DO-loop from outside the range is not permitted. I haven't looked in the F2003 standard, but I suspect it is also illegal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20224
[Bug fortran/20224] gfortran - flags error on strange, but correct f77 program
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-27 00:06 --- Here's a little more info from the F77 standard, Appendix A. A2. Conflicts with ANSI X3.9-1966 An extremely important consideration in the preparation of this standard was the minimization of conflicts with the previous standard, ANSI X3.9-1966. This standard includes changes that create conflicts with ANSI X3.9-1966 only when such changes were necessary to correct an error in the previous standard or to add to the power of the FORTRAN language in a significant manner. The following is a list of known conflicts: (7) This standard does not permit a transfer of control into the range of a DO-loop from outside the range. The range of a DO-loop may be entered only by the execution of a DO statement. ANSI X3.9-1966 permitted transfer of control into the range of a DO-loop under certain conditions. This involved the concept referred to as extended range of a DO. I think that this can be closed with a WONTFIX, since there is nothing to fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20224
[Bug fortran/20224] gfortran - flags error on strange, but correct f66 program
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-27 19:49 --- This is not an enhancement and should be given the WONTFIX status. Re-read the excerpt from the F77 standard that I quoted. If it is not an outright error, then consider the implications that this so-called enhancement will have on optimizing DO-loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20224
[Bug fortran/20058] Error on kind 16 hex data statement
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-28 00:42 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20058
[Bug fortran/20335] ICE with attached Fortran source
--- Additional Comments From kargl at gcc dot gnu dot org 2005-03-05 18:57 --- Here's a rduced version. This caused by UBOUND call on the allocated array. module types type lineListType type(vertexType), dimension(:), pointer :: vertex end type end module types module flow use types contains subroutine TraceCreate use types type(lineListType) :: line integer :: max_line allocate(line%vertex(0:15)) max_line = ubound(line%vertex, 1) end subroutine end module -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-05 18:57:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20335
[Bug fortran/19754] Shape conformance not checked
--- Additional Comments From kargl at gcc dot gnu dot org 2005-03-05 22:31 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19754
[Bug fortran/19936] confused error message about implied do loop
--- Additional Comments From kargl at gcc dot gnu dot org 2005-03-05 23:46 --- Fixed. A saner error message is generated for mangled implied-do loops. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19936
[Bug fortran/18537] no warning about tabs with std=f95 option
--- Additional Comments From kargl at gcc dot gnu dot org 2005-03-06 05:25 --- See patch at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00504.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18537
[Bug fortran/20460] Nasty extensions that should always warn
--- Additional Comments From kargl at gcc dot gnu dot org 2005-03-14 06:34 --- While I can agree that REAL DO loop indices should cause a warning, it is incorrect to call this feature an extension to the language. Fortran 77 permitted such indices. Fortran 90 declared them to be obsolescent, which means the feature was permitted. Fortran 95 finally deleted them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20460
[Bug fortran/18026] boz initialization of REALs fails
--- Additional Comments From kargl at gcc dot gnu dot org 2005-03-15 21:05 --- I've removed the reject-valid keyward because the code is not valid Fortran 95. From section 5.2.10, we have: If a data-statement-constant is a boz-literal-constant, the corresponding object shall be of type integer. A data-stmt-constant that is a boz-literal-constant is treated as if the constant were an int-literal- constant with a kind-param that specifies the representation method with the largest decimal exponent range supported by the processor. -- What|Removed |Added Keywords|rejects-valid | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug fortran/20520] allocatable arrays used without being allocated without a warning
--- Additional Comments From kargl at gcc dot gnu dot org 2005-03-17 19:46 --- www.lahey.com also compiles the code. It does issues 2 warnings about using an unitialized variable and a variable set bu never used. As Andrew said, you are in the area of undefined behavior, which means a compiler can do anything wants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
[Bug fortran/20541] INTEGER type declaration: ALLOCATABLE, compilation error
--- Additional Comments From kargl at gcc dot gnu dot org 2005-03-18 22:08 --- Your code is illegal with respect to the Fortran 95 standard. See section 4.4.1, page 38, of the (draft) standard, you'll find the following R426 component-attr-spec is POINTER or DIMENSION ( component-array-spec ) Note ALLOACTABLE is not listed above. If you have Metcalf Reid, Fortran 90/95 Explained, 2nd ed., you'll find on page 107: If a variable-sized array component of a structure is required, unfortunately, an array pointer must be used (see Section 6.14). The prohibition on allocatable arrays here was made to keep the the feature simple, but this is now recognized as a mistake that will be corrected in Fortran 2000 -- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug fortran/20538] compiling -finline-functions -O2 and we crash at runtime
--- Additional Comments From kargl at gcc dot gnu dot org 2005-03-18 22:24 --- It appears to be an optimization bug. It compiles and runs with -O and -O -finline-functions. It seg faults with -O2. The -finline-functions appears to be unrelated to the seg fault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20538
