--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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

--- 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