[Bug fortran/28809] [gfortran] internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1265

2006-08-22 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/28818] C/Fortran interoperability: variable number of arguments passed from fortran to C causes Illegal instruction

2006-08-25 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/28866] New: [Regression] Simple if statements are not so simple

2006-08-27 Thread kargl at gcc dot gnu dot org
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

[Bug fortran/28866] [Regression] Simple if statements are not so simple

2006-08-27 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/28874] gfortran confuses 'cycle' keyword for subroutine call in subroutine called 'cycle'

2006-08-28 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/28866] [Regression] Simple if statements are not so simple

2006-08-28 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/28866] [Regression] Simple if statements are not so simple

2006-08-29 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/28866] [Regression] Simple if statements are not so simple

2006-08-29 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/25252] ICE on invalid code

2006-08-29 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers

2006-08-30 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/28914] Code inside loop hangs; outside loop runs normally; runs OK on other compilers

2006-08-30 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/28971] ICE: Segmentation fault on valid code

2006-09-07 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29053] Consecutive STREAM I/O file positions mixed up

2006-09-12 Thread kargl at gcc dot gnu dot org
--- 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

2006-09-13 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type

2006-09-13 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type

2006-09-13 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type

2006-09-13 Thread kargl at gcc dot gnu dot org
-- 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

[Bug fortran/29240] optional argument for signal intrinsic not supported

2006-09-26 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/27021] Problem with nearest(tiny(o),-1.0)/2.0

2006-09-27 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/28276] EXPONENT() broken for real constants

2006-09-27 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/27021] Problem with nearest(tiny(o),-1.0)/2.0

2006-09-27 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/28276] EXPONENT() broken for real constants

2006-09-27 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29259] crash when reading from standard input after writing/reading unformatted file

2006-09-27 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29275] fortran added to language build list even when known buggy version of mpfr found

2006-09-28 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29275] fortran added to language build list even when known buggy version of mpfr found

2006-09-28 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29275] fortran added to language build list even when known buggy version of mpfr found

2006-09-28 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29147] Bad overflow check in DATA statements

2006-09-28 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/25818] Problem with handling optional and entry master arguments

2006-09-28 Thread kargl at gcc dot gnu dot org
--- 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

2006-09-28 Thread kargl at gcc dot gnu dot org
-- 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

[Bug fortran/29147] Bad overflow check in DATA statements

2006-09-28 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29147] Bad overflow check in DATA statements

2006-09-28 Thread kargl at gcc dot gnu dot org
--- 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

[Bug libfortran/29121] CPU_TIME subroutine missing for REAL(kind=10) argument

2006-09-29 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/24828] Z and negative integers

2006-09-29 Thread kargl at gcc dot gnu dot org
--- 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

[Bug libfortran/29121] CPU_TIME subroutine missing for REAL(kind=10) argument

2006-09-29 Thread kargl at gcc dot gnu dot org
--- 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

2006-09-29 Thread kargl at gcc dot gnu dot org
--- 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

[Bug target/29292] configure produces strange gmp, mpfr lib directories.

2006-09-29 Thread kargl at gcc dot gnu dot org
--- 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

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

2006-09-30 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29312] Errors in subnormal calculation

2006-10-01 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/18026] boz initialization of REALs fails

2006-10-02 Thread kargl at gcc dot gnu dot org
--- 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

[Bug target/17174] Fortran nearest broken on AIX

2006-10-03 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29343] (Regression) Error on valid specification variables in same call to ALLOCATE

2006-10-04 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29344] [gfortran,4.2.0 regression] valid ALLOCATE-statement rejected

2006-10-04 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/15441] RRSPACING broken for denormals

2006-10-04 Thread kargl at gcc dot gnu dot org
--- 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

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

2006-10-05 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/15441] RRSPACING broken for denormals

2006-10-05 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/25850] real kind=16 failures on powerpc-darwin

2006-10-05 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/24398] invalid module file gives weird error

2006-10-05 Thread kargl at gcc dot gnu dot org
--- 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

2006-10-06 Thread kargl at gcc dot gnu dot org
--- 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

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

2006-10-06 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29312] Errors in subnormal calculation

2006-10-09 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/15441] RRSPACING broken for denormals

2006-10-09 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/15441] RRSPACING broken for denormals

2006-10-09 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29312] Errors in subnormal calculation

