[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #39 from Steve Kargl --- On Wed, Mar 04, 2020 at 12:07:18PM +, thenlich at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 > > On the other hand side, always folding sind(45...90) to cosd(45...0) and > cosd(45...90) to sind(45...0) probably wouldn't be such a bad thing. > It is not only a good thing, it is required to get small max ULP near zero crossings. Testing fma is as accurate and as fast as the bit twiddling methods I devised. I haven't verified, but it seems gcc inlines fma, which likely is bit twiddling.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #42 from Steve Kargl --- On Wed, Mar 04, 2020 at 04:35:02PM +, thenlich at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 > > --- Comment #41 from Thomas Henlich --- > One would assume that fast FMA > (https://en.wikipedia.org/wiki/FMA_instruction_set) is or will be available to > the modern Fortran enthusiast, in the year 202x. > It already is. F2018, 17.11.3 IEEE_FMA. gfortran currently does not implement IEEE_FMA along with a few additional IEEE_ARITHMETIC features added in F2018. Note, gcc/builtins.def has fma, fmaf, and fmal covered. We'll need a mapping in libquadmath if it has a __float128 fma.
[Bug fortran/94228] Preprocessor inconsistency for macros when invoked from gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228 --- Comment #5 from Steve Kargl --- On Thu, Mar 19, 2020 at 10:24:10PM +, markwayne1969 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228 > > --- Comment #4 from Mark Paris --- > (In reply to kargl from comment #3) > > No. Newer C, as opposed to older C, uses // for a comment. > > Fortran uses // as the concatenation operator. Run this > > through a cpp pre-processor. > > > > character(len=80) :: name = 'john ' // 'Doe' > > print *, name > > end > > > > ~/work/bin/cpp a.F > > # 1 "a.F" > > # 1 "" > > # 1 "" > > # 1 "a.F" > > character(len=80) :: name = 'john ' > > print *, name > > end > > Thank you for your kind reply. I understand that this is an issue of disparate use of the same operator, '//' in C and Fortran. > > Is it possible to have cpp recognize the different uses of // by, > say, the file name extension of the source being processed? Sure. Anything is possible if someone puts in the time to write a Fortran specific preprocessor. AFAIK, none of the current diminishing number of gfortran contributors is working a new preprocessor. > Links to information about gcc development for this specific > possible feature would be appreciated. I don't know of any gfortran preprocessor projects. You are more then welcomed to clone the git repository and start such a project. Having new gfortran contributors would be healthy for gfortran's future.
[Bug fortran/94246] [9/10 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 --- Comment #4 from Steve Kargl --- On Sat, Mar 21, 2020 at 10:27:03PM +, dcb314 at hotmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 > > --- Comment #3 from David Binderman --- > (In reply to kargl from comment #2) > > So, what happens if you do use the required -fno-range-check > > option? > > The code is compiled happily: > > $ /home/dcb/gcc/results.20200320.valgrind/bin/gfortran -c -Wall > -fno-range-check gfortran.dg/bessel_5.f90 So, the code should be closed with WONTFIX or INVALID.
[Bug fortran/94228] Preprocessor inconsistency for macros when invoked from gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228 --- Comment #7 from Steve Kargl --- On Mon, Mar 23, 2020 at 02:41:23AM +, markwayne1969 at gmail dot com wrote: > > (In reply to Steve Kargl from comment #5) > > > > > Links to information about gcc development for this specific > > > possible feature would be appreciated. > > > > I don't know of any gfortran preprocessor projects. You are > > more then welcomed to clone the git repository and start > > such a project. Having new gfortran contributors would be > > healthy for gfortran's future. > > Thank you, again for your reply. It's not exactly the information > I was looking for -- perhaps you're not the right person to ask. > If not, you might be able to point me to the correct group. > > I was asking whether you knew of any reason that the existing cpp > couldn't be adjusted to handle the '//' disparity with a filename > extension dependency. > > If this is possible, then it seems like a minor revision, as > opposed to what you appear to have in mind of writing "a Fortran > specific preprocessor," which sounds like a prohibitive undertaking. > You can ask on g...@gcc.gnu.org and fort...@gcc.gnu.org. I doubt that that will be too profitable. Good luck.
[Bug fortran/94246] [9/10 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 --- Comment #6 from Steve Kargl --- On Mon, Mar 23, 2020 at 07:35:54AM +, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246 > > Richard Biener changed: > >What|Removed |Added > >Keywords||error-recovery, >||ice-on-invalid-code >Priority|P3 |P5 > > --- Comment #5 from Richard Biener --- > It's still a valid bugreport, the compiler shouldn't crash even on invalid > programs. > I disagree.
[Bug fortran/94246] [9/10 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246
--- Comment #9 from Steve Kargl ---
On Mon, Mar 23, 2020 at 07:29:02PM +, anlauf at gcc dot gnu.org wrote:
> --- Comment #7 from anlauf at gcc dot gnu.org ---
> I get an ICE even for the non-valgrind version on x86_64-pc-linux-gnu:
>
> gcc/testsuite/gfortran.dg/bessel_5.f90:64:50:
>
>64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ]))
> &
> | 1
> Error: Result of BESSEL_YN overflows its kind at (1)
> gcc/testsuite/gfortran.dg/bessel_5.f90:64:26:
>
>64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ]))
> &
> | 1
> Error: Result of BESSEL_YN is -INF at (1)
> f951: internal compiler error: Segmentation fault
(snip)
>
> I agree with Richard that this should not happen.
>
1. Fix the errors that are already emitted. It won't happen.
2. Use -fmax-errors = 1. It won't happen. -fmax-errors=1 should
be the default. Unfortunately, the GCC diagnosistic has usurped
that option.
3. Write correct Fortran. It won't happen.
4. Apply this patch. Watch for cut-n-paste tab corruption.
ndex: gcc/fortran/arith.c
===
--- gcc/fortran/arith.c (revision 280157)
+++ gcc/fortran/arith.c (working copy)
@@ -1322,6 +1322,12 @@ reduce_binary_ac (arith (*eval) (gfc_expr *, gfc_expr
else
{
gfc_constructor *c = gfc_constructor_first (head);
+
+ if (!c)
+ gfc_fatal_error ("\"To handle a language skillfully is to "
+"practice a kind of evocative sorcery.\" "
+"Charles Baudelaire");
+
r = gfc_get_array_expr (c->expr->ts.type, c->expr->ts.kind,
&op1->where);
r->shape = gfc_copy_shape (op1->shape, op1->rank);
[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397
--- Comment #3 from Steve Kargl ---
On Mon, Mar 30, 2020 at 04:23:11PM +, kargl at gcc dot gnu.org wrote:
>
> --- Comment #2 from kargl at gcc dot gnu.org ---
> (In reply to Martin Liška from comment #1)
> > Confirmed, started with r10-7369-gc38daa7976886a59.
>
> Patch in the linked git revision appears to expose a latent
> bug in TYPE IS(). Two workarounds are to use either
>
> type is (real(4)) ! Bad, because of hard coded kind parameter
>
> or
>
> integer, parameter :: sp = kind(1.)
> ...
> type is (real(sp))
>
Untested patch against svn reverion 280157.
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 280157)
+++ gcc/fortran/match.c (working copy)
@@ -2239,7 +2239,8 @@ found:
a scalar integer initialization-expr and valid kind parameter. */
if (c == ')')
{
- if (e->ts.type != BT_INTEGER || e->rank > 0)
+ if (!gfc_reduce_init_expr (e)
+ || e->ts.type != BT_INTEGER || e->rank > 0)
{
gfc_free_expr (e);
return MATCH_NO;
[Bug fortran/94411] E0.d not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411 --- Comment #3 from Steve Kargl --- On Tue, Mar 31, 2020 at 04:47:04AM +, longb at cray dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411 > > --- Comment #2 from Bill Long --- > Thanks for the quick reply. Is there a predicted release date for 10.1? > Trunk is in stage 4, which is regression and documentation fixes only. Historically, 7.1, 8.1, and 9.1 were released in May. I would suspect a May time frame.
[Bug fortran/93762] Truncation of deferred-length string when passing as optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93762
--- Comment #3 from Steve Kargl ---
Here's a better testcasei, which removes IO statement, which
makes it easier to read -fdump-tree-original.
module deepest_call_m
implicit none
contains
subroutine deepest_call(str)
character(len=:), allocatable, intent(out), optional :: str
if (present(str)) then
str = '12345'
if (len(str) /= 5) stop 1
end if
end subroutine deepest_call
end module deepest_call_m
module interface_call_m
implicit none
contains
subroutine interface_call(str)
use deepest_call_m, only : deepest_call
character(len=:), allocatable, intent(out), optional :: str
if (present(str)) then
call deepest_call(str)
if (len(str) /= 5) stop 2
end if
end subroutine interface_call
end module interface_call_m
program main
use interface_call_m, only : interface_call
implicit none
character(len=:), allocatable :: str
call interface_call(str)
if (len(str) /= 5) stop 3
end program main
Here's the -fdump-tree-original where I have removed
inconsequential code and re-ordered to help with thinking.
Comments are in-lined.
MAIN__ ()
{
integer(kind=4) .str;
character(kind=1)[1:.str] * str;
str = 0B;
interface_call (&str, &.str); /* .str is not set to some value. */
}
interface_call (character(kind=1)[1:*_str] * * str, integer(kind=4) * _str)
{
if (str != 0B)
{
{
/* This is not good. *_str has the value of .str from MAIN,
which wasn't set. */
character(kind=1)[1:*_str] * *D.3819;
integer(kind=4) D.3820;
/* Remove freeing from intent(out) attribute. */
D.3819 = str != 0B ? str : 0B;
D.3820 = str != 0B ? *_str : 0;
/* Here D.3820 is 0. */
deepest_call (D.3819, &D.3820);
/* *_str should be set to D.3820, but isn't. */
}
}
}
deepest_call (character(kind=1)[1:*_str] * * str, integer(kind=4) * _str)
{
if (str != 0B)
{
{
integer(kind=4) D.3808;
integer(kind=4) D.3809;
/* Handle intent(out) and/or re-allocation on assign. */
/* Set *_str to 5, which is the desired length. */
*_str = 5;
D.3808 = *_str;
if (D.3808 > 0)
{
/* Copy '12345' into str. */
}
}
}
}
So, yep! The string length is not propagated up the call chain.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #3 from Steve Kargl --- On Tue, Apr 14, 2020 at 07:23:32AM +, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #2 from Richard Biener --- > Not all targets have a C99 math runtime. libgfortran configury tests for a > load > of C99 functions: > > # Check for C99 (and other IEEE) math functions > GCC_CHECK_MATH_FUNC([acosf]) > GCC_CHECK_MATH_FUNC([acos]) > GCC_CHECK_MATH_FUNC([acosl]) > GCC_CHECK_MATH_FUNC([acoshf]) > ... > > but fails to check for fma[lf ] (I also don't see any uses of the HAVE_* > macros defined but that's another issue. > It is 2020. If a target doesn't support C99, then building gfortran should be prohibited. The file libgfortran/intrinsics/c99_functions.c is nothing but a kludge, and I wrote a part of that file! I also note that FreeBSD does not have a complete C99 and building libstdc++ is broken because of this. Yet, I can't get a trivially stupid patch applied. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #5 from Steve Kargl --- On Tue, Apr 14, 2020 at 12:55:45PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #4 from dave.anglin at bell dot net --- > On 2020-04-13 11:02 p.m., kargl at gcc dot gnu.org wrote: > > Does math.h define fmaf? If yes, this this is bogus bug report. > > If no, please disable building gfortran on hppa64. > No, math.h does not define fmaf. > After '#include ' in trigd.c, add #if (__STDC_VERSION__ < 199901L) #define fmaf(a,b,c) ((a)*(b)+(c)) #define fma(a,b,c) ((a)*(b)+(c)) #define fmal(a,b,c) ((a)*(b)+(c)) #endif
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #7 from Steve Kargl --- On Tue, Apr 14, 2020 at 05:24:51PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #6 from dave.anglin at bell dot net --- > On 2020-04-14 11:40 a.m., sgk at troutmask dot apl.washington.edu wrote: > > After '#include ' in trigd.c, add > > > > #if (__STDC_VERSION__ < 199901L) > > #define fmaf(a,b,c) ((a)*(b)+(c)) > > #define fma(a,b,c) ((a)*(b)+(c)) > > #define fmal(a,b,c) ((a)*(b)+(c)) > > #endif > > > Unfortunately, we also need copysignl, fabsl, cosl, sinl and tanl. > How are you getting to these? These are protected by #ifdef HAVE_GFC_REAL_10 #endif or #ifdef HAVE_GFC_REAL_16 #endif Is hppa64 claiming support for a REAL type that it actually doesn't support? In any event, you can extend the kludge #if (__STDC_VERSION__ < 199901L) #define fmaf(a,b,c) ((a)*(b)+(c)) #define fma(a,b,c) ((a)*(b)+(c)) #define fmal(a,b,c) ((a)*(b)+(c)) #define cosl(a) cos((double)(a)) #define sinl(a) sin((double)(a)) #define tanl(a) tan((double)(a)) #define fabsl(a) ((a) < 0 ? -(a) : (a)) #define copysignl(a,b) (fabsl(a)*((b)/fabsl(b))) #endif
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #9 from Steve Kargl --- On Tue, Apr 14, 2020 at 08:48:47PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #8 from dave.anglin at bell dot net --- > On 2020-04-14 2:12 p.m., sgk at troutmask dot apl.washington.edu wrote: > > #ifdef HAVE_GFC_REAL_16 > > #endif > This one. > > > > Is hppa64 claiming support for a REAL type that it actually > > doesn't support? > Support is a fuzzy word. There's enough support to build libquadmath. So, you have REAL(4), REAL(8), and REAL(16). Is REAL(16) a software implementaton of IEEE 128-bit floating point, which uses libquadmath? If yes, then this suggests the logic to select the suffix 'q' or 'l' needs tweaking as you should be getting, e.g., cosq() from libquadmath instead of cosl(). > > In any event, you can extend the kludge > > > > #if (__STDC_VERSION__ < 199901L) > > #define fmaf(a,b,c) ((a)*(b)+(c)) > > #define fma(a,b,c) ((a)*(b)+(c)) > > #define fmal(a,b,c) ((a)*(b)+(c)) > > #define cosl(a) cos((double)(a)) > > #define sinl(a) sin((double)(a)) > > #define tanl(a) tan((double)(a)) > > #define fabsl(a) ((a) < 0 ? -(a) : (a)) > > #define copysignl(a,b) (fabsl(a)*((b)/fabsl(b))) > > #endif > I have something that builds now. Need to test. > > I think we need to use _POSIX_VERSION as __STDC_VERSION__ is set by cpp. Looking at trigd.c, one finds #ifdef GFC_REAL_16_IS_FLOAT128 /* libquadmath. */ #define SUFFIX(x) x ## q #else #define SUFFIX(x) x ## l #endif /* GFC_REAL_16_IS_FLOAT128 */ So, hppa64 has REAL(16), but it does not use __float128 or GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Instead of the above kludge you can do something like #ifndef HAVE_COSL #define cosl cosq /* Use libquadmath for hppa64. */ #endif HAVE_COSL, HAVE_SINL, HAVE_TANL are definitely available. I don't recall if fabsl and copysignl have similar macros.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #11 from Steve Kargl --- On Tue, Apr 14, 2020 at 11:46:36PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #10 from dave.anglin at bell dot net --- > On 2020-04-14 6:08 p.m., sgk at troutmask dot apl.washington.edu wrote: > > So, hppa64 has REAL(16), but it does not use __float128 or > > GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Instead > > of the above kludge you can do something like > It appears GFC_REAL_16_IS_FLOAT128 is not getting set. Will investigate. > There's a similar problem with the test dec_math.f90 which has started to fail > > We have when the hpux long double library is available: > > /* Under HPUX, the __float128 type is a synonym for "long double". */ > (*lang_hooks.types.register_builtin_type) (long_double_type_node, > "__float128"); > > We have __builtin_fabsq, __builtin_copysignq, __builtin_infq and > __builtin_huge_valq. > I suppose I could add "l" versions. > This seems to be confusing the simply assumptions in libgfortran/kinds-override.h, which states /* What are the C types corresponding to the real(kind=10) and real(kind=16) types? We currently rely on the following assumptions: -- if real(kind=10) exists, i.e. if HAVE_GFC_REAL_10 is defined, then it is necessarily the "long double" type -- if real(kind=16) exists, then: * if HAVE_GFC_REAL_10, real(kind=16) is "__float128" * otherwise, real(kind=16) is "long double" To allow to change this in the future, we create the GFC_REAL_16_IS_FLOAT128 macro that is used throughout libgfortran. */ #if defined(HAVE_GFC_REAL_16) # if defined(HAVE_GFC_REAL_10) # define GFC_REAL_16_IS_FLOAT128 # if !defined(HAVE_FLOAT128) # error "Where has __float128 gone?" # endif # else # define GFC_REAL_16_IS_LONG_DOUBLE # endif #endif So, hpux does not have REAL(10) and has REAL(16). This is doing what it is designed to do based on the assumption that a target like hpux with REAL(16) will define the long double functions with the 'l' suffix. It seems the the fix for hpux is to change the test to something like # if defined(HAVE_GFC_REAL_10) || defined(__HPUX__) using, of course, whatever the relevant macro. This will then select the 'q' suffix.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #14 from Steve Kargl ---
On Wed, Apr 15, 2020 at 03:28:29PM +, dave.anglin at bell dot net wrote:
>
> On 2020-04-15 11:02 a.m., sgk at troutmask dot apl.washington.edu wrote:
> >
> > #if defined(HAVE_GFC_REAL_16)
> > # if defined(HAVE_GFC_REAL_10)
> > # define GFC_REAL_16_IS_FLOAT128
> > # if !defined(HAVE_FLOAT128)
> > # error "Where has __float128 gone?"
> > # endif
> > # else
> > # define GFC_REAL_16_IS_LONG_DOUBLE
> > # endif
> > #endif
> >
> > So, hpux does not have REAL(10) and has REAL(16). This is doing
> > what it is designed to do based on the assumption that a target
> > like hpux with REAL(16) will define the long double functions
> > with the 'l' suffix. It seems the the fix for hpux is to change
> > the test to something like
> >
> > # if defined(HAVE_GFC_REAL_10) || defined(__HPUX__)
> >
> > using, of course, whatever the relevant macro. This will then
> > select the 'q' suffix.
>
> I tried the above approach yesterday but it led to a couple of undefined
> symbols in libgfortran that
> caused a new test fail. Possibly, the above might be a better overall
> approach
It likely is the start of an approach, but it seems hpux is conflating
long double and __float128, where it flips between an 'l' and 'q' suffix.
gfortran simply assumes a correspondence with C types and C99 naming
conventions (e.g., sinf, sin, and sinl). If a target has REAL(4), REAL(8),
REAL(10), and REAL(16) the correspondence is float, double, long double,
and __float128, respectively. If a target has REAL(4), REAL(8), and REAL(16),
then the correspondence is float, double, and long double. There is no
__float128, and by extension, no functions with a 'q' suffix. The long
double math function will end in 'l'.
> but this is what I ended
> up doing last night:
>
> diff --git a/libgfortran/intrinsics/trigd.c b/libgfortran/intrinsics/trigd.c
> index 81699069545..970c60952ee 100644
> --- a/libgfortran/intrinsics/trigd.c
> +++ b/libgfortran/intrinsics/trigd.c
> @@ -27,6 +27,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
> If
> not, see
>
> #include
>
> +#if (_POSIX_VERSION < 200112L)
> +#define fmaf(a,b,c) ((a)*(b)+(c))
> +#define fma(a,b,c) ((a)*(b)+(c))
> +#endif
>
> /*
> For real x, let {x}_P or x_P be the closest representible number in the
> @@ -169,7 +173,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
> If not, see
> #define COSDcosd_r16
> #define TANDtand_r16
>
> -#ifdef GFC_REAL_16_IS_FLOAT128 /* libquadmath. */
> +#if defined(GFC_REAL_16_IS_FLOAT128) || !defined(HAVE_COSL) /* libquadmath.
> */
> #define SUFFIX(x) x ## q
> #else
> #define SUFFIX(x) x ## l
>
> This fixed build of trigd.c. I think I need to do something similar to fix
> dec_math.f90:
>
> FAIL: gfortran.dg/dec_math.f90 -O0 (test for excess errors)
> Excess errors:
> /usr/ccs/bin/ld: Unsatisfied symbols:
>tanl (first referenced in /var/tmp//ccLGIJFM.o) (code)
>asinl (first referenced in /var/tmp//ccLGIJFM.o) (code)
>sinl (first referenced in /var/tmp//ccLGIJFM.o) (code)
>acosl (first referenced in /var/tmp//ccLGIJFM.o) (code)
>atanl (first referenced in /var/tmp//ccLGIJFM.o) (code)
>atan2l (first referenced in /var/tmp//ccLGIJFM.o) (code)
>cosl (first referenced in /var/tmp//ccLGIJFM.o) (code)
>
> It's the only new fail.
What does -fdump-tree-original show for
function foo(x)
real(16) foo, x
foo = cos(x)
end function foo
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #15 from Steve Kargl --- On Wed, Apr 15, 2020 at 06:04:08PM +, dave.anglin at bell dot net wrote: > > /usr/lib/dld.sl: Unresolved symbol: strtoflt128 (data) from This should be in libquadmath. % nm /usr/home/kargl/work/lib/libquadmath.a | grep strtoflt strtoflt128.o: 0880 T strtoflt128 > /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libgfortran.sl.5 > /usr/lib/dld.sl: Unresolved module for symbol: _gfortrani_si_max (code) from This should be in libgfortran and comes from libgfortran/io/read.c. It is unclear why it would be missing. Given that confusion that hpux seems to be causing for libgfortran, it seems the --disable-libquadmath is your best option.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #20 from Steve Kargl ---
On Thu, Apr 16, 2020 at 01:10:21AM +, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #18 from dave.anglin at bell dot net ---
> On 2020-04-15 2:14 p.m., sgk at troutmask dot apl.washington.edu wrote:
> > What does -fdump-tree-original show for
> >
> > function foo(x)
> >real(16) foo, x
> >foo = cos(x)
> > end function foo
> foo (real(kind=16) & restrict x)
> {
> real(kind=16) __result_foo;
>
> __result_foo = __builtin_cosl (*x);
> return __result_foo;
> }
This is what I anticipated after I sent the email.
With -fno-builtin, you'll get cosl, which you don't
have. So, you'll need to figure out how to force
gfortran to use 'q' suffixes instead of 'l'. I don't
know how the frontend will handle this. Using weak
references as you suggested in your other reply might
be the easily (if it worked).
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #22 from Steve Kargl --- On Thu, Apr 16, 2020 at 08:06:00PM +, danglin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #21 from John David Anglin --- > Created attachment 48295 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48295&action=edit > Patch to fix float128 node selection on hpux > > With this change, the libquadmath routines are now selected on hpux. > > Testing. > It is unclear to me if the patch will meet everyone's expectation. In particular, there are currently no target-specific macros used in the Fortran frontend. Using 'defined(__hpux__)' may make some unhappy as it now complicates maintenance and adding new Fortran features.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #24 from Steve Kargl --- On Thu, Apr 16, 2020 at 09:32:46PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #23 from dave.anglin at bell dot net --- > On 2020-04-16 5:07 p.m., sgk at troutmask dot apl.washington.edu wrote: > > It is unclear to me if the patch will meet everyone's > > expectation. In particular, there are currently no > > target-specific macros used in the Fortran frontend. > > Using 'defined(__hpux__)' may make some unhappy as > > it now complicates maintenance and adding new Fortran > > features. > Can I include "../../libgfortran/libgfortran.h" in these frontend routines? > This would pull in > the defines for GFC_REAL_16_IS_FLOAT128 and GFC_REAL_16_IS_LONG_DOUBLE. > That might be worse, but you're in territory that I've not tread. I suggest you send an email to both fortran@ and gcc@ asking for input from more experienced contributors. Don't hold your breath too long on fortran@ replies. Several of us have stop contributing because of the git transition.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #34 from Steve Kargl --- On Wed, Apr 22, 2020 at 04:02:01PM +, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #33 from dave.anglin at bell dot net --- > On 2020-04-22 10:54 a.m., foreese at gcc dot gnu.org wrote: > > If you have a functional gfortran you can also generate it with > > "$GCCSOURCE/libgfortran/mk-kinds-h.sh gfortran". This header is supposed to > > expose the core type which gfortran uses for REAL(16) according to the > > target. > Looking at script, I see it has same logic to disambiguate long double and > float128: > 16) if [ $long_double_kind -eq 10 ]; then > ctype="__float128" > cplxtype="_Complex float __attribute__((mode(TC)))" > suffix="q" > else > ctype="long double" > cplxtype="complex long double" > suffix="l" > fi ;; > > It always selects long double when both are REAL(16). > Which is the correct assumption that I already explained. Both the ISO C binding module and the IEEE 754 modules assume a C99 type mapping. There are only 2 cases: REAL(4) <--> float ! f suffix REAL(8) <--> double ! no suffix REAL(10) <--> long double ! l suffix REAL(16) <--> __float128 ! q suffix or REAL(4) <--> float ! f suffix REAL(8) <--> double ! no suffix REAL(16) <--> long double ! l suffix (if long double exists) I suspect that having HPUX map REAL(4) <--> float ! f suffix REAL(8) <--> double ! no suffix REAL(16) <--> __float128 ! q suffix may cause issues with either ISO C binding or IEEE 754 module or both.
[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 --- Comment #5 from Steve Kargl --- On Sun, Apr 26, 2020 at 02:39:37AM +, busby1 at llnl dot gov wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 > > --- Comment #4 from Lee Busby --- > (In reply to kargl from comment #3) > > (In reply to Thomas Koenig from comment #2) > > > Correction, this is not a regression. > > > > > > F2018 has, in 19.2, paragraph 2 > > > > > > # The global identifier of an entity shall not be the same as the global > > > # identifier of any other entity. Furthermore, a binding label shall not > > > # be the same as the global identifier of any other global entity, > > > # ignoring differences in case. > > > > > > So, the error message is correct, and you need to change your > > > program accordingly. > > > > Good catch, Thomas! > > > > In hindsight, the restriction makes prefect sense given > > Fortran is a case insensitive language. > > I don't have any particular problem using 19.2 to make this a feature, not a > bug. Clarity is always better. I wonder how does 19.2 square with 8.5.5, > lines > 13-14: > > # If the value of the [NAME=scalar-character-constant] is [...] nonzero, > # it shall be valid as an identifier on the companion processor. > > If you ignore the case of an identifier in the C language (the "companion > processor"?), I suppose it is still "valid". But it's the wrong one. Oh, > well, above my pay grade. Thank you for your investigation, and ongoing work > on gfortran. > I suppose I don't quite follow you. gfortran flagged an error in your code. Thomas took the time to locate the passage in the Fortran standard that confirms you have an error in your code. You would rather ask the diminishing number of volunteers to add an extension to gfortran to to compile your nonconforming code than fix the code. Seems reasonable.
[Bug fortran/94769] Possible use of uninitialized variable num
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
--- Comment #4 from Steve Kargl ---
On Mon, Apr 27, 2020 at 06:27:25AM +, stefansf at linux dot ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
>
> --- Comment #3 from Stefan Schulze Frielinghaus ibm.com> ---
> Since one call chain is gfc_resolve_dt -> check_io_constraints ->
> compare_to_allowed_values and at least one parameter of
> compare_to_allowed_values, from which the initialization of variable num
> depends, is passed through non-static function gfc_resolve_dt, the warning
> seems valid to me. Although compare_to_allowed_values is supposed to
> initialize num, it may return with a non-zero value although num is
> not initialized.
>
compare_to_allowed_values() appears 25 times in io.c; once as
a prototype, once as the function, and 23 invocations. This
is the function prototype:
compare_to_allowed_values (const char *specifier, const char *allowed[],
const char *allowed_f2003[],
const char *allowed_gnu[], gfc_char_t *value,
const char *statement, bool warn, locus *where,
int *num = NULL);
Of those 23 invocations, it is called once with a non-NULL &num argument.
That occurence is the one in question. Here is the code:
if (!compare_to_allowed_values
("ASYNCHRONOUS", asynchronous, NULL, NULL,
dt->asynchronous->value.character.string,
io_kind_name (k), warn, &dt->asynchronous->where, &num))
return false;
compare_to_allowed_values() returns either 0 or 1. If it is 0,
then the if-statement will cause check_io_constraint() to return
false and num is never used. If it returns 1, then one needs to
worry about num.
Prior to the invocation, it is noted that one has
static const char *asynchronous[] = { "YES", "NO", NULL };
dt->asynchronous->value.character.string is the string parsed from
the Fortran program, e.g., OPEN(UNIT=10,FILE='foo', ASYNCHRONOUS='string')
The initial code in compare_to_allowed_values() is
len = gfc_wide_strlen (value);
if (len > 0)
{
for (len--; len > 0; len--)
if (value[len] != ' ')
break;
len++;
}
The above accounts for leading whitespace in value (aka
dt->asynchronous->value.character.string), and for a valid value of
ASYNCHRONOUS, len = 2 or 3. The next chunk of code sets num for
a valid value. Here allowed[] = asynchronous[].
for (i = 0; allowed[i]; i++)
if (len == strlen (allowed[i])
&& gfc_wide_strncasecmp (value, allowed[i], strlen (allowed[i])) == 0)
{
if (num)
*num = i;
return 1;
}
If len does not equal 2 or 3, the block of code in the if statement is
not execute, num is not set, and the remainder of compare_to_allowed_values()
is executed, generating an error message, and returning 0. A return of
0 means that num is not used in check_io_constraint as it returns false.
If len is equal to 2 or 3, then value is compared to "YES" and "NO".
If the comparison is true, then num (being a non-NULL pointer) has
it target set to either 0 or 1 (i.e., the index of "YES" or "NO"
in allowed[]). If the comparison is false, then the block of code in the
if statement is not execute, num is not set, and the remainder of
compare_to_allowed_values() is executed, generating an error message,
and returning 0. A return of 0 means that num is not used in
check_io_constraint as it returns false.
In other words, a false positive.
There are now three choices.
1) Remove the command line option that causes the false positive.
2) Fix gcc to not generate a false positive.
3) Set num to anything you want to silence a false positive.
The above are the three options I offered in comment #1.
[Bug fortran/94769] Possible use of uninitialized variable num
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769 --- Comment #6 from Steve Kargl --- On Mon, Apr 27, 2020 at 05:12:50PM +, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769 > > Thomas Koenig changed: > >What|Removed |Added > > CC||tkoenig at gcc dot gnu.org > > --- Comment #5 from Thomas Koenig --- > Steve, > > is this sort of what you had in mind? > Yes, that should work. Unfortunately, io.c has changed from svn r280157, so I can only look at the current code through gitweb. The blame feature shows that Fritz added the 'if (num == 0)' block of code on 2020-04-09 while Jerry introduced the passing of &num in 2008.
[Bug fortran/93366] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93366 --- Comment #4 from Steve Kargl --- On Wed, Apr 29, 2020 at 08:57:44PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93366 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > CC||anlauf at gcc dot gnu.org > > --- Comment #3 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #2) > > patch against last SVN revision. > Steve, > > do you still care? > It is not that I don't care. It is that I no longer have an ability to commit patches or checkout top-of-tree. The recent io.c discuss that I participated in shows that top-of-tree and svn r280157 have started to diverge substantially. So, my time is done. It is time for a younger generation to step up.
[Bug fortran/94931] request: print include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931 --- Comment #3 from Steve Kargl --- On Mon, May 04, 2020 at 01:13:22AM +, ryofurue at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931 > > --- Comment #2 from Ryo Furue --- > Thanks for the detailed description. > > > > % gfcx -v -o z a.f90 | & grep -- -fin > > > > yields > > > > -fintrinsic-modules-path > > /usr/home/kargl/work/lib/gcc/i586-unknown-freebsd13.0/10.0.0/finclude > > So, I wonder if it is possible and would make sense to include > that information in the output of `--print-search-dirs` ? > Why? --print-search-dirs does not include information about C/C++ include paths. The documentation states '-print-search-dirs' Print the name of the configured installation directory and a list of program and library directories 'gcc' searches--and don't do anything else. There is only place gfortran will search for files that it installs for intrinsic modules, openmp files, and openacc files. There are no user files here.
[Bug fortran/94931] request: print include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931
--- Comment #5 from Steve Kargl ---
On Mon, May 04, 2020 at 01:33:43AM +, ryofurue at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931
>
> --- Comment #4 from Ryo Furue ---
> > There is only place gfortran will search for files that
> > it installs for intrinsic modules, openmp files, and
> > openacc files. There are no user files here.
>
> I see your point!
>
> So, should a library developer install the include files there (the directory
> where the intrinsic modules go)? I suppose that is the design?
>
> Thanks for your patience!
>
For my personal, projects I put libraries in ${HOME}/lib
and modules in ${HOME}/modules. I don't use include files
above the library levels. For a software developer, I
would put the libraries in ${INSTALLDIR}/lib and modules
in ${INSTALLDIR?/modules. INSTALLDIR could be /usr/local,
and, of course, you would describe this in the user and
installation manuals.
[Bug fortran/94931] request: print include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931 --- Comment #7 from Steve Kargl --- On Mon, May 04, 2020 at 08:23:17AM +, ryofurue at gmail dot com wrote: > > But, then the question is, why don't you need the -L option? as in > > gfortran -I/usr/include mysourcefile.f -L/usr/lib -lnetcdff -netcdf > > > Why is this asymmetry? It seems that there are "standard" places to place > libraries but not include files . . . I think you're seeing the effects of shared libraries. The loader has library information: % ldconfig -r | grep netcdf 453:-lnetcdf.15 => /usr/local/lib/libnetcdf.so.15 My advice is to always have the correct -L options.
[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 --- Comment #14 from Steve Kargl --- On Tue, May 12, 2020 at 06:43:54PM +, seurer at linux dot vnet.ibm.com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 > > --- Comment #13 from Bill Seurer --- > I don't know fortran and this appears to be part of a multi-thousand line > extremely complex function. > There is only a single division in that line of code. Can you determine what the value of cldeps is? The error message suggests that it is 0. If there is a testcase that you can run, then change the code to if (cldeps == 0) then print *, 'Whoops. cldeps = ', cldeps stop 1 else asort(nxs) = 1.0_r8-(floor(cld(i,k)/cldeps)*cldeps) end if
[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 --- Comment #23 from Steve Kargl --- On Thu, May 14, 2020 at 02:57:37PM +, wschmidt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 > > Bill Schmidt changed: > >What|Removed |Added > > CC||wschmidt at gcc dot gnu.org > > --- Comment #22 from Bill Schmidt --- > Breaking legitimate code, even if "borderline," does not seem right to me. > Zero division is generally a runtime exception because of such cases. > > You write code for a general case, then later you discover "oh, well, we could > make this variable zero for our specific usage," and now the compiler throws a > fit? Seems like this is warning-level stuff. > If Bill's reduction of the several thousand-line file to 10ish lines is an accurate reduction (and I have no reasons to doubt that it isn't), then no. It is an programming error. This is not the first time that gfortran has found a programming error in WRF. Sure, in this case the 'if (cdleps > 0)' leads to dead code elimination, but DCE happens after gfortran has done some constant folding and common subexpression elimination in the front-end.
[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 --- Comment #27 from Steve Kargl --- On Thu, May 14, 2020 at 06:39:24PM +, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 > > --- Comment #26 from Thomas Koenig --- > (In reply to wschmidt from comment #24) > > > I'm afraid I disagree. A divide-by-zero that cannot ever be executed is > > not an error. > > Well, there is PR90302. We could insert some piece of code into the > IL. A warning or an error could then be issued if the piece of code is still > present after the final optimization. > > It would make a nice project, and remove a few more false positives > as well. > gfortran supports a legacy extension of jumping into a if-block. Prior to Harald's patch (which fixes at least 1 ICE), we have % cat a.f90 program foo real x, y real, parameter :: c = 0 x = 1 y = 2 goto 10 if (c > 0) then 10x = (y / c) * c end if print *, x, y end program foo % gfcx -o z a.f90 && ./z a.f90:8:2: 6 |goto 10 | 2 7 |if (c > 0) then 8 | 10x = (y / c) * c | 1 Warning: Legacy Extension: Label at (1) is not in the same block as the GOTO statement at (2) NaN 2. So, using 'if (c > 0)' to assume DCE occurs is invalid as the code is reachable. Perhaps, my original patch submitted at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93499#c2 should have been committed with no attempt to aid a programmer from making a potential mistake.
[Bug libfortran/95177] error: array subscript has type char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177 --- Comment #4 from Steve Kargl --- On Tue, May 19, 2020 at 04:38:32AM +, roland.illig at gmx dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177 > > --- Comment #2 from Roland Illig --- > >--- Comment #1 from kargl at gcc dot gnu.org --- > >Why cast to unsigned char? The prototypes for tolower(), toupper(), > >isdigit(), etc show that the type of the argument is int. > > See https://stackoverflow.com/a/60696378 for a detailed explanation. > Ah, yeah, so? There are no subscripts in the code you are changing. Why does -Werror=char-subscripts trigger if there are no subscripts? Is the error flag misnamed? If you're going to fix unbroken code, why not cast the argument to the declared type of the ctype functions?
[Bug libfortran/95177] error: array subscript has type char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177 --- Comment #9 from Steve Kargl --- On Wed, May 20, 2020 at 04:10:50AM +, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177 > > Thomas Koenig changed: > >What|Removed |Added > > Ever confirmed|0 |1 > Status|UNCONFIRMED |NEW >Last reconfirmed||2020-05-20 > > --- Comment #8 from Thomas Koenig --- > Alternatively, it might make sense to change some variable types to > GFC_UINTEGER_1 aka unsigned char. > That could work. I'm still trying to understand how an option names -Werror=char-subscripts could trigger an error. There are no subscripts. AFAIK, the patched routines are not general purpose routines, so the char arguments can only take on values from the Fortran character set, which is a subset of the 7-bit ASCII set. Just commit the patch. I've wasted too much time trying to get an answer about how the option works. Nothing like cluttering working code.
[Bug libfortran/95293] Fortran not passing array by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 --- Comment #3 from Steve Kargl --- On Sat, May 23, 2020 at 10:43:23PM +, david.sagan at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 > > --- Comment #2 from David Sagan --- > The gcc documentation says: > > ‘array-temps’ > Warns at run time when for passing an actual argument a temporary array had to > be generated. The information generated by this warning is sometimes useful in > optimization, in order to avoid such temporaries. > > But a temporary array does not have to be created in this example. The ifort > compiler does not do this. > I suspect your code is invalid, and so gfortran results are correct. Namely, you have call sub2(s1%cc%cbar) ... subroutine sub2(vec) real, target, intent(inout) :: vec(:) ... vec(2) = 23 s1%cc(2)%cbar = 10 ... end subroutine sub2 >From F2028 2 The name of the dummy argument may be different from the name, if any, of its effective argument. The dummy argument name is the name by which the effective argument is known, and by which it may be accessed, in the referenced procedure. The effective argument is s1%cc%cbar and the dummy argument is vec. Within sub2, you can access vec, which vec(2) = 23 does. The 's1%cc(2)%cbar' cannot be accessed via host association. Fortran also does not specify calling semantics, so this call sub2(s1%cc%cbar) becomes tmp = s1%cc%cbar call sub2(tmp) s1%cc%bar= tmp which is essentially create temporary for s1%cc%cbar temporary becomes vec(:) set vec(2) = 23 set s1%cc(2)%cbar = 10 (which is a no-no as it is an effective argument) return to main and copy vec into s1%cc%cbar (which overwrites the no-no) Of course, I could be wrong. Of course, changing an entity via both an effective argument and host association is also questionable.
[Bug libfortran/95293] Fortran not passing array by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 --- Comment #5 from Steve Kargl --- On Sun, May 24, 2020 at 06:47:18AM +, tkoenig at gcc dot gnu.org wrote: > > and the effective argument has the TARGET attribute > > That I will have to look up; if a has the TARGET attribute, > does a%b have it as well? > You're looking for If an object has the TARGET attribute, then all of its nonpointer subobjects also have the TARGET attribute. I believe it does not matter. The effective argument is s1%cc%cbar. The subroutine sub2() accesses s1%cc(2)%cbar via host association. I've quoted the relevant part of the standard that says an effective should be accessed via the dummy argument. You basically have an aliasing problem where something is known by a dummy argument and by host association. It's a rather questionable programming idiom. Consider, program foo real x x = 42 call bar(x) print *, x contains subroutine bar(a) real, intent(inout) :: a a = 12 x = 0 end subroutine bar end program foo Should this print 12 or 0? When bar returns 'a' has a value of 12, should this value be transferred to 'x' before the print statement is executed?
[Bug libfortran/95293] Fortran not passing array by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 --- Comment #7 from Steve Kargl --- On Sun, May 24, 2020 at 02:45:32PM +, david.sagan at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293 > > --- Comment #6 from David Sagan --- > > program foo > >real x > >x = 42 > >call bar(x) > >print *, x > >contains > > subroutine bar(a) > > real, intent(inout) :: a > > a = 12 > > x = 0 > > end subroutine bar > > end program foo > > > > Should this print 12 or 0? When bar returns 'a' has a value of > > 12, should this value be transferred to 'x' before the print > > statement is executed? > > 'a' is passed by reference. Therefore, when the statement 'x = 0' is executed, > the value of 'a' immediately changes to 0. So '0' will be printed. > The code, like your original example, is invalid. As this is not a numbered constraint, a Fortran processor is not required to tell a programmer that the program violated the standard. 15.5.2.13 Restrictions on entities associated with dummy arguments While an entity is associated with a dummy argument, the following restrictions hold. (1) Does not apply (2) Does not apply (3) Action that affects the value of the entity or any subobject of it shall be taken only through the dummy argument unless (a) Does not apply (b) Does not apply (c) Does not apply (d) Does not apply
[Bug libfortran/95104] [9/10/11 Regression] Segfault on a legal WAIT statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104 --- Comment #7 from Steve Kargl --- On Tue, May 26, 2020 at 08:30:36PM +, anlauf at gcc dot gnu.org wrote: > > --- Comment #6 from anlauf at gcc dot gnu.org --- > Steve, do you want me to commit it for you, including backports? > I no longer commit, because I do not use git and have no day-job reason to learn it. As trunk advances from the last available svn revision, I'll simply stop submitting patches.
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373
--- Comment #4 from Steve Kargl ---
On Wed, May 27, 2020 at 08:04:22PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373
>
> --- Comment #3 from anlauf at gcc dot gnu.org ---
> Patch:
>
> diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
> index d73898473df..67105cc9ab1 100644
> --- a/gcc/fortran/primary.c
> +++ b/gcc/fortran/primary.c
> @@ -1998,6 +1998,28 @@ is_inquiry_ref (const char *name, gfc_ref **ref)
>else
> return false;
>
> + switch (type)
> +{
> +case INQUIRY_RE:
> +case INQUIRY_IM:
> + if (!gfc_notify_std (GFC_STD_F2008, "RE or IM part_ref at %C"))
> + return false;
> + break;
> +
> +case INQUIRY_KIND:
> + if (!gfc_notify_std (GFC_STD_F2003, "KIND part_ref at %C"))
> + return false;
> + break;
> +
> +case INQUIRY_LEN:
> + if (!gfc_notify_std (GFC_STD_F2003, "LEN part_ref at %C"))
> + return false;
> + break;
> +
> +default:
> + gcc_unreachable ();
> +}
> +
This is clearly better than the patch I submitted.
It it regression tests cleanly, feel free to commit
with appropriate testase(s).
[Bug fortran/95398] ICE on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95398 --- Comment #1 from Steve Kargl --- On Thu, May 28, 2020 at 09:33:08PM +, kargl at gcc dot gnu.org wrote: > > Code posted at > > https://groups.google.com/forum/#!topic/comp.lang.fortran/mW1gV6tyxXk Here's the code implicit none type :: t1 integer :: i end type type, extends(t1) :: t2 end type class(t1), allocatable :: array1(:,:) class(t2), allocatable :: array2(:,:) allocate(array1(3,3)) allocate(array2(3,3)) select type(b => foo(1)) type is (t1) b%i = 1 !VDC type is (t2) call sub_with_in_and_inout_param(b,b) !VDC end select contains function foo(i) integer :: U(2) integer :: i class(t1), POINTER :: foo(:) ALLOCATE(FOO(2)) U = (/ 1,2 /) if (i>0) then foo => array1(2,U) else foo => array2(2,U) end if end function subroutine sub_with_in_and_inout_param(y, z) type(t2), INTENT(IN) :: y(:) class(t2), INTENT(INOUT) :: z(:) z%i = 10 end subroutine end
[Bug fortran/95544] ICE in gfc_can_put_var_on_stack, at fortran/trans-decl.c:494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95544
--- Comment #4 from Steve Kargl ---
Likely, want to include this in the commit if someone ever gets
around to committing the patch(es).
Index: gcc/fortran/misc.c
===
--- gcc/fortran/misc.c (revision 280157)
+++ gcc/fortran/misc.c (working copy)
@@ -252,7 +252,8 @@ gfc_dummy_typename (gfc_typespec *ts)
has_length = ts->u.cl->length != NULL;
if (!has_length)
{
- if (ts->kind == gfc_default_character_kind)
+ if (ts->kind == gfc_default_character_kind
+ || ts->kind == 0)
sprintf(buffer, "CHARACTER(*)");
else if (ts->kind < 10)
sprintf(buffer, "CHARACTER(*,%d)", ts->kind);
[Bug testsuite/95546] Random Fortran test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95546 --- Comment #5 from Steve Kargl --- On Fri, Jun 05, 2020 at 03:46:18PM +, jvdelisle at charter dot net wrote: > > I am curious, did this just start happening or is it a long time issue just > reported. Locking mecahnisms were adjusted recently I believe. > What locking are you referring to? If it some recent changes to libgfortran's pthread locking, then I think that has nothing to do with the problem reported here. The code eof_4.f90 runs multiple tests. The looks like open(unit=99, file='test.dat', status='new') ! ! Test 1 ! close(99, status='delete') open(unit=99, file='test.dat', status='new') ! ! Test 2 ! close(99, status='delete') open(unit=99, file='test.dat', status='new') ! ! Test 3 ! close(99, status='delete') The above is actually testing Fortran feature. HJ Lu reported problems with 'make -jN', which suggests that eof_4.f90 is being compiled and executed in parallel. That is subject to races. Dejagnu needs to be told that eof_4.f90 cannot be run in parallel. If it is not possible to defeat dejagnu, then the test will need to changed to use a unique file name character(len=20) name write(name, '(A,I0,A)') 'tmp', getpid(), '.dat' open(unit=99, file=name, status='new') ! ! Test 1 ! close(99, status='delete') The test could also be adjusted to use inquire() and sleep() (need to check syntax) 1 inquire(file='test.dat', exists=stat) if (stat == 1) then call sleep(2) goto 1 end if
[Bug fortran/95543] [PDT] ICE in is_CFI_desc, at fortran/expr.c:1080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543 --- Comment #3 from Steve Kargl --- On Sat, Jun 06, 2020 at 04:34:53PM +, kargl at gcc dot gnu.org wrote: > > This cures the ICE, which then I believe leads to wrong-code. > PDT are completely broken. When this is parsed type t(a, b) integer, kind :: a = 1 integer, kind :: b = a end type the internal representation of for 't' has two components; namely, a component for 'a' and a component for 'b'. Neither 'a' nor 'b' is a component, and should therefore not be in the link list of components. All of the programs in this bug report should likely print nothing.
[Bug fortran/95543] [PDT] ICE in is_CFI_desc, at fortran/expr.c:1080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543 --- Comment #4 from Steve Kargl --- On Sat, Jun 06, 2020 at 05:13:31PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543 > > --- Comment #3 from Steve Kargl --- > On Sat, Jun 06, 2020 at 04:34:53PM +, kargl at gcc dot gnu.org wrote: > > > > This cures the ICE, which then I believe leads to wrong-code. > > > > PDT are completely broken. When this is parsed > >type t(a, b) > integer, kind :: a = 1 > integer, kind :: b = a >end type > > the internal representation of for 't' has two components; > namely, a component for 'a' and a component for 'b'. Neither > 'a' nor 'b' is a component, and should therefore not be > in the link list of components. All of the programs in this > bug report should likely print nothing. > A little debugging shows *ts->u.derived->param_list = 0x0 ts->u.derived->components->name = 'a' ts->u.derived->components->next->name = 'b' It seems that param_list is populated when the derived type definition is used in an actual derived type declaration, ie., type(t(b=6)) would have a param_list item for 'b'. Looking in gfortran.h shows param_list is a 'gfc_actual_arglist *' type, ie., a list of actual arguments. Probably not a bad idea, since 't(b=6,a=4)' is valid and 'a' and 'b' can be treated as-if they are actual arguments to a function 't'. components are 'gfc_symbol *', so we cannot simply move then to the param_list.
[Bug fortran/95544] ICE in gfc_can_put_var_on_stack, at fortran/trans-decl.c:494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95544 --- Comment #7 from Steve Kargl --- On Mon, Jun 08, 2020 at 08:02:48PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95544 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > CC||anlauf at gcc dot gnu.org > > --- Comment #5 from anlauf at gcc dot gnu.org --- > Created attachment 48708 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48708&action=edit > Cleaned up patch > > Hi Steve, > > since there is already a function invalid_null_arg(), it can be reused. > > If you do not object, I'll package it for you. > No problem. I was aware of invalid_null_arg(), but simply copied a nearby gfc_error().
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #4 from Steve Kargl --- On Thu, Jun 11, 2020 at 02:56:58PM +, kargl at gcc dot gnu.org wrote: > > IEEE-754 permits the extended double type (See 3.7 Extended and > extendable precisions). I do not see in the Fortran standard that > the output from ieee_seleted_real_kind must select binary32, > binary64, or binary128. Addendum 1, in case anyone cares. Neither IEEE decimal64 nor decimal128 can be returned as gfortran currently does not support RADIX=10. > That said, ieee_selected_real_kind is completely broken. > See PR69101. I used to have patch that fixed this PR, > but never got around to committing it. The patch attached > in 69101 is not correct. Addendum 2, I may have found my last working patch. If I get around to it, I might post it in the PR. Addendum 3, F2018 has added at least ieee_fma. gfortran does not support it.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #7 from Steve Kargl --- On Thu, Jun 11, 2020 at 04:12:57PM +, longb at cray dot com wrote: > > --- Comment #5 from Bill Long --- > The same user also submitted a bug about IEEE_FMA not being supported. Is > there already a bug/rfe for that in the gcc bugzilla? > Not that I am aware of. I had planned on looking at ieee support after 10.1 was released, because it is a longer term effort. The switch to git has caused me to abandon that effort.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #8 from Steve Kargl --- On Thu, Jun 11, 2020 at 04:21:25PM +, longb at cray dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 > > --- Comment #6 from Bill Long --- > (In reply to kargl from comment #3) > > (In reply to Bill Long from comment #0) > > > > cat test.f90 > > > > > Gfortran: > > > > > > > module swap PrgEnv-intel PrgEnv-gnu > > > > gfortran test.f90 > > > > ./a.out > > > selected_real_kind(16) = 10 > > > ieee_selected_real_kind(16) = 10 > > > > > > The output from gfortran is problematic because ieee_selected_real_kind > > > should not return 10. If the users want KIND=10 (i.e. the > > > Intel-proprietary 80-bit x87 floats), then they need to use > > > selected_real_kind and not the IEEE version. > > > > IEEE-754 permits the extended double type (See 3.7 Extended and > > extendable precisions). I do not see in the Fortran standard that > > the output from ieee_seleted_real_kind must select binary32, > > binary64, or binary128. > > > > That said, ieee_selected_real_kind is completely broken. > > See PR69101. I used to have patch that fixed this PR, > > but never got around to committing it. The patch attached > > in 69101 is not correct. > > > The description in the Fortran standard for IEEE_SELECTED_REAL_KIND includes > "The result has a value equal to a value of the kind type parameter of an > ISO/IEC/IEEE 60559:2011 floating-point format..." This, in practice, amounts > to > binary32, 64, 128 for RADIX=2 (the default). The 80-bit x87 format is not > part > of the quoted IEEE standard. > IEEE-754 calls binary32, 64, 128 the basic formats (Sec. 3, p. 6): Five basic formats are defined in this clause: Three binary formats, with encodings in lengths of 32, 64, and 128 bits. Two decimal formats, with encodings in lengths of 64 and 128 bits. Additional arithmetic formats are recommended for extending these basic formats (see 3.7). If J3 really intended that IEEE_SELECTED_REAL_KIND return a kind for one of IEEE-754 basic formats, then it ought to say that. Looks like a defect in the Fortran standard. If one looks into 3.7 (p. 14), it further recommends Language standards should define mechanisms supporting extendable precision for each supported radix.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #9 from Steve Kargl --- On Thu, Jun 11, 2020 at 10:14:21AM -0700, Steve Kargl wrote: > > IEEE-754 calls binary32, 64, 128 the basic formats (Sec. 3, p. 6): > > Five basic formats are defined in this clause: > Three binary formats, with encodings in lengths of 32, 64, and 128 bits. > Two decimal formats, with encodings in lengths of 64 and 128 bits. > > Additional arithmetic formats are recommended for extending these basic > formats (see 3.7). > > If J3 really intended that IEEE_SELECTED_REAL_KIND return a kind for one of > IEEE-754 basic formats, then it ought to say that. Looks like a defect > in the Fortran standard. > > If one looks into 3.7 (p. 14), it further recommends > > Language standards should define mechanisms supporting extendable > precision for each supported radix. > I have asked on the J3 mailing list if Section 17 should be restricted to the basic formats.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #13 from Steve Kargl --- On Fri, Jun 12, 2020 at 04:16:53AM +, kargl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 > > --- Comment #12 from kargl at gcc dot gnu.org --- > (In reply to Bill Long from comment #11) > > I checked with the Intel docs and the ia64 version of the compiler (what HPC > > users use) does not support x87. > > > > Is there a gfortran compiler option to disable x87 use (i.e. REAL(10) is an > > error), to match the other compilers? > > The types are set up in trans-type.c(gfc_init_kinds). I > do not see an option that would disable querying for > long_double_type_node. In principle, one might be able > to define an option that prevents gfortran from see a > long_double_type_node. This should then disable REAL(10). I have confirmed that having an -fdisable-real10 option could disable REAL(10) by commenting out the enumeration of long_double_type_node, i.e., Index: gcc/fortran/trans-types.c === --- gcc/fortran/trans-types.c (revision 280157) +++ gcc/fortran/trans-types.c (working copy) @@ -451,7 +451,7 @@ gfc_init_kinds (void) continue; if (mode != TYPE_MODE (float_type_node) && (mode != TYPE_MODE (double_type_node)) - && (mode != TYPE_MODE (long_double_type_node)) +// && (mode != TYPE_MODE (long_double_type_node)) #if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT) && (mode != TFmode) #endif With a bit of work, someone could do Index: gcc/fortran/trans-types.c === --- gcc/fortran/trans-types.c (revision 280157) +++ gcc/fortran/trans-types.c (working copy) @@ -451,7 +451,7 @@ gfc_init_kinds (void) continue; if (mode != TYPE_MODE (float_type_node) && (mode != TYPE_MODE (double_type_node)) - && (mode != TYPE_MODE (long_double_type_node)) + && (!flag_disable_real10 || mode != TYPE_MODE (long_double_type_node)) #if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT) && (mode != TFmode) #endif
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #15 from Steve Kargl --- On Fri, Jun 12, 2020 at 03:33:20PM +, anlauf at gcc dot gnu.org wrote: > --- Comment #14 from anlauf at gcc dot gnu.org --- > Why don't we simply set IEEE_SUPPORT_DATATYPE (1._10) to .false.? > > use, intrinsic :: ieee_arithmetic > print *, ieee_support_datatype (1._10) > end > > We currently print 'T'. > Because REAL(10) is a valid IEEE-754 format. Some may want REAL(10) because it is sufficient for their numerical problem and it is done in hardware. REAL(16) is a software implementation (can you say slow).
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #16 from Steve Kargl --- On Thu, Jun 11, 2020 at 10:40:29PM -0700, Steve Kargl wrote: > On Fri, Jun 12, 2020 at 04:16:53AM +, kargl at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 > > > > --- Comment #12 from kargl at gcc dot gnu.org --- > > (In reply to Bill Long from comment #11) > > > I checked with the Intel docs and the ia64 version of the compiler (what > > > HPC > > > users use) does not support x87. > > > > > > Is there a gfortran compiler option to disable x87 use (i.e. REAL(10) is > > > an > > > error), to match the other compilers? > > > > The types are set up in trans-type.c(gfc_init_kinds). I > > do not see an option that would disable querying for > > long_double_type_node. In principle, one might be able > > to define an option that prevents gfortran from see a > > long_double_type_node. This should then disable REAL(10). > > I have confirmed that having an -fdisable-real10 option > could disable REAL(10) by commenting out the enumeration > of long_double_type_node, i.e., > Hmmm. Well, my attempt to add an option failed. I leave this here in case someone else wants to unfix gfortran.
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #4 from Steve Kargl --- On Sat, Jun 13, 2020 at 08:11:22AM +, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 > > --- Comment #3 from Thomas Koenig --- > If we treat .eq. and == differently, that is an indication > of a bug in the compiler itself. If a user provides an overloading of .eq. or == with an INTERFACE OPERATOR() statement, then things appear to work. The IEEE modules are not provided by a user and for parts of the modules gfortran builts the needed the pieces at compile time. gfortran also marks symbols as coming from an IEEE module for special handling. For whatever reason, with the IEEE_ARITHMETICi module if the interface is given in terms of ==, it is not overloaded to .eq.; while for the converse .eq. is overloaded to ==. The purposed patch fixes this issue.
[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 --- Comment #18 from Steve Kargl --- On Sat, Jun 13, 2020 at 10:14:43AM +, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640 > > --- Comment #17 from Andrew Pinski --- > (In reply to Steve Kargl from comment #13) > > With a bit of work, someone could do > > > > Index: gcc/fortran/trans-types.c > > === > > --- gcc/fortran/trans-types.c (revision 280157) > > +++ gcc/fortran/trans-types.c (working copy) > > @@ -451,7 +451,7 @@ gfc_init_kinds (void) > > continue; > >if (mode != TYPE_MODE (float_type_node) > > && (mode != TYPE_MODE (double_type_node)) > > - && (mode != TYPE_MODE (long_double_type_node)) > > + && (!flag_disable_real10 || mode != TYPE_MODE > > (long_double_type_node)) > > #if defined(HAVE_TFmode) && defined(ENABLE_LIBQUADMATH_SUPPORT) > > && (mode != TFmode) > > #endif > > > It needs to be more complex than that as long double on most > targets is NOT the 80bit (96bit or 128bit storage) IEEE FP type. Of course, this was just a test to see if it would work. It does not. As gfortran's behavior conforms with the Fortran standard, I'm inclined to close the bug report with INVALID. But, I'm leaving it open as someone else might find value in disabling REAL(10). Now, if someone else closes the bug, I won't object.
[Bug fortran/30372] various intrinsics do not diagnose invalid argument kinds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372 --- Comment #14 from Steve Kargl --- This patch brings UNLINK subroutine into agreement with its documentation. Index: gcc/fortran/check.c === --- gcc/fortran/check.c (revision 280157) +++ gcc/fortran/check.c (working copy) @@ -7267,6 +7275,9 @@ gfc_check_unlink_sub (gfc_expr *name, gfc_expr *status return false; if (!type_check (status, 1, BT_INTEGER)) +return false; + + if (!kind_value_check (status, 1, gfc_default_integer_kind)) return false; return true;
[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635 --- Comment #4 from Steve Kargl --- On Sun, Jun 21, 2020 at 05:44:51PM +, drikosev at gmail dot com wrote: > > The attached patch contains various test cases for the PR's you mentioned at: > https://groups.google.com/d/msg/comp.lang.fortran/Xu73gGydAJk/X2YXyjndCAAJ > > You simply apply it to your local working tree (ignore whatever fails). > > patch -p0 < gcc48-tc93635-n.patch > > Just ensure that these test cases indeed make some sense; they need a review. > Thanks. Now, what is needed is someone taking the next step to becoming a gfortran contributor in the sense that she/he can commit changes to source tree.
[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614 --- Comment #4 from Steve Kargl --- On Mon, Jun 22, 2020 at 09:10:25AM +, drikosev at gmail dot com wrote: > > --- Comment #3 from Ev Drikos --- > > Hello, > > Perhaps, an additional check in file resolve.c might be necessary, or > one would have to adjust one-two "common*.f" test cases. > > Hope this helps, > Ev. Drikos Yes, indeed. Some testcases may need to be updated to account for the new error message or one may needs to use the old testcase to adjust the conditional to not trigger for the older testcase. Also, note that I've found invalid Fortran in testcases as I've fixed a bug. When parsing a file, gfortran runs a series of matchers. If a failure is detected in a matcher an error message is queued, and then other matchers are run. If no matcher succeeds in matching a statement, the last queued error message(s) is(are) emitted and gfortran will exit. If a matcher does match a statement, then the error queue is cleared and the next statement is parsed. Sometimes a new patch will find invalid Fortran in the testsuite.
[Bug fortran/52279] Fortran translation issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279 --- Comment #8 from Steve Kargl --- On Thu, Jul 02, 2020 at 03:53:22PM +, jakub at gcc dot gnu.org wrote: > > --- Comment #7 from Jakub Jelinek --- > (In reply to kargl from comment #6) > > There is no -fno-allow-invalid-boz option. The option is > > -fallow-invalid-boz. fortan/lang.opt defines the options > > with the RejectNegative annotation. > > Why is it RejectNegative? Because there is nothing to negate. real :: x = z'1234' end is an invalid use of a BOZ. gfortran 10.1 will issue an error for this construct (and a number of previously documented and undocumented extensions). Unfortunately, older vesions of gfortran accepted the above without error or warning. When I fixed gfortran's handling of BOZ to conform to the Fortran 2008/2018 standard (i.e., emit an error for the above code), I introduced -fallow-invalid-boz to down-grade the error to a warning, so that older codes will compile. gfortran -c a.f90<-- error gfortran -c -fallow-invalid-boz a.f90<-- warning gfortran -c -fallow-invalid-boz -fno-allow-invalid-boz a.f90 <-- stupidity > Is there some other option that acts as it negative option? IMO, there is nothing to negative. If you don't want the option, then don't use it. > If it is just a standalone boolean option, it should have a negative, > so that if e.g. one uses -fallow-invalid-boz in $FFLAGS for most of > files in some project, but there is a specific one that shouldn't > allow it, one can just append -fno-allow-invalid-boz for it to cancel > the earlier option. This makes no sense to me. gfortran will accept valid uses of a BOZ without any option. If you add -fallow-invalid-boz to $FFLAGS, then you're simply accepting invalid Fortran (with a warning) in addition to valid Fortran. If a programmer is adding a new file to a project and $FFLAGS includes -fallow-invalid-boz, then programmer will get a warning about invalid code instead of an error. The programmer is informed about the issue, and can make the necessary change, e.g., real :: x = real(z'1234', 4) end in the new file. The point of the option is to allow backwards compatibility, but to be verbose about the invalid Fortran; hopefully, to encourage the programmer to fix their code.
[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033 --- Comment #6 from Steve Kargl --- On Thu, Jul 02, 2020 at 04:10:38PM +, skorzennik at cfa dot harvard.edu wrote: > > GCC is the single one that decides that old code is trash and needs to be > rewritten. When 64b was introduced, gfortran decided that the UNIX record > integer embedded in the binary files ought to be 64b, making it impossible to > use existing binary files. That's simply shooting yourself in the foot. > That problem was recognized and fixed long ago. See the -frecord-marker and -fmax-subrecord-length options. > As for a specific URL: https://www.cfa.harvard.edu/~avrett/pandora/, the > PANDORA radiative transfer code is made up of 4,559 routines. Thanks for the URL. If the code is freely downloadable, I'll grab it and check out what gfortran does. > It was not well > designed, but it was started in 1959, with computers and compilers that had > many limitations, yet I can build it w/ Intel's and PGI's F77 compilers. It > needed minor one or two tweaks for runtime errors when moved from VMS to > Linux. > > Yet by writing > parameter (MSHLNG=50) > integer MSHCNO,MSHLNG > dimension MSHCLR(MSHLNG) > data MSHCLR,MSHCNO /MSHLNG*' ', 0/ > gfortran imposes a rule that did not exist -or wasn't enforced- back when: the > integer declaration must be before the parameter one. The developer used > VAX/VMS tools and saw no reasons to code differently (GNU did not exists). > > PGI and Intel do accept this order. > There can be bugs in the compiler. Unreported bugs tend to go unfixed. Ufortunately, there are more bugs than volunteers to fix them.
[Bug fortran/52279] Fortran translation issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279 --- Comment #10 from Steve Kargl --- On Thu, Jul 02, 2020 at 05:10:51PM +, sch...@linux-m68k.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279 > > --- Comment #9 from Andreas Schwab --- > That means you cannot override a default. > Huh? By default you get an error. The option down-grades the error to a warning. If you don't want the warning, then don't use the option. You'll get the error.
[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033 --- Comment #8 from Steve Kargl --- On Thu, Jul 02, 2020 at 05:31:21PM +, skorzennik at cfa dot harvard.edu wrote: > > I gave up on gfortran when the 64b record marker made it unusable for me. I'm > not surprised it was fixed, but this pointed to poor decision making and > ignoring the need to backward compatibility. When you don't need to sell your > product, your "customers" needs might not be your highest priority. It's a very small group of volunteers who hack on gfortran. No one is paid to do it (except for perhaps the OpenMP and OpenACC extensions). It has been a hobby for me. I fix bugs that affect my own codes and then address bugs reported by others as time permits. If Fortran were a more popular language, then things may be different. > Backward compatibility is a wide spread problem, in commercial products > (trust me, some have hear mn more than once) and in 'free' ones (the > Python 2.x vs 3.x debacle comes to mind). When you've been at it for 3 > decades, it matters. gfortran supports a large number of extension. I know as I either implemented the extension (e.g., real do-loop indices and nonstandard intrinsic subprograms) or sheparded the extension into the tree (Cray pointers and DEC structure/union/map). Unfortunately, extensions make it more difficult to maintain and add the new language features in the Fortran standards. > PANDORA can be downloaded, and it is ugly coding (I know the author, > he retired a while back and I was for a while helping maintain the > code), but it may be a good example why you can't easily all a sudden > switch to new rules, and why we maintain multiple versions of multiple > compilers. It isn't a matter of simply switching rules. It's a matter of bugs and whether the bug is reported. In the small snippet you posted, there is clearly a problem with implicit typing and parameter statements. This compiles function jfoo() parameter (MSHLNG=50) jfoo = mshlng end and this doesn't function ifoo() parameter (MSHLNG=50) integer MSHLNG ifoo = mshlng end % gfcx -c a.f a.f:3:22: 3 | integer MSHLNG |1 Error: PARAMETER at (1) is missing an initializer The Fortran standard has If a named constant is defined by a PARAMETER statement, it shall not be subsequently declared to have a type or type parameter value that differs from the type and type parameters it would have if declared implicitly (8.7). What is puzzling is that the 'parameter (mshlng=50)' is correctly parsed. The declaration statement is incorrectly parsed, but I don't know why, yet.
[Bug fortran/52279] Fortran translation issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279 --- Comment #12 from Steve Kargl --- On Thu, Jul 02, 2020 at 05:24:36PM +, sch...@linux-m68k.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279 > > --- Comment #11 from Andreas Schwab --- > If it was enabled by default, you cannot negate it. > I have no idea what you're writing about, or if you're addressing me or jakub. All I can do is explain what gfortran does, and the intended designed behavior of the -fallow-invalid-boz option. The negation of the option is to not specify it among your options.
[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033
--- Comment #9 from Steve Kargl ---
On Thu, Jul 02, 2020 at 06:30:40PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> It isn't a matter of simply switching rules. It's a matter of bugs
> and whether the bug is reported. In the small snippet you posted,
> there is clearly a problem with implicit typing and parameter statements.
> This compiles
>
> function jfoo()
> parameter (MSHLNG=50)
> jfoo = mshlng
> end
>
> and this doesn't
>
> function ifoo()
> parameter (MSHLNG=50)
> integer MSHLNG
> ifoo = mshlng
> end
>
> % gfcx -c a.f
> a.f:3:22:
>
> 3 | integer MSHLNG
> |1
> Error: PARAMETER at (1) is missing an initializer
>
> The Fortran standard has
>
> If a named constant is defined by a PARAMETER statement, it shall
> not be subsequently declared to have a type or type parameter value
> that differs from the type and type parameters it would have if
> declared implicitly (8.7).
>
> What is puzzling is that the 'parameter (mshlng=50)' is
> correctly parsed. The declaration statement is incorrectly
> parsed, but I don't know why, yet.
>
When bugs are reported, they sometime get fixed.
(Copy-n-paste tab corruption in patch)
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -1864,13 +1864,16 @@ add_init_expr_to_sym (const char *name, gfc_expr **ini
/* If this symbol is confirming an implicit parameter type,
then an initialization expression is not allowed. */
- if (attr.flavor == FL_PARAMETER
- && sym->value != NULL
- && *initp != NULL)
+ if (attr.flavor == FL_PARAMETER && sym->value != NULL)
{
- gfc_error ("Initializer not allowed for PARAMETER %qs at %C",
- sym->name);
- return false;
+ if (*initp != NULL)
+ {
+ gfc_error ("Initializer not allowed for PARAMETER %qs at %C",
+ sym->name);
+ return false;
+ }
+ else
+ return true;
}
if (init == NULL)
[Bug fortran/96024] [9/10/11 Regression] ICE in mio_name_expr_t, at fortran/module.c:2159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024 --- Comment #4 from Steve Kargl --- On Sat, Jul 04, 2020 at 09:29:49AM +, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024 > > --- Comment #3 from Dominique d'Humieres --- > > The patch in PR 95025 fixes this issue. > > The patch fixes the ICE, but I get the cryptic error > > f951: Fatal Error: Writing module 'm' at line 15 column 14: Bad type in > constant expression > compilation terminated. > gfc_fatal_error() is used 17 times in module.c. This normally means that gfortran's error handling mechanism is not available at the time the error occrurred. It also be that in this case, the *.mod file and the namespace is too corrupted to try to continue.
[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980 --- Comment #9 from Steve Kargl --- On Mon, Jul 06, 2020 at 08:29:24PM +, anlauf at gcc dot gnu.org wrote: > I have the impression that there's a lot of bad things happening with > invalid input that is not always caught on x86_64. This has been true since I started working on gfortran some 15+ years ago. Much of the code is written assuming a correctly written Fortran program. Invalid input, particularly corner cases and with newer features, tend to blow up. Gerhard seems to delight in finding these issues. :-)
[Bug fortran/96158] Debug symbols not emitted for module common variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158 --- Comment #6 from Steve Kargl --- On Mon, Jul 13, 2020 at 12:23:58PM +, amelvill at umich dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158 > > --- Comment #4 from AJM --- > >> I won't comment on the questionable programming idiom of placing > >> a common block in a module, which kind of defeats the niceties of > >> a module. > > If somebody wants to transition your code from using common blocks to > > modules, that is a good way to proceed. When all the direct usage > > of the common block have been removed, you can then remove the > > COMMON statement from the module. > > This is the case, more or less. I didn't write the code that did this. > > I would be quite happy to see the common blocks get moved to a module, > but to make things a bit more dangerous on that side, these variables > are bound to a C variable. Do you mean the variable is declared with BIND(C)? If so, you should be getting an error.
[Bug fortran/96158] Debug symbols not emitted for module common variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158 --- Comment #7 from Steve Kargl --- On Mon, Jul 13, 2020 at 01:42:29PM +, amelvill at umich dot edu wrote: > > As far as workarounds go, if it came to that I'd rather just make a dummy > "debug" function that stored these common variables as a local variable. > That would be the path of least trouble, is what my subroutine boo is. A quick scan of the DWARF5 standard does not show a DW_TAG that applies to a variable declared in a module.
[Bug fortran/96158] Debug symbols not emitted for module common variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158 --- Comment #9 from Steve Kargl --- On Mon, Jul 13, 2020 at 03:44:13PM +, amelvill at umich dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158 > > --- Comment #8 from AJM --- > > > >> I won't comment on the questionable programming idiom of placing > > > >> a common block in a module, which kind of defeats the niceties of > > > >> a module. > > > > If somebody wants to transition your code from using common blocks to > > > > modules, that is a good way to proceed. When all the direct usage > > > > of the common block have been removed, you can then remove the > > > > COMMON statement from the module. > > > > > > This is the case, more or less. I didn't write the code that did this. > > > > > > I would be quite happy to see the common blocks get moved to a module, > > > but to make things a bit more dangerous on that side, these variables > > > are bound to a C variable. > > Do you mean the variable is declared with BIND(C)? > > If so, you should be getting an error. > > The bind statement would look like this, directly under the "common" > statement, > inside somemodule.f90: > > module somemodule > > integer*8moduleVar !then many more variables > > common /othermodule/ moduleVar !then many more variables > bind(C, name="othermodule") :: /othermodule/ > > end module > > The program, with the bind statement added, compiles without errors. Ah, I misunderstood what you wrote. I thought you meant you had instances of something like integer*8, bind(c) :: modulevar common /othermodule/ moduleVar in the module. That's invalid, and gfortran must issue an error as it is a numbered constraint. I'll need to go look at the Fortran standard about bind(c) and named common blocks. > If you really need to know, on the C side there is a struct with fields that > match the order and size of the variables in the common statement / module > declaration. I am almost certain that this is not the "right way" to do this, > and that there is some UB there in struct packing and compiler decisions on > the > size of the variables (neither the C side nor the fortran side has packing > pragmas, and worse, the C side uses compiler defined integer types like > "int"). > Without a doubt this is not an ideal setup, a rewrite is probably in order to > ensure portability. We don't have the time resources for that rewrite right > now, though (and that's not my call, either). Oh. That does look error prone. The correct way, if you're working on improvements to the code, would be to use a derived type on the Fortran side that matches a struct on the C side. I would need check on whether you need to use a SEQUENCEd derived type, and what other restrictions apply (e.g., no allocatable components etc). > While I was making a minimal example I originally thought bind was the root > cause, but I eliminated it as the source of the problem (I found that I could > reproduce the issue with only common). I removed it to try and make the most > minimal example possible. Does the -fno-align-common option help you. The manual says '-falign-commons' By default, 'gfortran' enforces proper alignment of all variables in a 'COMMON' block by padding them as needed. On certain platforms this is mandatory, on others it increases performance. If a 'COMMON' block is not declared with consistent data types everywhere, this padding can cause trouble, and '-fno-align-commons' can be used to disable automatic alignment. The same form of this option should be used for all files that share a 'COMMON' block. To avoid potential alignment issues in 'COMMON' blocks, it is recommended to order objects from largest to smallest. Trying to match a named common block with memory alignment requirements with a C struct (which may have different alignment requirements) seems to the path to very hard to find bugs. > > A quick scan of the DWARF5 standard does not show > > a DW_TAG that applies to a variable declared in > > a module. > > Referring to the github repo quickly > https://github.com/amelvill-umich/Fortran_GDB_Common#with-that-line-commented-out > , with the common statement commented out, > > $ nm somemodule.o > B __somemodule_MOD_modulevar > Interesting. My guess would be that a common block is simply considered to be a chunk of memory under DWARF5. It provides a base address and one needs to know how to compute offsets into that chunk (including dealing with any padding).
[Bug fortran/85796] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796 --- Comment #4 from Steve Kargl --- On Sat, Jul 18, 2020 at 08:13:31PM +, jvdelisle at charter dot net wrote: > > --- Comment #3 from jvdelisle at charter dot net --- > This looks OK Steve. Assuming your regression tested, shall I commit this for > you? > My regression test shows 22 regression, but none can be associated with this patch. There are lto errors about linking, which likely means gfortran is finding FreeBSD ld (rtld) instead of binutils. I'm also getting an odd failure with 'gmake -j7 chec-fortran' where a submake is dying with 'argument to -j must be positive'. Odd?
[Bug fortran/30372] various intrinsics do not diagnose invalid argument kinds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372 --- Comment #19 from Steve Kargl --- On Sun, Jul 19, 2020 at 02:42:24PM +, arjen.markus895 at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372 > > --- Comment #17 from Arjen Markus --- > As UMASK has two arguments, should it be possible to combine integer arguments > of different kinds? That is: > > integer(kind=1) :: mask > integer(kind=8) :: old > > call umask( mask, old ) > > (Probably a bit overdoing it, but I guess it should be documented either way) > Comment 12 makes UMASK a generic function. Comment 13 makes UMASK a generic subroutine. The patch for the generic subroutine UMASK converts MASK to integer(4) and, if present, OLD to integer(4). It then creates a call to _gfortran_umask_i4_sub. Note umask(2) takes a mode_t in C, which at least on FreeBSD is an unsigned int. So, in a sense it does not matter if the kind types differ for MASK and OLD. OTOH, the Fortran standard for most intrinsic routines require types to be the same. gfortran should probably have a check for the same type. Index: gcc/fortran/check.c === --- gcc/fortran/check.c (revision 280157) +++ gcc/fortran/check.c (working copy) @@ -7230,10 +7230,7 @@ gfc_check_umask_sub (gfc_expr *mask, gfc_expr *old) if (old == NULL) return true; - if (!scalar_check (old, 1)) -return false; - - if (!type_check (old, 1, BT_INTEGER)) + if (!same_type_check (mask, 0, old, 1, false)) return false; return true;
[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 --- Comment #6 from Steve Kargl --- On Tue, Jul 21, 2020 at 07:44:16PM +, jvdelisle at charter dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 > > --- Comment #5 from jvdelisle at charter dot net --- > (In reply to kargl from comment #2) > > This issue depends on the fix for FORALL. In gfc_match_do in the concurrent > > section, one gets to > > > > m = match_forall_header (&head, &mask); > > > > to match the control portion of the statement. > > Although we need to support forall, it is interesting that the standards > committe i going to deprecate it, if they have not done so already. Not > encouraged to be used for sure. Also they will be adding features to DO > CONCUURENT which look useful to me. > do current (JUNK HERE) forall (JUNK HERE) The JUNK HERE is parsed by the same code; namely, match_forall_header(). So, if one fixes do current, then one fixes forall. PS: J3 has an interesting discussion that suggests that do current is also broken.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #8 from Steve Kargl --- On Sun, Jul 26, 2020 at 09:35:56PM +, jvdelisle at charter dot net wrote: > > I my too simple terms, when you define the interface and then use > module procedure in the contains, all of the declarations in the > interface exist as if you had them in the declaration of the > subroutine or function in the contains. This includes all arguments > and whether or not the procedure is a subroutine or a function. > > I was not aware of this either untill I saw some other code > Damian was doing earlier this week that does actually compile > fine like this with gfortran. It is a modern feature and if you > think about it, very useful in that it saves a lot of typing. > One can choose do do it either way, but this way shown truly uses > the interface to define everything. > I have thought about it, and I have concluded it is rather curious programming paradigm, because ... module foo private public bar interface bar ! Make bar generic module subroutine bar1(x) real, intent(in) :: x end subroutine bar1 end interface integer x contains ! ! Several hundreds to several thousand lines of code may ! appear here, which separates dummy argument declarations ! from where the dummy arguments are used. ! module procedure bar1 print *, x end procedure bar1 end module foo Oh, and at least, this simply test program works with my 2nd patch. program bah use foo real y y = 42. call bar(y) end program bah Likely, yet another patch that will sit in bugzilla.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #17 from Steve Kargl --- On Tue, Jul 28, 2020 at 10:32:50AM +, dominiq at lps dot ens.fr wrote: > > What I guessed, but I still see (not new) > > /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90:18:32: > >18 | pure integer function lensum (words, sep) > |1 > Warning: Interface mismatch in global procedure 'lensum' at (1): Shape > mismatch > in argument 'words' > So, change the dg-error to "Interface mismatch in" from "Shape mismatch in". Clearly, Paul's patch detects an error earlier in the parsing than previously detected.
[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
--- Comment #13 from Steve Kargl ---
On Wed, Jul 29, 2020 at 02:54:59PM +, pault at gcc dot gnu.org wrote:
> --- Comment #12 from Paul Thomas ---
> (In reply to kargl from comment #10)
> > (In reply to jvdelisle from comment #9)
> > > I regression tested the patch in comment 8 and see these failures.
> > >
> > > FAIL: gfortran.dg/pr93423.f90 -O (test for excess errors)
> > > FAIL: gfortran.dg/typebound_call_31.f90 -O (test for errors, line 14)
> > > FAIL: gfortran.dg/typebound_call_31.f90 -O (test for excess errors)
> >
> > Thanks for testing. Does the patch that follows fix the regressions?
> > gfortran treats components and type bound procedures separately. I've
> > (hopefully) adapted the patch to whether foo is either.
> >
> > Index: gcc/fortran/primary.c
> > ===
> > --- gcc/fortran/primary.c (revision 280157)
> > +++ gcc/fortran/primary.c (working copy)
> > @@ -2240,6 +2240,18 @@ gfc_match_varspec (gfc_expr *primary, int
> > equiv_flag,
> > inquiry = is_inquiry_ref (name, &tmp);
> > if (inquiry)
> > sym = NULL;
> > + else
> > + {
> > + component = gfc_find_component (sym, name, false, false, &tmp);
> > + tbp = gfc_find_typebound_proc (sym, &t, name, false,
> > &gfc_current_locus);
> > + if (!component && !tbp)
> > + {
> > + gfc_error ("%qs at %C is neither a component nor a type "
> > +"bound procedure of the derived "
> > +"type %qs", name, sym->name);
> > + return MATCH_ERROR;
> > + }
> > + }
> >
> > if (sep == '%' && primary->ts.type != BT_UNKNOWN)
> > intrinsic = true;
>
> Hi Steve,
>
> Given your comment 6, I set too first thing this morning and
> located the bug by searching the ChangeLogs for candidates. That
> I was the culprit is galling to say the least of it.
Don't be too galled (is that a word?). You've contributed to so
many areas of the compiler and the Fortran language is only getting
more complicated!
For my patch, I noted that is_inquiry_ref tested for %re, %im,
%len, and %kind. As that returns false, the only thing that
%foo(i) can be is either a component (which happens to be an
array) or type-bound procedure.
> My version of the fix is:
>
> index d73898473df..6f032fbabfd 100644
> --- a/gcc/fortran/primary.c
> +++ b/gcc/fortran/primary.c
> @@ -2327,10 +2327,12 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag,
> bool sub_flag,
>else
> component = NULL;
>
> - /* In some cases, returning MATCH_NO gives a better error message. Most
> -cases return "Unclassifiable statement at..." */
>if (intrinsic && !inquiry)
> - return MATCH_NO;
> + {
> + gfc_error ("%qs at %C is not an inquiry reference to an "
> +"intrinsic type", name);
> + return MATCH_ERROR;
> + }
This works for me. Note, jerryd is in the process of committing
my patch as I do not use git (and currently no one is paying me
to learn git).
> > + gfc_error ("%qs at %C is not an inquiry reference to an "
> > +"intrinsic type", name);
>
> or some such.
I suppose the above error message works. The message I came up
with is due to the (i) in %foo(i). Is this a typo for an array
or TBP? Either way the error is now detected.
>
> Also, you have to get rid of the comment and the dead code that
> was modified in my patch.
>
> Thanks for the patch. OK for trunk when the error message is
> corrected and the comment plus dead code removed.
I do not know git. I do not use git for my personal projects,
so there is no incentive for me to waste my time learning what
has become a bane. I am stuck at svn r280157 (Jan 2020 or so).
AFAICT, from reading gcc mailing list arhives, the switch from
subversion to git was not publically discussed. All discussion
(from a very small group of people) makes it clear the conversion
was going to happen. It seems there was no consideration for
the negative impact the switch will have. But, then again,
gfortran is an after thought for most.
You'll find a bunch of patches attached to PRs, which need a
(hopefully new) gfortran committer to look:
mobile:kargl[204] ls pr*diff
pr30371.diffpr95586.diff
pr30371_umask.diff pr95612.diff
pr30371_umask_sub.diff pr95613.diff
pr30371_unlink_sub.diff pr95614.diff
pr69101.diffpr95647.diff
pr85796.diffpr95708.diff
pr93635.diffpr95709.diff
pr95038.diffpr95710.diff
pr95340.diffpr95829.diff
pr95342.diffpr95980.diff
pr95352.diffpr95981.diff
pr95372.diffpr96013.diff
pr95446.diffpr96025.diff
pr9
[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 --- Comment #15 from Steve Kargl --- Hi Paul, Not sure how the UK is handling the pandemic. Here, in Washington we have 4 phases. Phase 1 has the most restrictions and phase 4 is the pandemic is over. Most of Washington made it into phase 2 (ie., small gathering, restaurants, and stores opened with socialing distancing, etc). Then the 4th of July holiday weekend happened, and now, many places are back to phase 1 (ie., mandatory mask (which people seem to ignore), gatherings of 5 (or 10) people, etc). It is interesting how people mistake common sense for infringement of their civil liberties. Of course, the political leadership in the USA seems to be leading the pack with a lack common sense. Transitioning to working from home has been interesting. No small children to worry about. But, my son was taking graduate-level on-line courses on music composition for film and multimedia, my wife was on-line, and I'm trying to work. Bandwidth was an issue. Oh, I almost forgot. I could often watch 2 EPL matches a day. If you do look at one of my patches in a PR, feel free to ping me. I had posted a list of PRs to comp.lang.fortran trying to recruit new contributor. Arjen has taken a baby step, but we could use more eyes.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #22 from Steve Kargl --- On Mon, Aug 03, 2020 at 11:45:20PM +, damian at sourceryinstitute dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 > > --- Comment #21 from Damian Rouson --- > Now that the patch fixing this PR has been committed to the trunk, should it > be > marked as "Resolved" instead of "Assigned?" > Depends on if someone (whomever committed the patch) is going to backport it to 9 and 10 branch.
[Bug fortran/96486] get_environment_variable fails for zero-length values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #14 from Steve Kargl --- On Thu, Aug 06, 2020 at 08:03:29AM +, markeggleston at gcc dot gnu.org wrote: > (In reply to kargl from comment #6) > > I do note there are other problems with get_environment_variable. > > It looks to me that this intrinsic supports the Fortran 2003 > standard. Changes were introduced with the Fortran 2018 and > support has not yet been implemented. Yep > > > > 1) Neither length nor status can be integer(1). gfortran should issue > >an error. > > Fortran 2003 has default kind for these arguments. > As does F2008. > > > > 2) Fortran 2018 has added an optional errmsg argument. This is not > >supported. > > > > 3) gfortran is issuing errors that don't make sence (to me). > > > > program foo > >integer( 1) i01 > >integer( 2) i02 > >integer( 4) i04 > >integer( 8) i08 > > #ifdef __GFC_INT_16__ > >integer(16) i16 > > #endif > >character(len=20) name > > > >print '(A,I0)', 'range(i01) = ', range(i01) > >print '(A,I0)', 'range(i02) = ', range(i02) > >print '(A,I0)', 'range(i04) = ', range(i04) > >print '(A,I0)', 'range(i08) = ', range(i08) > > #ifdef __GFC_INT_16__ > >print '(A,I0)', 'range(i16) = ', range(i16) > > #endif > > > >name = '' > >! Although valid Fortran, this should probably raise a warning. > >call get_environment_variable(name); > > > >name = 'FOO' > >call get_environment_variable(name,length=i01); ! Should be an error > >call get_environment_variable(name,length=i02); ! Should be ok > >call get_environment_variable(name,length=i04); ! Should be ok > >call get_environment_variable(name,length=i08); ! Should be ok > > #ifdef __GFC_INT_16__ > >call get_environment_variable(name,length=i16); ! Should be ok > > #endif > > > > end program foo > > > > mobile:kargl[256] gfcx -o z a.F90 && ./z > > a.F90:29:45: > > > >29 |call get_environment_variable(name,length=i01); ! Should be an > > error > > | 1 > > Error: In call to 'get_environment_variable' at (1), type mismatch in > > argument length'; pass 'INTEGER(1)' to 'INTEGER(4)' > > a.F90:30:45: > > > >30 |call get_environment_variable(name,length=i02); > > | 1 > > Error: In call to 'get_environment_variable' at (1), type mismatch in > > argument length'; pass 'INTEGER(2)' to 'INTEGER(4)' > > a.F90:32:45: > > > >32 |call get_environment_variable(name,length=i08); > > | 1 > > Error: In call to 'get_environment_variable' at (1), type mismatch in > > argument length'; pass 'INTEGER(8)' to 'INTEGER(4)' > > The mismatch errors are consistent with Fortran 2003 support. > > I think these issues should be in a separate PR for Fortran 2018 support. > gfortran is using the default argument checking routine, which is based on the information from intrinsic.c. With f2018, making (almost?) everything generic, a gfc_check_environment_variable is needed. This then may allow some of the runtime checking to be removed.
[Bug fortran/96486] get_environment_variable fails for zero-length values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #15 from Steve Kargl --- On Thu, Aug 06, 2020 at 08:42:20AM +, jussilehtola at fedoraproject dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 > > --- Comment #13 from Susi Lehtola --- > The gdb output is the same > > (gdb) r > Starting program: /tmp/a.out > Fortran runtime error: Zero-length string passed as value to > get_environment_variable. > > Error termination. Backtrace: > #0 0x401267 in zerolen_value > at /tmp/readvar2.f90:17 > #1 0x4012c4 in main > at /tmp/readvar2.f90:22 > [Inferior 1 (process 122282) exited with code 02] > I cannot reproduce your error. Your original backtrace was Error termination. Backtrace: #0 0x7f25c93aadf1 in ??? #1 0x7f25c93ab939 in ??? #2 0x7f25c93abe60 in ??? #3 0x7f25c960ce53 in ??? #4 0x401267 in ??? #5 0x4012c4 in ??? #6 0x7f25c903a041 in __libc_start_main at ../csu/libc-start.c:308 #7 0x4010ad in ??? #8 0x in ??? I would expect a long backtrace under gdb. Don't know what [Inferior 1...] means.
[Bug fortran/96486] get_environment_variable fails for zero-length values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #17 from Steve Kargl --- On Thu, Aug 06, 2020 at 08:33:12PM +, jussilehtola at fedoraproject dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 > > --- Comment #16 from Susi Lehtola --- > Yes, then I installed missing libgfortran debuginfos and the backtrace > shortened to > > #0 0x401267 in zerolen_value > at /tmp/readvar2.f90:17 > #1 0x4012c4 in main > at /tmp/readvar2.f90:22 > I cannot reproduce the issue.
[Bug fortran/96486] get_environment_variable fails for zero-length values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #20 from Steve Kargl --- On Fri, Aug 07, 2020 at 01:14:04PM +, jussilehtola at fedoraproject dot org wrote: > > It already was reproduced in comment #9? > There is clearly a language barrier. At this point, I have no idea what you think the issue is, and I don't care. Good luck getting anyone else to look this bug report.
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #24 from Steve Kargl --- On Fri, Aug 07, 2020 at 08:35:49PM +, jussilehtola at fedoraproject dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 > > --- Comment #21 from Susi Lehtola --- > to repeat: libgfortran crashes when you try to read an environment variable > that is an empty string, in the case you have preallocated an array that is > the > proper size i.e. zero characters. to repeat: I cannot reproduce your issue. It does not crash. It exits with a runtime error. % setenv HOSTNAME % gfcx -o z b.f90 % ./z Fortran runtime error: Zero-length string passed as value to get_environment_variable. That's it. No crash.
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
--- Comment #26 from Steve Kargl ---
On Fri, Aug 07, 2020 at 09:55:06PM +, sch...@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
>
> --- Comment #25 from Andreas Schwab ---
> But why does it error out? It shouldn't!
>
You'll have to ask Paul Brook why he chose to issue an error.
% svn annotate libgfortran/intrinsic/env.c
...
85656 pbrook if (value != NULL)
85656 pbrook {
85656 pbrook if (value_len < 1)
85656 pbrook runtime_error ("Zero-length string passed as value to "
85656 pbrook "get_environment_variable.");
85656 pbrook else
85656 pbrook memset (value, ' ', value_len); /* Blank the string.
*/
85656 pbrook }
IIRC, r85656 is tree-ssa becoming pre-gcc 4.0.0.
[Bug fortran/96613] SIGFPE on min1() with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
--- Comment #6 from Steve Kargl ---
On Mon, Aug 17, 2020 at 06:03:31PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
>
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #4)
> > I thought that this might be a good candidate for frontend fix.
> > Similar to thomas's frontend optimizations except except the
> > transformation is always done. That is, we should be able to do
> > substitutions based on Table 16.3 before we even get to backend.
>
> If frontend optimization is preferred, I'll step out of the way.
>
> Nevertheless, one also need to address issues like:
>
> % cat maxmin.f90
> program p
> implicit none
> print *, min (2.0, 1.d0)
> print *, min (2.d0, 1.0)
> print *, kind (min (2.0, 1.d0))
> print *, kind (min (2.d0, 1.0))
> end program p
>
> % gfc-11 maxmin.f90 && ./a.out
>1.
>1.
>4
>8
>
> The only compiler I found having the same is PGI/NVIDIA.
>
> OTOH ifort (and similarly sunf95, g95(!)) result in the expected:
>
>1.00
>1.00
>8
>8
Personally, I would rather issue an error if types of the
arguments are not the same, but that ship sailed years ago.
To fix, the above, you'll need to look at iresolve.c
static void
gfc_resolve_minmax (const char *name, gfc_expr *f, gfc_actual_arglist *args)
{
gfc_actual_arglist *a;
f->ts.type = args->expr->ts.type;
f->ts.kind = args->expr->ts.kind;
and re-do the conversion stuff. AFAICT, type conversion is
not handled correctly. The largest kind is found regardless
of the type and this kind with the type of first argument is
used to to do conversion.
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #9 from Steve Kargl ---
On Wed, Aug 19, 2020 at 09:36:32PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
>
> --- Comment #8 from anlauf at gcc dot gnu.org ---
> A very quick hack seems to solve the issue for me. For some reason the
> final fold_convert seems to create a problem. Does anybody know why?
> It there a shorter solution?
>
> diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
> index 2483f016d8e..deb3030b75d 100644
> --- a/gcc/fortran/trans-intrinsic.c
> +++ b/gcc/fortran/trans-intrinsic.c
> @@ -395,11 +395,26 @@ build_round_expr (tree arg, tree restype)
> fn = builtin_decl_for_precision (BUILT_IN_LROUND, argprec);
>else if (resprec <= LONG_LONG_TYPE_SIZE)
> fn = builtin_decl_for_precision (BUILT_IN_LLROUND, argprec);
> + else if (resprec >= argprec && resprec == 128)
> +{
> + /* Search for a real kind suitable as temporary for conversion. */
> + int kind = -1;
> + for (int i = 0; kind < 0 && gfc_real_kinds[i].kind != 0; i++)
> + if (gfc_real_kinds[i].mode_precision >= resprec)
> + kind = gfc_real_kinds[i].kind;
> + if (kind < 0)
> + gfc_internal_error ("Could not find real kind with at least %d bits",
> + resprec);
> + arg = fold_convert (gfc_float128_type_node, arg);
> + fn = gfc_builtin_decl_for_float_kind (BUILT_IN_ROUND, kind);
> +}
>else
> gcc_unreachable ();
>
> - return fold_convert (restype, build_call_expr_loc (input_location,
> -fn, 1, arg));
> + return convert (restype, build_call_expr_loc (input_location,
> + fn, 1, arg));
> + /* return fold_convert (restype, build_call_expr_loc (input_location, */
> + /*fn, 1, arg)); */
> }
I tried an even uglier hack, and also got stumped by GIMPLE.
Jakub can probably shed some light on how to handle
quad precision and GIMPLE.
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 --- Comment #11 from Steve Kargl --- On Thu, Aug 20, 2020 at 01:47:58PM +, bre08 at eggen dot co.uk wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 > > --- Comment #10 from B Eggen --- > I've been experimenting with the suggested work-around > > m = anint(y) > > This works for larger numbers, even in quad precision, however, it breaks down > a long way before the integer*16 range is exhausted, consider the code below, > which starts with 2^113 and tries to double it, minus 1. The minus 1 is not > taking effect: > Of course, that is going to fail if you want an exact result. REAL(16) is a floating point format, which has 113 digits of precision. This means that integers less than 2**113 are exactly representable as REAL(16) floating point numbers. When you double (2._16)**113 to (2._16)**114, that is a prefectly fine REAL(16) floating point number. Subtracting 1._16 from (2._16)**114 is a valid floating point operation. Your problem lies in that result is rounded, and 1._16 is less than epsilon(1._16) in comparison to (2._16)**114. > I guess at some point NINT() will be fixed, can anyone suggest a robust > workaround that is valid until 2^127-1 ? If you're trying to use floating point arithmetic in computations and you need exact integral values up to 2**127-1, then there isn't a REAL type that works. If you're looking for arbitrary precision arithmetic and you want to use Fortran, I suggest that you google "David Bailey arithmetic".
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 --- Comment #13 from Steve Kargl --- On Thu, Aug 20, 2020 at 03:54:44PM +, bre08 at eggen dot co.uk wrote: > > PS (and maybe I need to post this separately as a suggestion) - will > there be a fast "octuple-precision floating point / integer" library > (i.e. 256 bit) for C, C++ and Fortran, or is using something like > GMP the only way forward ? I'm not aware of any effort to offer an octuple-precision library. If you need this level of accuracy, then you probably want to use David Bailey's libraries or GMP/MPFR.
[Bug fortran/95352] ICE on select rank with assumed-size selector and lbound intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352 --- Comment #5 from Steve Kargl --- On Thu, Aug 20, 2020 at 11:15:27PM +, jrfsousa at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352 > > --- Comment #4 from José Rui Faustino de Sousa --- > I have tested the patch posted by Steve Kargl and it seems to do the trick. > > Can I do anything to get this going? > I don't use git, so have way to move forward. If you want to package the patch and add the testcase, I would appreciate it.
[Bug fortran/95352] ICE on select rank with assumed-size selector and lbound intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352 --- Comment #7 from Steve Kargl --- On Fri, Aug 21, 2020 at 10:35:27AM +, jrfsousa at gmail dot com wrote: > Done! > > https://gcc.gnu.org/pipermail/fortran/2020-August/054908.html > > Thank you very much. > Thanks for submitting. If no one reviews the patch in the next day or so, I think you can commit it. BTW, for the git log and ChangeLog, I use ka...@gcc.gnu.org not my sgk@troutmask address.
[Bug fortran/96811] Power: x**(negative integer) – use libgcc variant for power raised to negative value?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96811 --- Comment #4 from Steve Kargl --- On Thu, Aug 27, 2020 at 04:57:14PM +, burnus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96811 > > --- Comment #3 from Tobias Burnus --- > (In reply to kargl from comment #2) > > For real x, gfortran does not generate a call to libgfortran function. > > It does – as mentioned in my email reply but not only for 'int' integers: Not sure what you mean by email reply, ... > > integer(16) :: n > real :: x, y > y = x**n > end > > calls: > y = _gfortran_pow_r4_i16 (D.3904, n); > Ah, yes. It seems integer(8) and integer(16) generate libgfortran calls. Somewhat surprising as x**n will underflow/overflow for rather small values of |n|. Worse case is for real(16) where |n| > |emin| + p will overflow for the smallest subnormal number (ie., |n| = 32768+113). Seems like gfortran could do if (|n| > magic number) if (n < 0) return (underflow to zero):(overflow to inf) return _builtin_powif(x, (integer 4) n)
[Bug fortran/96859] Wrong answer with intrinsic merge_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859 --- Comment #8 from Steve Kargl --- On Tue, Sep 01, 2020 at 12:52:49PM +, jakub at gcc dot gnu.org wrote: > > --- Comment #5 from Jakub Jelinek --- > I think this boils down to: > program foo > print *, int(o'1234567',2), int(o'1234567',4) > end program foo > I believe ifort prints > 14711 342391 > while gfortran prints > -18057 342391 > Since 01234567 in C is 0x53977, after that is cast to 16-bit integer that > should be 0x3977 and thus 14711. > The Fortran standard states how the BOZ string of bits is padded or truncated if it contains too few or too many bits. See F2018, 16.3.3. Also no that the handling of the sign bit is processor dependent. -- Steve
[Bug fortran/96859] Wrong answer with intrinsic merge_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859
--- Comment #10 from Steve Kargl ---
On Tue, Sep 01, 2020 at 03:20:20PM +, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859
>
> --- Comment #9 from Jakub Jelinek ---
> I've read that. But I think in this case it is an obvious bug (just, what
> I've
> missed in the patch, there is another copy of the same bug in another
> routine).
> The
> /* Clear first bit. */
> if (kind == 1 || kind == 4 || kind == 16)
> {
> if (buf[0] == '4')
> buf[0] = '0';
> else if (buf[0] == '5')
> buf[0] = '1';
> else if (buf[0] == '6')
> buf[0] = '2';
> else if (buf[0] == '7')
> buf[0] = '3';
> }
> part looks correct, for kind 1, 4 and 16 the calculated len times 3 is 1
> larger
> than the number of bits it needs, so the above ensures that the first digit is
> 0-3 even if it is 4-7 by subtracting 4.
> But the:
> /* Clear first two bits. */
> else
> {
> if (buf[0] == '4' || buf[0] == '6')
> buf[0] = '0';
> else if (buf[0] == '5' || buf[0] == '7')
> buf[0] = '1';
> }
> which is needed for kind 2 and 8, when he calculated len times 3 is 2 larger
> than the number of bits it needs, is only correct for digits 0-1 an 4-7, for
> which it ensures the digit is 0 if it is even and 1 if it is odd. But 2 and 3
> are kept as is, while they don't fit into 1 bit.
>
It is certainly possible I have/had an off-by-one in handwritten
conversions I was doing; in particular, I don't often work with
octal numbers.
[Bug libfortran/96890] Wrong answer with intrinsic IALL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96890 --- Comment #4 from Steve Kargl --- On Thu, Sep 03, 2020 at 02:32:32PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96890 > > --- Comment #3 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #2) > > At one point, you did it by using --maintainer-mode with configure. > > With the move to git and other changes, I don't know if this has > > changed. > > Well, --enable-maintainer-mode exists, but then I hit for libgomp: > Yes, that's the option. > WARNING: 'aclocal-1.16' is missing on your system. > > % aclocal --version > aclocal (GNU automake) 1.15.1 Yep. This is a pain of --enable-maintainer-mode, it runs the autotools over the src hierarchy. There is supposedly another way to regenerate the libgfortran source from the m4 files, but I cannot remember it. > > Giving up for someone else to take it up. > Ping Thomas. I recall seeing that he recently was asking about --enable-maintainer-mode in a git world.
[Bug fortran/97031] the content of a comment line breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031 --- Comment #3 from Steve Kargl --- On Sun, Sep 13, 2020 at 08:02:01AM +, jean-pierre.flam...@univ-lille.fr wrote: > > I just noticed that cpp recognizes the extensions .fpp .F and other uppercase > extensions. > This is why I added -cpp in the gfortran command (otherwise I have a > diagnostic > because of #ifdef's > > I have renamed my file with the .fpp extension; with "-cpp" in the gfortran > submission I get the same errors. > > If I compile the file with extension *.f or .fpp without -cpp > > 1) the compilation has no error > 2) a #ifdef...#endif is recognized even with a .f extension, without -cpp, in > my simple example, (I should check that the directive really is taken into > account !) > 3) IF I compile my full project in a makefile, the absence of "-cpp" in the > gfortran command induces > a "Illegal preprocessor directive" error in all the routines having that > #ifdef...#endif > I don't quite follow you. But, it come down to gfortran uses the C pre-processor when asked to pre-process a file. If you have a C language construct such as '/*' in your Fortran code it will cause problems.
[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046
--- Comment #3 from Steve Kargl ---
On Mon, Sep 14, 2020 at 11:56:18PM +, gilles.gouaillardet at gmail dot com
wrote:
> This is the libc subroutine
>
> void sync(void);
>
> The point here is any subroutine (that will not cause a crash) can be used to
> evidence the issue.
>
Isn't there a mismatch in the number of
arguments provided by your Fortran code
and the parameters expected in sync(2)?
dummy (struct array15_unknown & restrict x0)
{
{
void * cfi.0;
x0->span = (integer(kind=4)) x0->dtype.elem_len;
x0->dtype.attribute = 2;
cfi.0 = 0B;
_gfortran_gfc_desc_to_cfi_desc (&cfi.0, (struct array15_unknown *) x0);
x0->dtype.attribute = 2;
dummyc (cfi.0);
_gfortran_cfi_desc_to_gfc_desc ((struct array15_unknown *) x0, &cfi.0);
__builtin_free (cfi.0);
}
}
dummyc(cfi.0) becomes sync(cfi.0).
Is this standard conform?
[Bug fortran/92174] runtime error: index 15 out of bounds for type 'gfc_expr *[15]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 --- Comment #3 from Steve Kargl --- On Tue, Oct 22, 2019 at 02:14:55PM +, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 > > --- Comment #2 from Martin Liška --- > (In reply to kargl from comment #1) > > (In reply to Martin Liška from comment #0) > > > Happens with UBSAN build in: > > > > > > $ ./xgcc -B. > > > /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/pr91802.f90 > > > -fcoarray=single > > > ../../gcc/fortran/array.c:867:36: runtime error: index 15 out of bounds > > > for > > > type 'gfc_expr *[15]' > > > > > > What are you doing? pr91802.f90 is a compile time test. > > It cannot generate a runtime error. > > It's a runtime error of the GCC compiler that compiles the test-case ;) > The error message is a bit misleading. > So, what does your tool do? gfortran correctly diagnosis that rank+corank > 15, issues an error, and exits. What is the problem?
[Bug fortran/92174] runtime error: index 15 out of bounds for type 'gfc_expr *[15]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 --- Comment #6 from Steve Kargl --- On Tue, Oct 22, 2019 at 02:56:01PM +, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174 > > --- Comment #5 from Martin Liška --- > > Problem is that the compiler invokes an undefined behaviour for the source > file. > > More precisely, it's an out of bounds array access. > Which is irrelevant as the gfortran diagnosis the issue, issues an error meesage, and exits.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #3 from Steve Kargl --- On Tue, Oct 22, 2019 at 07:32:59PM +, kargl at gcc dot gnu.org wrote: > > The effect of the intent(out) in assign is to deallocate the code on entry to > assign. This is done with the if-block. The side-effect of evaluating the > first dummy argument is that 'a' in the expression of the 2nd dummy argument > is > undefined. > > F2018 (well 18-007r1) page 308: > >If a dummy argument has INTENT (OUT) or INTENT (INOUT), the actual >argument shall be definable. If a dummy argument has INTENT (OUT) >and its associated actual argument is allocated, the actual argument >is deallocated on procedure invocation (9.7.3.2). > > then later > >15.5.2.13 Restrictions on entities associated with dummy arguments > >While an entity is associated with a dummy argument, the following >restrictions hold. > >(1) Action that affects the allocation status of the entity or a >subobject thereof shall be taken through the dummy argument. > >(2) If the allocation status of the entity or a subobject thereof >is affected through the dummy argument, then at any time during >the invocation and execution of the procedure, either before or >after the allocation or deallocation, it shall be referenced only >through the dummy argument. > > It seems that code is non-conforming. > Seems to be some wiggle room. 15.5.4 Subroutine reference A subroutine is invoked by execution of a CALL statement, ... When a subroutine is invoked, all actual argument expressions are evaluated, then the arguments are associated, and then the subroutine is executed. So, it comes down to when the deallocation occur? P. 308 says the deallocation occurs when the procedure is invoked. But, 15.5.4 defines the sequence of events that occur when it procedure is invoked. Is the reference to the subroutine name the initiation of invocation? No where does it say when the deallocation occurs.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #5 from Steve Kargl ---
On Tue, Oct 22, 2019 at 09:03:42PM +, vladimir.fuka at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
>
> --- Comment #4 from Vladimir Fuka ---
> It would be really strange if even expressions like below were not possible.
>
> implicit none
> integer, allocatable :: a(:)
> allocate(a, source=[1])
> call assign(a, (min(a(1)**2,0)))
> print *, allocated(a)
> contains
> subroutine assign(a, i)
> integer, allocatable, intent(out) :: a(:)
> integer, value :: i
> print *, i
> end subroutine
> end program
Yep. I agree. In fact, if you reverse the arguments, like,
implicit none
integer, allocatable :: a(:)
allocate(a, source=[1])
call assign((min(a(1)**2,0)), a)
print *, allocated(a)
contains
subroutine assign(i, a)
integer, allocatable, intent(out) :: a(:)
integer, value :: i
print *, i
end subroutine
end
gfortran gives
% gfcx -o z a.f90 && ./z
0
F
Cutting the -ftree-dump-original down to the 'call' statement
gives
MAIN__ ()
{
{
integer(kind=4) D.3955;
integer(kind=4) D.3956;
integer(kind=4) M.7;
D.3955 = (*(integer(kind=4)[0:] * restrict) a.data)[a.offset + 1];
D.3956 = D.3955 * D.3955;
M.7 = D.3956;
M.7 = MIN_EXPR ;
if ((integer(kind=4)[0:] * restrict) a.data != 0B)
{
__builtin_free ((void *) a.data);
(integer(kind=4)[0:] * restrict) a.data = 0B;
}
assign (M.7, &a);
}
}
which shows the argument evaluation is done correctly. In short,
gfortran needs to scan the effective and dummy arguments for a
deallocation and just do the right thing.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #6 from Steve Kargl ---
On Tue, Oct 22, 2019 at 09:30:14PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> Cutting the -ftree-dump-original down to the 'call' statement
> gives
>
> MAIN__ ()
> {
> {
> integer(kind=4) D.3955;
> integer(kind=4) D.3956;
> integer(kind=4) M.7;
>
> D.3955 = (*(integer(kind=4)[0:] * restrict) a.data)[a.offset + 1];
> D.3956 = D.3955 * D.3955;
> M.7 = D.3956;
> M.7 = MIN_EXPR ;
> if ((integer(kind=4)[0:] * restrict) a.data != 0B)
> {
> __builtin_free ((void *) a.data);
> (integer(kind=4)[0:] * restrict) a.data = 0B;
> }
> assign (M.7, &a);
> }
> }
>
> which shows the argument evaluation is done correctly. In short,
> gfortran needs to scan the effective and dummy arguments for a
> deallocation and just do the right thing.
>
The evaluation of arguments seems to be done in trans-expr.c
gfc_conv_procedure_call(), where the argument list is simply
walked and evaluated. That's not good as this pr shows. :(
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #7 from Steve Kargl ---
On Tue, Oct 22, 2019 at 10:22:42PM +, sgk at troutmask dot
apl.washington.edu wrote:
> --- Comment #6 from Steve Kargl ---
> On Tue, Oct 22, 2019 at 09:30:14PM +0000, sgk at troutmask dot
> apl.washington.edu wrote:
> >
> > Cutting the -ftree-dump-original down to the 'call' statement
> > gives
> >
> > MAIN__ ()
> > {
> > {
> > integer(kind=4) D.3955;
> > integer(kind=4) D.3956;
> > integer(kind=4) M.7;
> >
> > D.3955 = (*(integer(kind=4)[0:] * restrict) a.data)[a.offset + 1];
> > D.3956 = D.3955 * D.3955;
> > M.7 = D.3956;
> > M.7 = MIN_EXPR ;
> > if ((integer(kind=4)[0:] * restrict) a.data != 0B)
> > {
> > __builtin_free ((void *) a.data);
> > (integer(kind=4)[0:] * restrict) a.data = 0B;
> > }
> > assign (M.7, &a);
> > }
> > }
> >
> > which shows the argument evaluation is done correctly. In short,
> > gfortran needs to scan the effective and dummy arguments for a
> > deallocation and just do the right thing.
> >
>
> The evaluation of arguments seems to be done in trans-expr.c
> gfc_conv_procedure_call(), where the argument list is simply
> walked and evaluated. That's not good as this pr shows. :(
>
There is a massive for-loop (lines: 5478-6638) that is used
for the evaluation of arguments. Within those lines, the
blocks 5924-5981, 6071-6111, and 6242-6273 are used to
delete allocated actual args for intent(out) dummy args.
I suspect that those blocks need to be removed, and second
following for-loop should scan the arg list to do the
deallocations.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #10 from Steve Kargl --- On Thu, Oct 24, 2019 at 05:09:55AM +, mscfd at gmx dot net wrote: > > --- Comment #9 from martin --- > Is this possibly related to bug 87142? > Certainly appears that way. If I add a 'print *, ">"//trim(str%cs)//"<" to the end of the program, when I compile and run it, the result is >0123456789<