2006-10-09 Thread kargl at gcc dot gnu dot org
--- 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

[Bug libfortran/29423] FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90 and intrinsic_spacing.f90

2006-10-10 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29446] New: VRP ICE in compare_names

2006-10-12 Thread kargl at gcc dot gnu dot org
: 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

2006-10-13 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29403] print ('(a)') not working, print '(a) works

2006-10-13 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type

2006-10-14 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type

2006-10-14 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29403] print ('(a)') not working, print '(a) works

2006-10-15 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29403] print ('(a)') not working, print '(a) works

2006-10-15 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places

2006-10-16 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29403] [4.1 only] print ('(a)') not working, print '(a) works

2006-10-16 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places

2006-10-16 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29403] [4.1 only] print ('(a)') not working, print '(a) works

2006-10-16 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29403] [4.1 only] print ('(a)') not working, print '(a) works

2006-10-16 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29507] New: INDEX in an array initialization causes ICE

2006-10-18 Thread kargl 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) = ...

2006-10-18 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29537] ICE in gfc_match_common

2006-10-21 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29561] hexadecimal constant problem

2006-10-23 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/18026] boz initialization of REALs fails

2006-10-23 Thread kargl at gcc dot gnu dot org
--- 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

[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)

2006-10-23 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29580] integer -2147483648 out of range: bug or feature?

2006-10-24 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29580] integer -2147483648 out of range: bug or feature?

2006-10-24 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29621] lapack runs into infinite loop with -03

2006-10-27 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29621] lapack runs into infinite loop with -03

2006-10-27 Thread kargl at gcc dot gnu dot org
--- 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

2006-10-27 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29621] lapack runs into infinite loop with -03

2006-10-27 Thread kargl at gcc dot gnu dot org
--- 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

[Bug target/29660] get 'internal compiler error' when building numerical recipes

2006-10-30 Thread kargl at gcc dot gnu dot org
--- 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

2006-10-31 Thread kargl at gcc dot gnu dot org
--- 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

[Bug libfortran/29810] ld: (Warning) Unsatisfied symbol fmodl in file /mnt/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl

2006-11-12 Thread kargl at gcc dot gnu dot org
--- 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

2006-11-12 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/29837] INTERFACE overloading INTENT problem - valid code is rejected

2006-11-14 Thread kargl at gcc dot gnu dot org
--- 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

[Bug libfortran/20085] iargc returns wrong count for number of program arguments

2005-02-20 Thread kargl at gcc dot gnu dot org
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-20 15:37 --- Patch applied. -- What|Removed |Added Status|NEW

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

2005-02-20 Thread kargl at gcc dot gnu dot org
-- 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

[Bug fortran/20058] Error on kind 16 hex data statement

2005-02-21 Thread kargl at gcc dot gnu dot org
--- 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

[Bug libfortran/20156] gfortran - bus error on backspace

2005-02-25 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/20224] gfortran - flags error on strange, but correct f77 program

2005-02-26 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/20224] gfortran - flags error on strange, but correct f77 program

2005-02-26 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/20224] gfortran - flags error on strange, but correct f66 program

2005-02-27 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/20058] Error on kind 16 hex data statement

2005-02-27 Thread kargl at gcc dot gnu dot org
--- Additional Comments From kargl at gcc dot gnu dot org 2005-02-28 00:42 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug fortran/20335] ICE with attached Fortran source

2005-03-05 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/19754] Shape conformance not checked

2005-03-05 Thread kargl at gcc dot gnu dot org
--- Additional Comments From kargl at gcc dot gnu dot org 2005-03-05 22:31 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug fortran/19936] confused error message about implied do loop

2005-03-05 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/18537] no warning about tabs with std=f95 option

2005-03-05 Thread kargl at gcc dot gnu dot org
--- 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

2005-03-13 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/18026] boz initialization of REALs fails

2005-03-15 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/20520] allocatable arrays used without being allocated without a warning

2005-03-17 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/20541] INTEGER type declaration: ALLOCATABLE, compilation error

2005-03-18 Thread kargl at gcc dot gnu dot org
--- 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

[Bug fortran/20538] compiling -finline-functions -O2 and we crash at runtime

2005-03-18 Thread kargl at gcc dot gnu dot org
--- 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

  1   2   3   4   5   6   7   8   9   10   >