[patch, libgfortran] PR99210 X editing for reading file with encoding='utf-8'
The attached patch fixes the X editing.
Fairly self explanatory. I created the patch a few years back.
Regression tested on x86_64 and new test case.
OK for trunk?
Regards,
Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr99210.f90 b/gcc/testsuite/gfortran.dg/pr99210.f90
new file mode 100644
index 000..9fd2fb468df
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr99210.f90
@@ -0,0 +1,29 @@
+! { dg-do run }
+! PR99210 X editing for reading file with encoding='utf-8'
+program test_bug_format_x
+ use iso_fortran_env
+ integer, parameter :: u = selected_char_kind('ISO_10646')
+
+ character(kind=u, len=1) a, b, a1, b1, b2
+
+ open(unit=10, file='test_bug_format_x.tmp', encoding='UTF-8')
+
+ a = char(int(z'03B1'), u)
+ b = char(int(z'03B2'), u)
+ write(10, '(a1, a1)') a, b
+
+ rewind(10)
+ read(10, '(a1, a1)') a1, b1
+
+ rewind(10)
+ read(10, '(1x, a1)') b2
+
+ close (10, status="delete")
+ if(a /= a1 .or. b /= b1) then
+error stop 1
+ end if
+
+ if(b /= b2) then
+error stop 2
+ end if
+end program test_bug_format_x
diff --git a/libgfortran/io/read.c b/libgfortran/io/read.c
index 0ffcf76fd38..e2d2f8be806 100644
--- a/libgfortran/io/read.c
+++ b/libgfortran/io/read.c
@@ -1307,6 +1307,23 @@ read_x (st_parameter_dt *dtp, size_t n)
if (n == 0)
return;
+
+ if (dtp->u.p.current_unit->flags.encoding == ENCODING_UTF8)
+{
+ gfc_char4_t c;
+ size_t nbytes, j;
+
+ /* Proceed with decoding one character at a time. */
+ for (j = 0; j < n; j++)
+ {
+ c = read_utf8 (dtp, );
+
+ /* Check for a short read and if so, break out. */
+ if (nbytes == 0 || c == (gfc_char4_t)0)
+ break;
+ }
+ return;
+}
length = n;
[PATCHES, Committed] As obvious
Committed as obvious: commit 061b13ed014ba0b6891800a5c7f852bf58e4d856 Author: Jerry DeLisle Date: Thu Feb 16 18:13:56 2023 -0800 Fortran Tests: Allow passing on mingw. gcc/testsuite/ChangeLog: * gfortran.dg/bind_c_array_params_2.f90: Add *-*-ming* to dg-final. and commit f978585c2939691176ad8d3fa9c2e4e91ed18bf4 (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Thu Feb 16 19:29:44 2023 -0800 Fortran test: Modify test cases to pass on mingw. gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_14.f90: Change example function to CLOCK which is available on mingw as well as other platforms. * gfortran.dg/pr96486.f90: Change variable to PATH likewise.
[patch, fortran] PR103506 [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c
Attached patch fixes this problem by allowing the namespace pointer to
be set correctly regardless of error condition.
Regression tested on x86_64_linux_gnu.
OK for trunk and backports?
Regards,
Jerry
Author: Jerry DeLisle
Date: Sat Jan 28 20:00:34 2023 -0800
ICE in gfc_free_namespace. ice-on-invalid.
PR fortran/103506
gcc/fortran/ChangeLog:
* parse.cc (parse_module): Remove use of a bool error value
that prevented proper setting of the namespace pointer.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr103506_1.f90: New test.diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 0fb19cc9f0f..039e7e7da53 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -6502,7 +6502,6 @@ parse_module (void)
{
gfc_statement st;
gfc_gsymbol *s;
- bool error;
s = gfc_get_gsymbol (gfc_new_block->name, false);
if (s->defined || (s->type != GSYM_UNKNOWN && s->type != GSYM_MODULE))
@@ -6525,7 +6524,6 @@ parse_module (void)
st = parse_spec (ST_NONE);
- error = false;
loop:
switch (st)
{
@@ -6544,16 +6542,11 @@ loop:
default:
gfc_error ("Unexpected %s statement in MODULE at %C",
gfc_ascii_statement (st));
-
- error = true;
reject_statement ();
st = next_statement ();
goto loop;
}
-
- /* Make sure not to free the namespace twice on error. */
- if (!error)
-s->ns = gfc_current_ns;
+ s->ns = gfc_current_ns;
}
diff --git a/gcc/testsuite/gfortran.dg/pr103506_1.f90 b/gcc/testsuite/gfortran.dg/pr103506_1.f90
new file mode 100644
index 000..3f57809e099
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103506_1.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR103506 ICE in gfc_free_namespace. ice-on-invalid
+! Test case from the PR.
+module m ! { dg-error "is already being used as a MODULE" }
+stop ! { dg-error "Unexpected STOP statement in MODULE" }
+end
+program p
+call m ! { dg-error "is already being used as a MODULE" }
+end
[patch, gfortran.dg] Allow test to pass on mingw
Hi all,
Similar to a patch I committed a while ago for Cygwin, the attached
patch allows it to pass on the mingw version of gfortran.
It is trivial.
Ok for trunk?
Regards,
Jerrydiff --git a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
index 8dd7e8fb088..04faa433435 100644
--- a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
+++ b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
@@ -16,9 +16,9 @@ integer :: aa(4,4)
call test(aa)
end
-! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { ! { hppa*-*-* s390*-*-* *-*-cygwin* amdgcn*-*-* powerpc-ibm-aix*} } } } }
+! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { ! { hppa*-*-* s390*-*-* *-*-cygwin* amdgcn*-*-* powerpc-ibm-aix* *-*-ming* } } } } }
! { dg-final { scan-assembler-times "myBindC,%r2" 1 { target { hppa*-*-* } } } }
-! { dg-final { scan-assembler-times "call\tmyBindC" 1 { target { *-*-cygwin* } } } }
+! { dg-final { scan-assembler-times "call\tmyBindC" 1 { target { *-*-cygwin* *-*-ming* } } } }
! { dg-final { scan-assembler-times "brasl\t%r\[0-9\]*,myBindC" 1 { target { s390*-*-* } } } }
! { dg-final { scan-assembler-times "bl \.myBindC" 1 { target { powerpc-ibm-aix* } } } }
! { dg-final { scan-assembler-times "add_u32\t\[sv\]\[0-9\]*, \[sv\]\[0-9\]*, myBindC@rel32@lo" 1 { target { amdgcn*-*-* } } } }
[patch, fortran] ICE in attr_decl1, at fortran/decl.c:8691
The attached patch was provided by Steve Kargl. After exploring for
possible other checks I settled on leaving the patch intact.
Two existing test cases updated as different but sensible error messages
resulted.
Regression tested on main line.
OK to commit?
Regards,
Jerry
Author: Steve Kargl
Date: Mon Dec 26 14:07:04 2022 -0800
Modify checks to avoid referencing NULL pointer.
Update test cases with error messages that changed as a result.
gcc/fortran/ChangeLog:
* decl.cc (attr_decl1): Guard against NULL pointer.
* parse.cc (match_deferred_characteristics): Include
BT_CLASS in check for
derived being undefined.
gcc/testsuite/ChangeLog:
* gfortran.dg/class_result_4.f90: Update error message check.
* gfortran.dg/pr85779_3.f90: Update error message check.diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index e593518a77e..bac7b6568b0 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -8743,7 +8743,9 @@ attr_decl1 (void)
/* Update symbol table. DIMENSION attribute is set in
gfc_set_array_spec(). For CLASS variables, this must be applied
to the first component, or '_data' field. */
- if (sym->ts.type == BT_CLASS && sym->ts.u.derived->attr.is_class)
+ if (sym->ts.type == BT_CLASS
+ && sym->ts.u.derived
+ && sym->ts.u.derived->attr.is_class)
{
/* gfc_set_array_spec sets sym->attr not CLASS_DATA(sym)->attr. Check
for duplicate attribute here. */
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index bc2b2188eea..6186c48aee2 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -3934,7 +3934,7 @@ match_deferred_characteristics (gfc_typespec * ts)
m = gfc_match_prefix (ts);
gfc_buffer_error (false);
- if (ts->type == BT_DERIVED)
+ if (ts->type == BT_DERIVED || ts->type == BT_CLASS)
{
ts->kind = 0;
@@ -4215,7 +4215,7 @@ declSt:
if (bad_characteristic)
{
ts = _current_block ()->result->ts;
- if (ts->type != BT_DERIVED)
+ if (ts->type != BT_DERIVED && ts->type != BT_CLASS)
gfc_error ("Bad kind expression for function %qs at %L",
gfc_current_block ()->name,
_current_block ()->declared_at);
diff --git a/gcc/testsuite/gfortran.dg/class_result_4.f90 b/gcc/testsuite/gfortran.dg/class_result_4.f90
index 4b22a3c30ee..5497ac652ec 100644
--- a/gcc/testsuite/gfortran.dg/class_result_4.f90
+++ b/gcc/testsuite/gfortran.dg/class_result_4.f90
@@ -1,6 +1,6 @@
! { dg-do compile }
! PR fortran/78500
-class(t) function f() ! { dg-error "must be dummy, allocatable or pointer" }
+class(t) function f() ! { dg-error "is not accessible" }
f = 1 ! { dg-error "variable must not be polymorphic" }
end
diff --git a/gcc/testsuite/gfortran.dg/pr85779_3.f90 b/gcc/testsuite/gfortran.dg/pr85779_3.f90
index fba1133b3ea..a81a9faf88e 100644
--- a/gcc/testsuite/gfortran.dg/pr85779_3.f90
+++ b/gcc/testsuite/gfortran.dg/pr85779_3.f90
@@ -1,6 +1,6 @@
! { dg-do compile }
! PR fortran/85779
-class(t) function f() ! { dg-error "must be dummy, allocatable or pointer" }
+class(t) function f() ! { dg-error "is not accessible" }
type f ! { dg-error "already has a basic type" }
end type ! { dg-error "END FUNCTION statement" }
end
Re: [PATCH] PR fortran/100656 - ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
On 5/26/21 2:04 PM, Harald Anlauf via Fortran wrote: Dear Fortranners, Gerhard found a case where bounds-checking for an optional, allocatable character dummy resulted in an ICE. We'd better not call the presence check on a non-dummy symbol, as this will hit an assert... Regtested on x86_64-pc-linux-gnu. OK for mainline? And backport to 11? (The code in question has not been touched for nearly 10 years, so I'm expecting this to be safe). Thanks, Harald PR fortran/100656 - prevent ICE in gfc_conv_expr_present gcc/fortran/ChangeLog: PR fortran/100656 * trans-array.c (gfc_conv_ss_startstride): Do not call check for presence of a dummy argument when a symbol actually refers to a non-dummy. gcc/testsuite/ChangeLog: PR fortran/100656 * gfortran.dg/bounds_check_22.f90: New test. Yes, OK on both. Thanks Jerry
Re: [PATCH] PR fortran/100602 - [11/12 Regression] Erroneous "pointer argument is not associated" runtime error
On 5/18/21 11:36 AM, Harald Anlauf via Fortran wrote: The generation of the new runtime check picked up the wrong attributes in the case of CLASS array arguments. There is related new code in gfc_conv_procedure_call which served as reference for the fix. Regtested on x86_64-pc-linux-gnu. OK for mainline / 11-branch? Thanks, Harald Fortran: Fix erroneous "pointer argument is not associated" runtime error For CLASS arrays we need to use the CLASS data attributes to determine which runtime check to generate. gcc/fortran/ChangeLog: PR fortran/100602 * trans-intrinsic.c (gfc_conv_intrinsic_size): Use CLASS data attributes for CLASS arrays for generation of runtime error. gcc/testsuite/ChangeLog: PR fortran/100602 * gfortran.dg/pointer_check_14.f90: New test. Yes, OK for both, thanks Jerry
Re: *PING* [PATCH] PR fortran/100274 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
LGTM, OK for trunk and back ports. On 5/4/21 11:34 AM, Harald Anlauf via Fortran wrote: PING! --- Dear Fortranners, Gerhard found a case where the mismatch of actual and formal argument lead to an ICE instead of the relevant warning. Furthermore, the special case of character argument avoided the check that the actual argument must be definable if the formal one is INTENT-OUT or -INOUT. The check was already there, it just did not get triggered here. The patch is close to obvious, trivial and self-explaining. I chose to continue doing the argument checking after emitting the warning. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK for backports to the affected branches? Thanks, Harald PR fortran/100274 - ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131 When the check for the length of formal and actual character arguments found a mismatch and emitted a warning, it would skip further checks like that could lead to errors. Fix that by continuing the checking. Also catch a NULL pointer dereference. gcc/fortran/ChangeLog: PR fortran/100274 * interface.c (gfc_compare_actual_formal): Continue checks after emitting warning for argument length mismatch. * trans-expr.c (gfc_conv_procedure_call): Check for NULL pointer dereference. gcc/testsuite/ChangeLog: PR fortran/100274 * gfortran.dg/argument_checking_25.f90: New test.
Re: [Patch, fortran] PR99818 - [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
Paul, This looks OK to me for Trunk. I believe 10 is in freeze so it may have to wait or get release manager approval. Jerry On 4/1/21 6:44 AM, Paul Richard Thomas via Fortran wrote: This one is trivial. The wrong error message was transformed by my patch for PR98897 into an ICE. This patch now produces the correct error. Regtests OK on FC33/x86_64 - OK for the affected branches? Paul Fortran: Fix ICE on wrong code [PR99818]. 2021-04-01 Paul Thomas gcc/fortran/ChangeLog PR fortran/99818 * interface.c (compare_parameter): The codimension attribute is applied to the _data field of class formal arguments. gcc/testsuite/ChangeLog PR fortran/99818 * gfortran.dg/coarray_48.f90: New test.
Re: [PATCH] PR fortran/99840 - [8/9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
Yes OK for trunk and affected branches. Thanks, Jerry On 3/31/21 2:08 PM, Harald Anlauf via Fortran wrote: Dear all, the simplification of the TRANSPOSE of a zero-sized array would lead to an ICE if the result was used in a subsequent simplification of a MATMUL. The reason was the lack of the proper initialization of the shape, which is mpz_t. Use mpz_init_set instead of mpz_set. Regtested on x86_64-pc-linux-gnu. OK for mainline? Since this is a regression, backport to all affected branches? Thanks, Harald PR fortran/99840 - ICE in gfc_simplify_matmul, at fortran/simplify.c:4777 The simplification of the transposition of a constant array shall properly initialize and set the shape of the result. gcc/fortran/ChangeLog: PR fortran/99840 * simplify.c (gfc_simplify_transpose): Properly initialize resulting shape. gcc/testsuite/ChangeLog: PR fortran/99840 * gfortran.dg/transpose_5.f90: New test.
Re: off-by-one buffer overflow patch
Pushed: To git+ssh://gcc.gnu.org/git/gcc.git 651684b462f..01685676a93 master -> master Author: Steve Kargl Date: Sat Mar 27 15:02:16 2021 -0700 fortran: Fix off-by-one in buffer sizes. gcc/fortran/ChangeLog: * misc.c (gfc_typename): Fix off-by-one in buffer sizes. Regards, Jerry On 3/27/21 6:28 AM, dhumieres.domini...@free.fr wrote: Le 2021-03-27 06:36, Jerry DeLisle a écrit : On 3/26/21 10:38 AM, dhumieres.dominique--- via Fortran wrote: I have proposed a similar patch in pr95998. I cannot commit to git!-( Thanks Dominique I do not see a patch in 95998. Do you need help to do a commit? Jerry I was too quick and did not realize that I did not post the actual patch I have in my working tree, but the Steve's one does the trick. And yes I need help to do a commit. Thanks Dominique
Re: [Patch] Fortran: Fix 'name' bound size [PR99688]
Hi Tobias and others,
Reembering some of my own history, we always have used a +1 on
'LENGTH_MAX' items to allow the C null termination on strings or buffers
for obvious reasons.
Certainly OK for trunk and backports.
Regards,
Jerry
On 3/21/21 9:08 AM, Tobias Burnus wrote:
The gfc_match_select_rank issue showed up in the testsuite
and was found by Martin's asan-bootstrapped GCC. First
analysis by Harald – thanks to both!
However, I think the other variables I fixed were also
prone to overflows; see below for its usage.
OK for mainline? Other branches?
Tobias
PS: Other pending Fortran patches – please review!
[Patch] Fortran: Fix intrinsic null() handling [PR99651]
[Patch] Fortran: Fix func decl mismatch [PR93660]
PPS: Usage of 'name' in the patched functions:
resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
char name[GFC_MAX_SYMBOL_LEN];
...
sprintf (name, "__tmp_class_%s", c->ts.u.derived->name);
select_intrinsic_set_tmp (gfc_typespec *ts)
{
char name[GFC_MAX_SYMBOL_LEN];
...
sprintf (name, "__tmp_class_%s", ts->u.derived->name);
gfc_match_select_type (void)
...
char name[GFC_MAX_SYMBOL_LEN];
...
m = gfc_match (" %n => %e", name, );
gfc_match_select_rank (void)
...
char name[GFC_MAX_SYMBOL_LEN];
...
m = gfc_match (" %n => %e", name, );
Re: [patch, fortran] Also use size estimate for vector-matrix matmul
Yes Ok for trunk. Thanks much! On 3/19/21 10:37 AM, Thomas Koenig via Fortran wrote: Hell world, here is the patch I talked about earlier. It passes regression testing. OK for trunk? Best regards Thomas Add size check to vector-matrix matmul. It turns out the library version is much faster for vector-matrix multiplications for large sizes than what inlining can produce. Use size checks for switching between this and inlining for that case to. gcc/fortran/ChangeLog: * frontend-passes.c (inline_limit_check): Add rank_a argument. If a is rank 1, set the second dimension to 1. (inline_matmul_assign): Pass rank_a argument to inline_limit_check. (call_external_blas): Likewise. gcc/testsuite/ChangeLog: * gfortran.dg/inline_matmul_6.f90: Adjust count for _gfortran_matmul.
Re: [Patch] Fortran: Fix libgfortran I/O race with newunit_free [PR99529]
Looks good Tobias, OK, Odd about that line in set_internal_unit. Probably leftover from a copy/paste. I see in comment #5 of the PR that you mentioned trying the assert to make sure it is useless code. Thanks for the patch, Jerry On 3/11/21 2:38 AM, Tobias Burnus wrote: Revised version – the previous had a lock inversion, which could lead to a deadlock, found by -fsanitize=thread. See transfer.c for the changes. OK? Tobias On 11.03.21 10:42, Tobias Burnus wrote: Hi all, as found by Martin (thanks!) there is a race for newunit_free. While that call is within the unitlock for the calls in io/unit.c, the call in transfer.c did not use locks. Additionally, unit = get_gfc_unit (dtp->common.unit, do_create); set_internal_unit (dtp, unit, kind); gets first the unit (with proper locking when using the unit number dtp->common.unit) but then in set_internal_unit it re-sets the unit number to the same number without locking. That causes race warnings and if the assignment is not atomic it is a true race. OK for mainline? What about GCC 10? As Martin notes in the email thread and in the PR there are more race warnings (and likely true race issues). Tobias
Re: [Patch] Fortran: Follow fixes to -freal-{4,8}-real* handling [PR99355,PR57871] (was: Re: [Patch] Fortran: Fix -freal-{4,8}-real* handling [PR99355])
OK, thanks Dominique for spotting this.
On 3/4/21 9:02 AM, Tobias Burnus wrote:
Dominique found an issue ("regression") with this patch – and a testcase
omission.
The previous patch mishandled the noncommitted testcase of PR57871 – or
in other words: It did not promote 1.0_4 or 1.0_8 – as only the
default-real-kind values 1.0 and 1.0d0 were promoted (via code in in
trans-types.c).
I have additionally updated the documentation to more accurately state
what the option does and how it interacts with other options.
OK for mainline?
Tobias
PS: Side remark: My recommendation is to avoid
-freal-{4,8}-real-{4,8,10,16} ...
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
Frank Thürauf
Re: [PATCH] PR libfortran/99218 - [8/9/10/11 Regression] matmul on temporary array accesses invalid memory
Yes, OK, however, have you been able to test performance. I am only curious. There was a test program we used back when this code was first implemented in bugzilla. I do not remember the PR number off hand. Jerry On 2/23/21 1:46 PM, Harald Anlauf via Fortran wrote: Dear all, under certain circumstances a call to MATMUL for rank-2 times rank-1 would invoke a highly tuned rank-2 times rank-2 algorithm which could lead to invalid reads and writes. The solution is to check the rank of the second argument to matmul and fall back to a regular algorithm for rank-1. The invalid accesses did show up with valgrind. I have not been able to create a testcase that gives wrong results. Regtested on x86_64-pc-linux-gnu, and verified with valgrind. OK for master? As this affects all open branches down to 8, ok for backports? Thanks, Harald PR libfortran/99218 - matmul on temporary array accesses invalid memory Do not invoke tuned rank-2 times rank-2 matmul if rank(b) == 1. libgfortran/ChangeLog: PR libfortran/99218 * m4/matmul_internal.m4: Invoke tuned matmul only for rank(b)>1. * generated/matmul_c10.c: Regenerated. * generated/matmul_c16.c: Likewise. * generated/matmul_c4.c: Likewise. * generated/matmul_c8.c: Likewise. * generated/matmul_i1.c: Likewise. * generated/matmul_i16.c: Likewise. * generated/matmul_i2.c: Likewise. * generated/matmul_i4.c: Likewise. * generated/matmul_i8.c: Likewise. * generated/matmul_r10.c: Likewise. * generated/matmul_r16.c: Likewise. * generated/matmul_r4.c: Likewise. * generated/matmul_r8.c: Likewise. * generated/matmulavx128_c10.c: Likewise. * generated/matmulavx128_c16.c: Likewise. * generated/matmulavx128_c4.c: Likewise. * generated/matmulavx128_c8.c: Likewise. * generated/matmulavx128_i1.c: Likewise. * generated/matmulavx128_i16.c: Likewise. * generated/matmulavx128_i2.c: Likewise. * generated/matmulavx128_i4.c: Likewise. * generated/matmulavx128_i8.c: Likewise. * generated/matmulavx128_r10.c: Likewise. * generated/matmulavx128_r16.c: Likewise. * generated/matmulavx128_r4.c: Likewise. * generated/matmulavx128_r8.c: Likewise.
Re: [Patch] Fortran: Fix -freal-{4,8}-real* handling [PR99355]
Yes OK got mainline. On 3/3/21 3:45 AM, Tobias Burnus wrote: Rather obvious change – don't apply replacement multiple times. OK for mainline? Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf
Re: [PATCH] PR fortran/99206 - [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980
Hi Harald, Looks Good to Me. OK Thanks On 2/22/21 1:14 PM, Harald Anlauf via Fortran wrote: Dear all, when simplifying the RESHAPE intrinsic we lost the string length when the resulting array had size zero. The attached patch sets the resulting length from the source. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald PR fortran/99206 - ICE in add_init_expr_to_sym, at fortran/decl.c:1980 Make sure that the string length is properly set during simplification even when the resulting array is zero-sized. gcc/fortran/ChangeLog: PR fortran/99206 * simplify.c (gfc_simplify_reshape): Set string length for character arguments. gcc/testsuite/ChangeLog: PR fortran/99206 * gfortran.dg/reshape_zerosize_4.f90: New test.
Re: *PING**2 Re: [Patch] Fortran: Fix coarray handling for gfc_dep_resolver [PR99010] (was: Re: [Patch] Fortran: Fix Array dependency with local coarrays [PR98913]
On 2/19/21 1:33 AM, Tobias Burnus wrote: On 09.02.21 12:52, Tobias Burnus wrote: Hi all, hi Thomas, On 02.02.21 18:15, Tobias Burnus wrote: I think I will do a combination: If 'identical' is true, I think I cannot remove it. If it is false, it can be identical or nonoverlapping – which makes sense. Well, it turned out that coarray scalars did not work; for them, the array ref consists only of the coindexed access: falling through then triggered as fin_dep == GFC_DEP_ERROR. To be more careful, I also removed the 'identical &&' check such that the first loop is now always triggered if coarray != SINGLE not only if identical – I am not sure whether it is really needed or whether falling though is the better solution (with updating the comment). I would be happy if someone could carefully check the logic – in the details, it is rather confusing. OK? Yes OK, thanks for patch. Jerry
Re: [Patch] Fortran: Fix DTIO with type ICE [PR99146]
On 2/19/21 8:00 AM, Tobias Burnus wrote: In this example, the formal argument is a derived type and not a class – hence, there is an ICE. OK for the trunk? This is OK, could you also check 89219 and 81499 and see if these are the same or similar. Much appreciated. Jerry
[patch, fortran] PR96686 Namelist group objects shall be defined before appearing in namelist
Hi all,
Attached patch adds to checks. In the case of IMPLICIT typing it checks
to see if the objects listed in the NAMELIST have defined types andf if
not, sets them to the default implicit types.
In the case of IMPLICIT NONE, the types are required be declared before
the NAMELIST. If an object type is found to not be declared already,
an error is issued.
One new test case added and one modified to pass.
Regression tested.
OK for trunk?
Regards,
Jerry
fortran: Object types should be declared before use in NAMELIST.
gcc/fortran/ChangeLog:
PR fortran/98686
* match.c (gfc_match_namelist): Add checks for IMPLICIT NONE and
whether the type for each namelist object has been defined before
the namelist declaration. For IMPLICIT, set the types so that
any subsequent use of objects will have their types confirmed.
gcc/testsuite/ChangeLog:
PR fortran/98686
* gfortran.dg/namelist_4.f90: Modify.
* gfortran.dg/namelist_98.f90: New test.
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 2df6191d7e6..3a06f308812 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -5536,6 +5536,27 @@ gfc_match_namelist (void)
if (m == MATCH_ERROR)
goto error;
+ if (!gfc_current_ns->seen_implicit_none)
+ {
+ /* If the type is not set already, we set it here to the
+ implicit default type. It is not allowed to set it
+ later to any other type. */
+ if (sym->ts.type == BT_UNKNOWN)
+ gfc_set_default_type (sym, 0, gfc_current_ns);
+ }
+ else
+ {
+ /* It is required that members of a namelist be declared
+ before the namelist. We check this by checking if the
+ symbol has a defined type for IMPLICIT NONE. */
+ if (sym->ts.type == BT_UNKNOWN)
+ {
+ gfc_error ("Symbol %qs in namelist %qs at %C must be "
+ "declared before the namelist is declared.",
+ sym->name, group_name->name);
+ gfc_error_check ();
+ }
+ }
if (sym->attr.in_namelist == 0
&& !gfc_add_in_namelist (>attr, sym->name, NULL))
goto error;
diff --git a/gcc/testsuite/gfortran.dg/namelist_4.f90 b/gcc/testsuite/gfortran.dg/namelist_4.f90
index 538bceaa4b6..4e021253f01 100644
--- a/gcc/testsuite/gfortran.dg/namelist_4.f90
+++ b/gcc/testsuite/gfortran.dg/namelist_4.f90
@@ -27,14 +27,14 @@ END module M1
program P1
CONTAINS
! This has the additional wrinkle of a reference to the object.
+ INTEGER FUNCTION F2()
+F2=1
+ END FUNCTION
INTEGER FUNCTION F1()
NAMELIST /NML3/ F2 ! { dg-error "PROCEDURE attribute conflicts" }
! Used to ICE here
-f2 = 1 ! { dg-error "is not a VALUE" }
+f2 = 1 ! { dg-error "is not a variable" }
F1=1
END FUNCTION
- INTEGER FUNCTION F2()
-F2=1
- END FUNCTION
END
diff --git a/gcc/testsuite/gfortran.dg/namelist_98.f90 b/gcc/testsuite/gfortran.dg/namelist_98.f90
new file mode 100644
index 000..19a7e869f92
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/namelist_98.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! pr98686
+ implicit none
+ real:: x, m
+ namelist /NML/ x, m, q ! { dg-error "must be declared before the namelist*" }
+ integer :: q
+ x = 1.0
+ m = 2.0
+ q = 3
+ write(*, nml=NML)
+end
Re: [patch, libfortran] PR95647 operator(.eq.) and operator(==) treated differently
How do I get permissions set so that I can change status of bug reports and assign to myself. My permissions got dissolved during some evolution in the last year. also The master branch has been updated by Jerry DeLisle: https://gcc.gnu.org/g:0631e008adc759cc801d0d034224ee6b4bcf31aa commit r11-7225-g0631e008adc759cc801d0d034224ee6b4bcf31aa Author: Steve Kargl Date: Fri Feb 12 07:58:16 2021 -0800 On 2/11/21 7:02 PM, Jerry DeLisle wrote: The attached patch is another provided from Steve Kargle in the PR report. I have created a test case and regression tested the result. OK for trunk? Regards, Jerry libgfortran: Fix PR95647 by changing the interfaces of operators .eq. and .ne. The FE converts the old school .eq. to ==, and then tracks the ==. The module starts with == and so it does not properly overload the .eq. Reversing the interfaces fixes this. 2021-02-11 Steve Kargl libgfortran/ChangeLog: PR libfortran 95647 * ieee/ieee_arithmetic.F90: Flip interfaces of operators .eq. to == and .ne. to /= . gcc/testsuite/ChangeLog: PR libfortran 95647 * gfortran.dg/ieee/ieee_arithmetic: New test.
[patch, libfortran] PR95647 operator(.eq.) and operator(==) treated differently
The attached patch is another provided from Steve Kargle in the PR report.
I have created a test case and regression tested the result.
OK for trunk?
Regards,
Jerry
libgfortran: Fix PR95647 by changing the interfaces of operators .eq.
and .ne.
The FE converts the old school .eq. to ==,
and then tracks the ==. The module starts with == and so it does not
properly overload the .eq. Reversing the interfaces fixes this.
2021-02-11 Steve Kargl
libgfortran/ChangeLog:
PR libfortran 95647
* ieee/ieee_arithmetic.F90: Flip interfaces of operators .eq. to
== and .ne. to /= .
gcc/testsuite/ChangeLog:
PR libfortran 95647
* gfortran.dg/ieee/ieee_arithmetic: New test.
diff --git a/gcc/testsuite/gfortran.dg/ieee/ieee_12.f90 b/gcc/testsuite/gfortran.dg/ieee/ieee_12.f90
new file mode 100644
index 000..139a70142b8
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/ieee/ieee_12.f90
@@ -0,0 +1,24 @@
+! { dg-do run }
+! PR95647 operator(.eq.) and operator(==) treated differently
+program test
+ use, intrinsic :: ieee_arithmetic, only : &
+&ieee_class, &
+&ieee_class_type, &
+&ieee_negative_normal, &
+&ieee_positive_normal, &
+&operator(.eq.), operator(.ne.)
+ integer :: good
+ real(4) r4
+ type(ieee_class_type) class1
+ good = 0
+ r4 = 1.0
+ class1 = ieee_class(r4)
+ if (class1 .eq. ieee_positive_normal) good = good + 1
+ if (class1 .ne. ieee_negative_normal) good = good + 1
+ r4 = -1.0
+ class1 = ieee_class(r4)
+ if (class1 .eq. ieee_negative_normal) good = good + 1
+ if (class1 .ne. ieee_positive_normal) good = good + 1
+ if (good /= 4) call abort
+end program test
+
diff --git a/libgfortran/ieee/ieee_arithmetic.F90 b/libgfortran/ieee/ieee_arithmetic.F90
index 55992232ce2..35a16938f8e 100644
--- a/libgfortran/ieee/ieee_arithmetic.F90
+++ b/libgfortran/ieee/ieee_arithmetic.F90
@@ -77,15 +77,16 @@ module IEEE_ARITHMETIC
! Equality operators on the derived types
- interface operator (==)
+ ! Note, the FE overloads .eq. to == and .ne. to /=
+ interface operator (.eq.)
module procedure IEEE_CLASS_TYPE_EQ, IEEE_ROUND_TYPE_EQ
end interface
- public :: operator(==)
+ public :: operator(.eq.)
- interface operator (/=)
+ interface operator (.ne.)
module procedure IEEE_CLASS_TYPE_NE, IEEE_ROUND_TYPE_NE
end interface
- public :: operator (/=)
+ public :: operator (.ne.)
! IEEE_IS_FINITE
Re: [patch, libgfortran] PR98825 Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'
On 2/7/21 9:07 AM, Thomas Koenig wrote: Hi Jerry, OK for trunk and backport to 10 since it is simple enough? OK for trunk. Because this is a user-visible change (even if we did the wrong thing before) I don't feel that we should backport (but I am open to suggestions otherwise). Could you also mention this in gcc-11/changes.html ? Best regards Thomas The above was committed. I had a very frustrating experiance with the push process. Over and over attempting to push and having it rejected for an invalid PR reference. The directory that holds the runtime library is called "libgfortran". The official gcc component in Bugzilla is called "libfortran". There is no letter "g" in that component name and thus the hooks rejected my push attempts. The only reason I figured it out, after exhausting about 25 other variations I could think of is that I thought "What does the PR think this is?" Well that was not intuitively obvious, but my bug tracking persistance hung in there. Sheesh! Just telling people so others might be aware of this little detail. Thomas, I will get around to updating the changes.html. Thanks and best regards, Jerry
[patch, libgfortran] PR98825 Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'
Hello all,
Attached patch fixes this and adds a test case. The "$" edit descriptor
was being completely ignored when next_record_w is processed. Fixed by
adding a simple check.
OK for trunk and backport to 10 since it is simple enough?
Regards,
Jerry
libgfortran: Do not emit end-of-record if seen_dollar.
2021-02-07 Jerry DeLisle
libgfortran/ChangeLog:
PR libgfortran/98825
* io/transfer.c (next_record_w): Insert check for seen_dollar and if
so, skip issueing next record.
gcc/testsuite/ChangeLog:
* gfortran.dg/dollar_edit_descriptor_4.f: New test.
diff --git a/gcc/testsuite/gfortran.dg/dollar_edit_descriptor_4.f b/gcc/testsuite/gfortran.dg/dollar_edit_descriptor_4.f
new file mode 100644
index 000..c8453ce6bc8
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/dollar_edit_descriptor_4.f
@@ -0,0 +1,16 @@
+! { dg-do run }
+! { dg-options "-std=gnu" }
+! PR98825 Test for fix of '$' edit descriptor.
+ character(30) :: line
+ 10 format (i3,$)
+
+ open(10, status='scratch')
+ write (10,10) 1
+ write (10,10) 2,3,4,5
+! Check the result.
+ line = 'abcdefg'
+ rewind(10)
+ read(10, '(a)') line
+ close(10)
+ if (line .ne. ' 1 2 3 4 5') call abort
+ end
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 8ab0583dd55..27bee9d4e01 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -4020,6 +4020,8 @@ next_record_w (st_parameter_dt *dtp, int done)
}
}
}
+ else if (dtp->u.p.seen_dollar == 1)
+ break;
/* Handle legacy CARRIAGECONTROL line endings. */
else if (dtp->u.p.current_unit->flags.cc == CC_FORTRAN)
next_record_cc (dtp);
Re: [PATCH, Fortran] PR fortran/93524 - ISO_Fortran_binding signed char arrays
Looks good and I have tested. I will commit after one more double check
for regressions with the test case in the testsuite
I have been following Harris on this one for several days and tested the
patch before submitted here.
Thanks for patch Harris, much appreciated.
Regards,
Jerry
On 1/13/21 8:02 AM, Harris Snyder wrote:
On Wed, Jan 13, 2021 at 1:34 AM Harris Snyder wrote:
Hi everyone,
Sorry, my previous email erroneously referred to unsigned chars / uint8_t,
when I in fact meant signed chars / int8_t. The actual patch works, but the
test case files have ‘uint’ in the file names. I’ll provide a corrected patch
tomorrow to fix the file names.
Harris
Corrected patch below.
OK for master? I don't have write access so I will need someone else
to commit this for me if possible.
Thanks,
Harris Snyder
Fixes a bug in ISO_Fortran_binding.c whereby signed char or int8_t
arrays would cause crashes unless an element size is specified.
Related to PR fortran/93524.
libgfortran/ChangeLog:
* runtime/ISO_Fortran_binding.c (CFI_establish): fixed signed char arrays.
gcc/testsuite/ChangeLog:
* gfortran.dg/iso_fortran_binding_int8_array.f90: New test.
* gfortran.dg/iso_fortran_binding_int8_array_driver.c: New test.
diff --git a/gcc/testsuite/gfortran.dg/iso_fortran_binding_int8_array.f90
b/gcc/testsuite/gfortran.dg/iso_fortran_binding_int8_array.f90
new file mode 100644
index 000..31fdf863e0a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/iso_fortran_binding_int8_array.f90
@@ -0,0 +1,11 @@
+! { dg-do run }
+! { dg-additional-sources iso_fortran_binding_int8_array_driver.c }
+
+module m
+ use iso_c_binding
+contains
+ subroutine fsub( x ) bind(C, name="fsub")
+ integer(c_int8_t), intent(inout) :: x(:)
+ x = x+1
+ end subroutine
+end module
diff --git a/gcc/testsuite/gfortran.dg/iso_fortran_binding_int8_array_driver.c
b/gcc/testsuite/gfortran.dg/iso_fortran_binding_int8_array_driver.c
new file mode 100644
index 000..84ed127d525
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/iso_fortran_binding_int8_array_driver.c
@@ -0,0 +1,25 @@
+#include
+#include
+#include
+#include "ISO_Fortran_binding.h"
+
+extern void fsub(CFI_cdesc_t *);
+
+int main(void)
+{
+ int8_t x[] = {1,2,3,4};
+ int N = sizeof(x)/sizeof(x[0]);
+
+ CFI_CDESC_T(1) dat;
+ CFI_index_t ext[1];
+ ext[0] = (CFI_index_t)N;
+ int rc = CFI_establish((CFI_cdesc_t *), , CFI_attribute_other,
+ CFI_type_int8_t, 0, (CFI_rank_t)1, ext);
+ printf("CFI_establish call returned: %d\n", rc);
+
+ fsub((CFI_cdesc_t *) );
+
+ for (int i=0; ibase_addr = base_addr;
if (type == CFI_type_char || type == CFI_type_ucs4_char ||
- type == CFI_type_signed_char || type == CFI_type_struct ||
- type == CFI_type_other)
+ type == CFI_type_struct || type == CFI_type_other)
dv->elem_len = elem_len;
else
{
Re: Ping: [Patch, fortran] PR97694 - ICE with optional assumed rank class(*) argument (and PR97723)
LGTM Paul, go for it. On 12/26/20 8:37 AM, Paul Richard Thomas via Fortran wrote: Ping! On Sat, 12 Dec 2020 at 10:38, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: Fortran: Fix some select rank issues [PR97694 and 97723]. Hi All, Unlike select type, select rank selectors retain the allocatable attribute. This is corrected by the chunk in check.c. Note the trailing whitespace corrections. Resolution of select rank construct must be done in the same way as select type and so the break has been added to ensure that the block is resolved in resolve_select_rank. The final chunk prevents segfaults for class associate variables that are optional dummies, since these apparently are not adorned with the GFC_DECL_SAVED_DESCRIPTOR. Regtests OK on FC31/x86_64 - OK for master? Cheers Paul 2020-12-12 Paul Thomas gcc/fortran PR fortran/97694 PR fortran/97723 * check.c (allocatable_check): Select rank temporaries are permitted even though they are treated as associate variables. * resolve.c (gfc_resolve_code): Break on select rank as well as select type so that the block os resolved. * trans-stmt.c (trans_associate_var): Class associate variables that are optional dummies must use the backend_decl. gcc/testsuite/ PR fortran/97694 PR fortran/97723 * gfortran.dg/select_rank_5.f90: New test.
Re: *PING* [PATCH] PR fortran/90903 [part2] Add runtime checking for the MVBITS intrinsic
Harold, Looks good. Thanks for the work! Jerry On 9/20/20 11:10 AM, Harald Anlauf wrote: *ping* Gesendet: Sonntag, 13. September 2020 um 23:24 Uhr Von: "Harald Anlauf" An: "fortran" , "gcc-patches" Cc: "Paul Richard Thomas" Betreff: [PATCH] PR fortran/90903 [part2] Add runtime checking for the MVBITS intrinsic Dear all, finally here comes the second part of runtime checks for the bit manipulation intrinsics, this time MVBITS. This turned out to be more elaborate than the treatment of simple function calls. I chose the path to inline expand MVBITS, which enables additional optimization opportunities in some cases, such as constant arguments. For the case of scalar arguments, this was mostly straightforward. However, for the proper handling of MVBITS as an elemental procedure all honors should go to Paul, as he not only lend me a hand and kindly guided me through the swampland of the scalarizer, but he also managed to placate the gimple part of gcc. Regtested on x86_64-pc-linux-gnu. OK for master? Thanks, Harald PR fortran/90903 [part2] - Add runtime checking for the MVBITS intrinsic Implement inline expansion of the intrinsic elemental subroutine MVBITS with optional runtime checks for valid argument range. gcc/fortran/ChangeLog: * iresolve.c (gfc_resolve_mvbits): Remove unneeded conversion of FROMPOS, LEN and TOPOS arguments to fit a C int. * trans-intrinsic.c (gfc_conv_intrinsic_mvbits): Add inline expansion of MVBITS intrinsic elemental subroutine and add code for runtime argument checking. (gfc_conv_intrinsic_subroutine): Recognise MVBITS intrinsic, but defer handling to gfc_trans_call. * trans-stmt.c (replace_ss): (gfc_trans_call): Adjust to handle inline expansion, scalarization of intrinsic subroutine MVBITS in gfc_conv_intrinsic_mvbits. * trans.h (gfc_conv_intrinsic_mvbits): Add prototype for gfc_conv_intrinsic_mvbits. gcc/testsuite/ChangeLog: * gfortran.dg/check_bits_2.f90: New test. Co-authored-by: Paul Thomas
Re: [PATCH] PR fortran/97036 - [F2018] Allow ELEMENTAL RECURSIVE procedure prefix
ok, thanks . On 9/15/20 1:35 PM, Harald Anlauf wrote: As stated in the PR, the Fortran 2018 standard removed the restriction prohibiting ELEMENTAL RECURSIVE procedures. Adjust the relevant check. Regtested on x86_64-pc-linux-gnu. OK for master? Thanks, Harald PR fortran/97036 - [F2018] Allow ELEMENTAL RECURSIVE procedure prefix gcc/fortran/ChangeLog: * symbol.c (gfc_check_conflict): Allow ELEMENTAL RECURSIVE procedure prefix for -std=f2018. gcc/testsuite/ChangeLog: * gfortran.dg/pr97036.f90: New test.
Re: [PATCH] Fortran : rejected f0.d edit descriptor PR96436
On 8/17/20 12:31 AM, Mark Eggleston wrote: Please find attached a patch for PR96436. OK to commit? Looks good to me. Thanks for fixing this. Regards, Jerry
Re: [Patch, fortran] PR93671 - gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray
This look good, OK to commit. Thanks, Jerry On 8/10/20 8:03 AM, Andre Vehreschild wrote: Hi folks, long time, no see. I was asked by Damian to do some Coarray stuff in gfortran so here is the first step on fixing a bug. The issue at hand is, that the coarray handling is not propagated correctly and later on the coarray-token not generated/retrieved from the correct position leading to coarray programs to crash/hang. This patch fixes at least the misbehavior reported in the PR. More to come. Regtests ok on FC31.x86_64. Ok for trunk? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [PATCH] Fortran : ICE in gfc_check_reshape PR95585
OK to commit and Backport. On 6/18/20 1:11 AM, Mark Eggleston wrote: Please find attached fix for PR95585. OK to commit and backport? Commit message: Fortran : ICE in gfc_check_reshape PR95585 Issue an error where an array is used before its definition instead of an ICE. 2020-06-18 Steven G. Kargl gcc/fortran/ PR fortran/PR95585 *check.c (gfc_check_reshape): Add check for a value when the symbol has an attribute flavor FL_PARAMETER. 2020-06-17 Mark Eggleston gcc/testsuite/ PR fortran/95585 * gfortran.dg/pr95585.f90: New test.
Re: [PATCH] Fortran : ICE in gfc_check_pointer_assign PR95612
OK to commit and backport. On 6/30/20 11:12 PM, Mark Eggleston wrote: Please find attached a patch which is a fix for PR95612. The original patch is by Steve Kargl. OK to commit and backport? Commit message: Fortran : ICE in gfc_check_pointer_assign PR95612 Output an error if the right hand value is a zero sized array or does not have a symbol tree otherwise continue checking. 2020-07-01 Steven G. Kargl gcc/fortran/ PR fortran/95612 * expr.c (gfc_check_pointer_assigb): Output an error if rvalue is a zero sized array or output an error if rvalue doesn't have a symbol tree. 2020-07-01 Mark Eggleston gcc/testsuite/ PR fortran/95612 * gfortran.dg/pr95612.f90: New test.
Re: [PATCH] Fortran : Fill in missing array dimensions using the lower, bound (for review)
On 6/27/20 1:40 AM, Thomas Koenig via Fortran wrote: Hi Mark, Use -fdec-add-missing-indexes to enable feature. Also enabled by fdec. A warning that the lower bound is being used for a mission dimension is output unless suppressed by using -Wno-missing-index. This is... seriously problematic. I forsee all sorts of not-so-funny interactions with more modern features. What do people actually do with this kind of code? What kind of test cases do you have that "work" with this? And people would actually want to save a few keystrokes so they don't have to write A(N,M,1) instead of A(N,M)? And is this even the right fix, how sure are you of the semantics; is there documentation for this feature (maybe on Bitsavers)? If not, this is not be done. If this goes in at all, I want this rejected with any modern Fortran feature, i.e. it should not be contain - allocatable arrays - coarrays - pointers - derived types - CLASS - assumed-shape arrays - assumed-rank arrays (well, it probably doesn't make sense) - KIND=4 characters - as an argument to any of the array intrinsics like MATMUL, EOSHIFT, ... but even with these restrictions, I will still take a lot of convincing that this make sense. Just imagine what will happen if people specify -fdec for some relatively benign reason (for example because they want -fdec-math) and start not finding bugs in their code because of this feature. Best regards Thomas Please stop fixing problematic DEC programs by using the compiler as the pet tool. Use an editor or python or some suitable tool to initialize arrays properly. I appreciate the effort, but need things run by here before the effort so you can spend the effort on really true compiler bugs, and not on the wishes of perhaps a paying customer. We should never have caved on the previous DEC enhancement. Just my humble opinion. Jerry
Re: [PATCH] PR fortran/95707 - ICE in finish_equivalences, at fortran/trans-common.c:1319
OK, and once again, thanks. Jerry On 6/17/20 12:27 PM, Harald Anlauf wrote: Another corner case of buffer overflows during name mangling found by Gerhard. We now check that the new buffer sizes suffice. The patch is on top of the patches for PRs 95687, 95688, 95689. Regtested on x86_64-pc-linux-gnu. OK for master / backports? Thanks, Harald PR fortran/95707 - ICE in finish_equivalences, at fortran/trans-common.c:1319 With submodules and equivalence declarations, name mangling may result in long internal symbols overflowing internal buffers. We now check that we do not exceed the enlarged buffer sizes. gcc/fortran/ PR fortran/95707 * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (gfc_sym_mangled_common_id): Enlarge temporary buffers, and add check on length on mangled name to prevent overflow.
Re: [PATCH] PR fortran/95827 - Buffer overflows with PDTs and long symbols
OK, and thanks for Patch. On 6/23/20 2:08 PM, Harald Anlauf wrote: Dear all, here's another case with a buffer that did overflow. Regtested on x86_64-pc-linux-gnu. OK for master / backports? Thanks, Harald PR fortran/95827 - Buffer overflows with PDTs and long symbols With submodules and coarrays, name mangling results in long internal symbols. Enlarge internal buffer. gcc/fortran/ PR fortran/95827 * iresolve.c (gfc_get_string): Enlarge internal buffer used in generating the mangled name.
Re: [patch,fortran] PR90374 add e0 zero width exponent support
On 11/28/19 7:53 AM, Steve Kargl wrote:
On Thu, Nov 28, 2019 at 07:45:25AM -0800, Jerry DeLisle wrote:
+ if (u == FMT_ZERO)
+ {
+ if (!gfc_notify_std (GFC_STD_F2018,
+ "Positive exponent width required in "
+ "format string at %L", _locus))
+ {
+ saved_token = u;
+ goto fail;
+ }
+ }
+ else
+ {
+ error = G_("Positive exponent width required in format"
+"string at %L");
This needs a space after "format" or before "string".
+ goto syntax;
+ }
}
Fixed. OK with that?
Jerry
[patch,fortran] PR90374 add e0 zero width exponent support
Hi all,
The attached patch implements the last piece of this which enables the zero
width exponent, giving a processor dependent width.
Regression tested on x86_64-pc-linux-gnu.
I don't think it is very intrusive and I updated the test case.
OK for trunk?
Regards,
Jerry
2019-11-27 Jerry DeLisle
PR fortran/90374
* io.c (check_format): Allow zero width expoenent with e0.
io/format.c (parse_format_list): Relax format checking to allow
e0 exponent specifier.
* gfortran.dg/fmt_zero_width.f90: Update test.
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index 57a3fdd5152..70aa6474445 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -1007,9 +1007,22 @@ data_desc:
goto fail;
if (u != FMT_POSINT)
{
- error = G_("Positive exponent width required in format string "
- "at %L");
- goto syntax;
+ if (u == FMT_ZERO)
+ {
+ if (!gfc_notify_std (GFC_STD_F2018,
+ "Positive exponent width required in "
+ "format string at %L", _locus))
+ {
+ saved_token = u;
+ goto fail;
+ }
+ }
+ else
+ {
+ error = G_("Positive exponent width required in format"
+ "string at %L");
+ goto syntax;
+ }
}
}
diff --git a/gcc/testsuite/gfortran.dg/fmt_zero_width.f90 b/gcc/testsuite/gfortran.dg/fmt_zero_width.f90
index 093c0a44c34..640b6735c65 100644
--- a/gcc/testsuite/gfortran.dg/fmt_zero_width.f90
+++ b/gcc/testsuite/gfortran.dg/fmt_zero_width.f90
@@ -1,11 +1,11 @@
! { dg-do run }
! PR90374 "5.5 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d edit descriptors
program pr90374
+ implicit none
real(4) :: rn
character(32) :: afmt, aresult
- real(8) :: one = 1.0D0, zero = 0.0D0, nan, pinf, minf
+ real(8) :: one = 1.0D0, zero = 0.0D0, pinf, minf
- nan = zero/zero
rn = 0.00314_4
afmt = "(D0.3)"
write (aresult,fmt=afmt) rn
@@ -22,15 +22,19 @@ program pr90374
afmt = "(G0.10)"
write (aresult,fmt=afmt) rn
if (aresult /= "0.313928E-02") stop 24
+ afmt = "(E0.10e0)"
+ write (aresult,fmt=afmt) rn
+ if (aresult /= "0.313928E-02") stop 27
write (aresult,fmt="(D0.3)") rn
- if (aresult /= "0.314D-02") stop 26
+ if (aresult /= "0.314D-02") stop 29
write (aresult,fmt="(E0.10)") rn
- if (aresult /= "0.313928E-02") stop 28
+ if (aresult /= "0.313928E-02") stop 31
write (aresult,fmt="(ES0.10)") rn
- if (aresult /= "3.139280E-03") stop 30
+ if (aresult /= "3.139280E-03") stop 33
write (aresult,fmt="(EN0.10)") rn
- if (aresult /= "3.139280E-03") stop 32
+ if (aresult /= "3.139280E-03") stop 35
write (aresult,fmt="(G0.10)") rn
- if (aresult /= "0.313928E-02") stop 34
-
+ if (aresult /= "0.313928E-02") stop 37
+ write (aresult,fmt="(E0.10e0)") rn
+ if (aresult /= "0.313928E-02") stop 39
end
diff --git a/libgfortran/io/format.c b/libgfortran/io/format.c
index b33620815d5..dd448c83e87 100644
--- a/libgfortran/io/format.c
+++ b/libgfortran/io/format.c
@@ -1027,11 +1027,17 @@ parse_format_list (st_parameter_dt *dtp, bool *seen_dd)
{
t = format_lex (fmt);
if (t != FMT_POSINT)
- {
- fmt->error = "Positive exponent width required in format";
- goto finished;
- }
-
+ if (t == FMT_ZERO)
+ {
+ notify_std (>common, GFC_STD_F2018,
+ "Positive exponent width required");
+ }
+ else
+ {
+ fmt->error = "Positive exponent width required in "
+ "format string at %L";
+ goto finished;
+ }
tail->u.real.e = fmt->value;
}
diff --git a/libgfortran/io/write_float.def b/libgfortran/io/write_float.def
index daa16679f53..ce6aec83114 100644
--- a/libgfortran/io/write_float.def
+++ b/libgfortran/io/write_float.def
@@ -482,7 +482,7 @@ build_float_string (st_parameter_dt *dtp, const fnode *f, char *buffer,
for (i = abs (e); i >= 10; i /= 10)
edigits++;
- if (f->u.real.e < 0)
+ if (f->u.real.e <= 0)
{
/* Width not specified. Must be no more than 3 digits. */
if (e > 999 || e < -999)
Re: [patch, committed] PR92100 Formatted stream IO irreproducible read with binary data in file
On 11/24/19 2:20 PM, Jerry DeLisle wrote: Committed this as simple one liner. I will probably backport this in a few days. Jerry Committed r278660 M libgfortran/ChangeLog M libgfortran/io/transfer.c 2019-11-24 Jerry DeLisle PR fortran/92100 io/transfer.c (data_transfer_init_worker): Use fbuf_reset instead of fbuf_flush before the seek. Note that fbuf_reset calls fbuf_flush and adjusts fbuf pointers. Also commited a testcase, streamio_18.f90. Jerry
[patch, committed] PR92100 Formatted stream IO irreproducible read with binary data in file
Committed this as simple one liner. I will probably backport this in a few
days.
Jerry
Committed r278660
M libgfortran/ChangeLog
M libgfortran/io/transfer.c
2019-11-24 Jerry DeLisle
PR fortran/92100
io/transfer.c (data_transfer_init_worker): Use fbuf_reset
instead of fbuf_flush before the seek. Note that fbuf_reset
calls fbuf_flush and adjusts fbuf pointers.
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 6382d0dad09..bb104db3584 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -3273,8 +3273,9 @@ data_transfer_init_worker (st_parameter_dt *dtp, int
read_flag)
if (dtp->pos != dtp->u.p.current_unit->strm_pos)
{
- fbuf_flush (dtp->u.p.current_unit, dtp->u.p.mode);
- if (sseek (dtp->u.p.current_unit->s, dtp->pos - 1, SEEK_SET) < 0)
+ fbuf_reset (dtp->u.p.current_unit);
+ if (sseek (dtp->u.p.current_unit->s, dtp->pos - 1,
+SEEK_SET) < 0)
{
generate_error (>common, LIBERROR_OS, NULL);
return;
Re: [Patch][Fortran] PR91253 fix continuation-line handling with -pre_include
On 11/7/19 12:41 PM, Tobias Burnus wrote:
This fixes the gfortran.dg/continuation_6.f fails testsuite fails with newer
GLIBC.
The continuation line handling assumes that the line number starts at 0 (→
continue_line) and then can be incremented, if needed.
The problem came up with -pre_include, which is used with newer GLIBC to provide
things like "!GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64')".
There, first the file math-vector-fortran.h file is loaded, then the actual
file. The 'continue_line' gets incremented for math-vector-fortran.h but nothing
resets it before parsing the actual input file. For the 'include_stmt' function,
the reset happens during parsing – while for our case, this knowledge is only in
the line information, but on file change, 'continue_line' is not updated/reset.
I think the same issue can occur with #include, especially as one plays with
#line, but I have not actually tested it. Obviously, if one plays around with
#line during a continuation block, this check won't work either. However, it
should fix the most common occurrence.
Additionally, I have removed the ATTRIBUTE_UNUSED from get_file's 'reason' as it
is used in the linemap_add call.
And I have moved the OpenMP/OpenACC comment before if openmp/openacc condition,
where in my opinion it belongs to.
OK for the trunk?
Tobias
Yes, OK, thanks for patch.
Jerry
[Patch, Fortran] PR90374 Support d0.d, e0.d, es0.d, en0.d, g0.d
Hi all,
The attached patch provides frontend and runtime modifications to allow the
subject format specifiers. These are allowed as default behavior and under
-std=f2018.
It does not implement the ew.de0 specifier. I decided to do that part
separarately since it involves different places in the code.
I will to a Changlog for the testsuite changes. In summary:
modified: fmt_error_10.f to allow it to pass.
modified: fmt_error_7.f likewise.
modified: fmt_error_9.f likewise.
new file: fmt_zero_width.f90 to test the new features.
Regression tested on x86_64-pc-linux-gnu.
OK for trunk?
Jerry
2019-11-01 Jerry DeLisle
PR fortran/90374
* io.c (check_format): Allow zero width for D, E, EN, and ES
specifiers as default and when -std=F2018 is given. Retain
existing errors when using the -fdec family of flags.
2019-11-01 Jerry DeLisle
PR fortran/90374
io/format.c (parse_format_list): Relax format checking for
zero width as default and when -std=f2018.
io/format.h (format_token): Move definition to io.h.
io/io.h (format_token): Add definition here to allow access to
this definition at higher levels. Rename the declaration of
write_real_g0 to write_real_w0 and add a new format_token
argumanet so that higher level functions can pass to it the
token so that handling of g0 vs the other zero width specifiers
can be differentiated.
io/transfer.c (formatted_transfer_scalar_write): Add checks for
zero width and call write_real_w0 to handle it.
io/write.c (write_real_g0): Remove.
(write_real_w0): Add new, same as previous write_real_g0 except
check format token to handle the g0 case.
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index b969a1a4738..57a3fdd5152 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -922,19 +922,38 @@ data_desc:
if (u != FMT_POSINT)
{
+ if (flag_dec)
+ {
+ if (flag_dec_format_defaults)
+ {
+ /* Assume a default width based on the variable size. */
+ saved_token = u;
+ break;
+ }
+ else
+ {
+ gfc_error ("Positive width required in format "
+ "specifier %s at %L", token_to_string (t),
+ _locus);
+ saved_token = u;
+ goto fail;
+ }
+ }
+
+ format_locus.nextc += format_string_pos;
+ if (!gfc_notify_std (GFC_STD_F2018,
+ "positive width required at %L",
+ _locus))
+ {
+ saved_token = u;
+ goto fail;
+ }
if (flag_dec_format_defaults)
{
/* Assume a default width based on the variable size. */
saved_token = u;
break;
}
-
- format_locus.nextc += format_string_pos;
- gfc_error ("Positive width required in format "
- "specifier %s at %L", token_to_string (t),
- _locus);
- saved_token = u;
- goto fail;
}
u = format_lex ();
diff --git a/gcc/testsuite/gfortran.dg/fmt_error_10.f b/gcc/testsuite/gfortran.dg/fmt_error_10.f
index 7ea6aec1220..6e1a5f60bea 100644
--- a/gcc/testsuite/gfortran.dg/fmt_error_10.f
+++ b/gcc/testsuite/gfortran.dg/fmt_error_10.f
@@ -18,9 +18,9 @@
str = '(1pd0.15)'
write (line,str,iostat=istat, iomsg=msg) 1.0d0
- if (istat.ne.5006 .or. msg(1:15).ne."Positive width ") STOP 5
+ if (line.ne."1.000") STOP 5
read (*,str,iostat=istat, iomsg=msg) x
- if (istat.ne.5006 .or. msg(1:15).ne."Positive width ") STOP 6
+ if (istat.ne.5006 .or. msg(1:10).ne."Zero width") STOP 6
if (x.ne.555.25) STOP 7
write (line,'(1pd24.15e11.3)') 1.0d0, 1.234
diff --git a/gcc/testsuite/gfortran.dg/fmt_error_7.f b/gcc/testsuite/gfortran.dg/fmt_error_7.f
index 9b5fba97e25..3937c8fe750 100644
--- a/gcc/testsuite/gfortran.dg/fmt_error_7.f
+++ b/gcc/testsuite/gfortran.dg/fmt_error_7.f
@@ -1,7 +1,9 @@
! { dg-do compile }
+! { dg-options "-std=f95" }
+
! PR37446 Diagnostic of edit descriptors, esp. EN
character(40) :: fmt_string
write(*, '(1P,2E12.4)') 1.0
- write(*,'(EN)') 5.0 ! { dg-error "Positive width required" }
+ write(*,'(EN)') 5.0 ! { dg-error "positive width required" }
write(*,'("abcdefg",EN6,"hjjklmnop")') 5.0 ! { dg-error "Period required" }
end
diff --git a/gcc/testsuite/gfortran.dg/fmt_error_9.f b/gcc/testsuite/gfortran.dg/fmt_error_9.f
index 1d677509e37..40c73599ac8 100644
--- a/gcc/testsuite/gfortran.dg/fmt_error_9.f
+++ b/gcc/testsuite/gfortran.dg/fmt_error_9.f
@@ -16,7 +16,7 @@
write (line,str,iostat=istat, iomsg=msg) 1.0d0
if (istat.ne.0) STOP 3
read (*,str,iostat=istat, iomsg=msg) x
- if (istat.ne.5006 .or. msg(1:15).ne."Positive width ") STOP 4
+ if (istat.ne.5006 .or. msg(1:10).ne."Zero width") STOP 4
if (x.ne.555.25) STOP 5
Re: [PATCH] PR fortran/91785 -- Set locus for inquiry parameter
On 10/1/19 5:06 PM, Steve Kargl wrote: The attached patch has been tested on x86_64-*-freebsd. OK to commit? Ok Steve, Thanks, Jerry The patch prevents an ICE by setting the locus of an inquiry parameter. 2019-10-01 Steven G. Kargl
Re: [PATCH] PR fortran/91784 -- Simplify EXPR_OP in conversion of constants
On 10/1/19 4:46 PM, Steve Kargl wrote: The attached patch has been tested on x86_64-*-freebsd. OK to commmit? OK, thanks Steve. In a previous patch, I specialized the simplfication of an EXPR_OP to the case of an inserted parenthesis. This was too restrictive as evidenced by the new test case. The patch simply does a simplification of an expression. 2019-10-01 Steven G. Kargl PR fortran/91784 * simplify.c (gfc_convert_constant): Simplify expression if the expression type is EXPR_OP. 2019-10-01 Steven G. Kargl PR fortran/91784 * gfortran.dg/pr91784.f90: New test.
Re: [PATCH] PR fortran/91942 -- Inquiry parameter cannot be IO tag
On 10/1/19 4:10 PM, Steve Kargl wrote: The attached patch has been tested on x86_64-*-freebsd. OK to commit? OK Steve, thanks, Jerry
Re: [PATCH] PR fortran/91802 -- rank+corank must be less than 16
On 9/28/19 10:11 AM, Steve Kargl wrote: Committed as r276254. I am getting this: gfc -c -fcoarray=single pr91802.f90 f951: internal compiler error: free_expr0(): Bad expr type 0x809fc9 gfc_report_diagnostic ../../trunk/gcc/fortran/error.c:776 0x80b62a gfc_internal_error(char const*, ...) ... I will do a rebuild and rerun in case I missed something. This is on x86_64-pc-linux-gnu. Jerry
Re: [patch, libgfortran] Bug 91593 - Implicit enum conversions in libgfortran/io/transfer.c
On 9/23/19 8:12 PM, Jerry DeLisle wrote:
On 9/23/19 8:52 AM, Bernhard Reutner-Fischer wrote:
On 22 September 2019 22:51:46 CEST, Jerry DeLisle wrote:
Hi all,
The attached patch eliminates several warnings by adjusting which
enumerator is
used in the subject offending code. I fixed this by adding an
enumerator at the
end of the file_mode definition. This then triggered a warning in
several other
places for an unhandled case in the switch statements. I cleared those
by
throwing in an assert (false) since it cant happen unless something
really goes
wrong somehow.
I'm curious why you assert (false) instead of the usual gcc_unreachable ()?
Thanks,
Because I forgot all about gcc_unreachable. I will give it a try.
Jerry
gcc_unreachable is only defined in the gfortran frontend and not the runtime.
Therefore, I added a define to io.h which invokes __builtin_unreachable and does
not use fancy_abort. I don't think we need anything fancy.
If no objections, I will commit the attached updated patch with a new ChangeLog.
Regression tested ok.
Regards,
Jerry
diff --git a/libgfortran/io/io.h b/libgfortran/io/io.h
index f5e63797ba1..bcd6dde9a5b 100644
--- a/libgfortran/io/io.h
+++ b/libgfortran/io/io.h
@@ -32,6 +32,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
#include
+#define gcc_unreachable() __builtin_unreachable ()
/* POSIX 2008 specifies that the extended locale stuff is found in
locale.h, but some systems have them in xlocale.h. */
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index c43360f6332..4c5e210ce5a 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -193,7 +193,8 @@ static const st_option async_opt[] = {
typedef enum
{ FORMATTED_SEQUENTIAL, UNFORMATTED_SEQUENTIAL,
- FORMATTED_DIRECT, UNFORMATTED_DIRECT, FORMATTED_STREAM, UNFORMATTED_STREAM
+ FORMATTED_DIRECT, UNFORMATTED_DIRECT, FORMATTED_STREAM,
+ UNFORMATTED_STREAM, FORMATTED_UNSPECIFIED
}
file_mode;
@@ -203,7 +204,7 @@ current_mode (st_parameter_dt *dtp)
{
file_mode m;
- m = FORM_UNSPECIFIED;
+ m = FORMATTED_UNSPECIFIED;
if (dtp->u.p.current_unit->flags.access == ACCESS_DIRECT)
{
@@ -1727,17 +1728,17 @@ formatted_transfer_scalar_read (st_parameter_dt *dtp, bt type, void *p, int kind
case FMT_S:
consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_S;
+ dtp->u.p.sign_status = SIGN_PROCDEFINED;
break;
case FMT_SS:
consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_SS;
+ dtp->u.p.sign_status = SIGN_SUPPRESS;
break;
case FMT_SP:
consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_SP;
+ dtp->u.p.sign_status = SIGN_PLUS;
break;
case FMT_BN:
@@ -2186,17 +2187,17 @@ formatted_transfer_scalar_write (st_parameter_dt *dtp, bt type, void *p, int kin
case FMT_S:
consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_S;
+ dtp->u.p.sign_status = SIGN_PROCDEFINED;
break;
case FMT_SS:
consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_SS;
+ dtp->u.p.sign_status = SIGN_SUPPRESS;
break;
case FMT_SP:
consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_SP;
+ dtp->u.p.sign_status = SIGN_PLUS;
break;
case FMT_BN:
@@ -2766,6 +2767,8 @@ pre_position (st_parameter_dt *dtp)
case UNFORMATTED_DIRECT:
dtp->u.p.current_unit->bytes_left = dtp->u.p.current_unit->recl;
break;
+case FORMATTED_UNSPECIFIED:
+ gcc_unreachable ();
}
dtp->u.p.current_unit->current_record = 1;
@@ -3637,6 +3640,8 @@ next_record_r (st_parameter_dt *dtp, int done)
while (p != '\n');
}
break;
+case FORMATTED_UNSPECIFIED:
+ gcc_unreachable ();
}
}
@@ -4002,6 +4007,8 @@ next_record_w (st_parameter_dt *dtp, int done)
}
break;
+case FORMATTED_UNSPECIFIED:
+ gcc_unreachable ();
io_error:
generate_error (>common, LIBERROR_OS, NULL);
Re: [patch, libgfortran] Bug 91593 - Implicit enum conversions in libgfortran/io/transfer.c
On 9/23/19 8:52 AM, Bernhard Reutner-Fischer wrote: On 22 September 2019 22:51:46 CEST, Jerry DeLisle wrote: Hi all, The attached patch eliminates several warnings by adjusting which enumerator is used in the subject offending code. I fixed this by adding an enumerator at the end of the file_mode definition. This then triggered a warning in several other places for an unhandled case in the switch statements. I cleared those by throwing in an assert (false) since it cant happen unless something really goes wrong somehow. I'm curious why you assert (false) instead of the usual gcc_unreachable ()? Thanks, Because I forgot all about gcc_unreachable. I will give it a try. Jerry
[patch, libgfortran] Bug 91593 - Implicit enum conversions in libgfortran/io/transfer.c
Hi all,
The attached patch eliminates several warnings by adjusting which enumerator is
used in the subject offending code. I fixed this by adding an enumerator at the
end of the file_mode definition. This then triggered a warning in several other
places for an unhandled case in the switch statements. I cleared those by
throwing in an assert (false) since it cant happen unless something really goes
wrong somehow.
Regardless, regression tested on x86_64-pc-linux-gnu.
OK for trunk? No applicable test case.
Jerry
2019-09-22 Jerry DeLisle
PR libfortran/91593
* io/transfer.c (file_mode, current_mode,
formatted_transfer_scalar_read, formatted_transfer_scalar_write,
pre_position, next_record_r, next_record_w): Add and use
FORMATTED_UNSPECIFIED to enumeration.
PS
While I was at it, I 'touched' all files in libgfortran/io to see what other
warnings are left, There is another odd warning I have not sorted out yet.
../../../trunk/libgfortran/io/read.c: In function ‘read_decimal’:
../../../trunk/libgfortran/io/read.c:641:9: warning: comparison of integer
expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and
‘int’ [-Wsign-compare]
641 | if (w == DEFAULT_WIDTH)
| ^~
In function ‘btoa_big’,
inlined from ‘write_b’ at ../../../trunk/libgfortran/io/write.c:1212:11:
../../../trunk/libgfortran/io/write.c:1051:6: warning: writing 1 byte into a
region of size 0 [-Wstringop-overflow=]
1051 | *q = '\0';
| ~~~^~
The first of these two I understand. The second one about region of size 0
puzzles me.
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index c43360f6332..3ba72a47d3e 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -32,6 +32,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
#include "format.h"
#include "unix.h"
#include "async.h"
+#include
#include
#include
@@ -193,7 +194,8 @@ static const st_option async_opt[] = {
typedef enum
{ FORMATTED_SEQUENTIAL, UNFORMATTED_SEQUENTIAL,
- FORMATTED_DIRECT, UNFORMATTED_DIRECT, FORMATTED_STREAM, UNFORMATTED_STREAM
+ FORMATTED_DIRECT, UNFORMATTED_DIRECT, FORMATTED_STREAM,
+ UNFORMATTED_STREAM, FORMATTED_UNSPECIFIED
}
file_mode;
@@ -203,7 +205,7 @@ current_mode (st_parameter_dt *dtp)
{
file_mode m;
- m = FORM_UNSPECIFIED;
+ m = FORMATTED_UNSPECIFIED;
if (dtp->u.p.current_unit->flags.access == ACCESS_DIRECT)
{
@@ -1727,17 +1729,17 @@ formatted_transfer_scalar_read (st_parameter_dt *dtp, bt type, void *p, int kind
case FMT_S:
consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_S;
+ dtp->u.p.sign_status = SIGN_PROCDEFINED;
break;
case FMT_SS:
consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_SS;
+ dtp->u.p.sign_status = SIGN_SUPPRESS;
break;
case FMT_SP:
consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_SP;
+ dtp->u.p.sign_status = SIGN_PLUS;
break;
case FMT_BN:
@@ -2186,17 +2188,17 @@ formatted_transfer_scalar_write (st_parameter_dt *dtp, bt type, void *p, int kin
case FMT_S:
consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_S;
+ dtp->u.p.sign_status = SIGN_PROCDEFINED;
break;
case FMT_SS:
consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_SS;
+ dtp->u.p.sign_status = SIGN_SUPPRESS;
break;
case FMT_SP:
consume_data_flag = 0;
- dtp->u.p.sign_status = SIGN_SP;
+ dtp->u.p.sign_status = SIGN_PLUS;
break;
case FMT_BN:
@@ -2766,6 +2768,8 @@ pre_position (st_parameter_dt *dtp)
case UNFORMATTED_DIRECT:
dtp->u.p.current_unit->bytes_left = dtp->u.p.current_unit->recl;
break;
+case FORMATTED_UNSPECIFIED:
+ assert (false); /* Should never happen. */
}
dtp->u.p.current_unit->current_record = 1;
@@ -3637,6 +3641,8 @@ next_record_r (st_parameter_dt *dtp, int done)
while (p != '\n');
}
break;
+case FORMATTED_UNSPECIFIED:
+ assert (false); /* Should never happen. */
}
}
@@ -4002,6 +4008,8 @@ next_record_w (st_parameter_dt *dtp, int done)
}
break;
+case FORMATTED_UNSPECIFIED:
+ assert (false); /* Should never happen. */
io_error:
generate_error (>common, LIBERROR_OS, NULL);
Re: [PATCH,fortran] Handle BOZ in accordance to Fortran 2018 standard
On 7/17/19 8:32 PM, Steve Kargl wrote: I will be away until Monday. Plenty of time for a review. ---snip -- Something not quite right here in this comment. +/* A BOZ literal constant can appear in a limited number of contexts. + gfc_invalid_boz() is a help function to simplify error/warning generation. + Note, gfortran accepts the nonstandard 'X' for 'Z' the nonstandard ^<<< in >>? + suffix location. If -fallow-invalid-boz is used, then issue a warning; + otherwise issue an error. */ --- snip + /* FIXME BOZ. What to do with complex? */ Is your question here regarding whether to treat the two real storage locations as one single area and pad? Or to duplicate one BOZ pattern into each? Or require two BOZ patterns to be provided? or something else? --- snip --- - + /* FIXME BOZ. */ if (!gfc_in_match_data () && (!gfc_notify_std(GFC_STD_F2003, "BOZ used outside a DATA " - "statement at %C"))) - return MATCH_ERROR; + "statement at %L", >where))) +return MATCH_ERROR; Maybe expand the comment a bit to better hint at the issue. --- snip --- The patch applies cleanly and tests OK on my machines here. I am very much in favor of deprecating LONG and SHORT which are way too ambiguous. I say OK to commit. Regards, Jerry
Re: [patch, fortran] Pr87233 Constraint C1279 still followed after f2008 standard revision
Could not get the use of gfc_get_errors to work right, it missed one of the errors in initialazation_30.f90. So I just did the deed. Regards, Jerry Committing to svn+ssh://jvdeli...@gcc.gnu.org/svn/gcc/trunk ... A gcc/testsuite/gfortran.dg/initialization_30.f90 M gcc/fortran/ChangeLog M gcc/fortran/expr.c M gcc/testsuite/ChangeLog M gcc/testsuite/gfortran.dg/initialization_14.f90 Committed r273484
[patch, fortran] Pr87233 Constraint C1279 still followed after f2008 standard revision
Hi all,
The attached patch removes the subject constraint for gfortran default and
-std=f2008/f2018. I had issues with repetitious errors. I tried to get rid of it
using the e->error = 1 method useded later in the function, but that did not
work, so I resorted to gfc_error_now which does the job.
Also modified one test case and added a new to cover this in the testsuite.
Regression tested on x86_64-pc-linux-gnu.
OK for trunk?
Regards,
Jerry
2019-07-13 Jerry DeLisle
PR fortran/87233
* expr.c (check_restricted): Relax constraint C1279 which was
removed from F2008 and above.
and
2019-07-13 Jerry DeLisle
PR fortran/87233
* gfortran.dg/initialization_14.f90: Modify to now pass by
remiving two dg-error commands. Added comments.
* gfortran.dg/initialization_30.f90: New test that includes the
two tests removed above with the 'dg-options -std=f95'.
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index ec9e3288b48..3b64b196c1b 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3305,11 +3305,13 @@ check_restricted (gfc_expr *e)
restricted expression in an elemental procedure, it will have
already been simplified away once we get here. Therefore we
don't need to jump through hoops to distinguish valid from
- invalid cases. */
- if (sym->attr.dummy && sym->ns == gfc_current_ns
+ invalid cases. Allowed in F2018. */
+ if (gfc_notification_std (GFC_STD_F2008)
+ && sym->attr.dummy && sym->ns == gfc_current_ns
&& sym->ns->proc_name && sym->ns->proc_name->attr.elemental)
{
- gfc_error ("Dummy argument %qs not allowed in expression at %L",
+ gfc_error_now ("Dummy argument %qs not "
+ "allowed in expression at %L",
sym->name, >where);
break;
}
diff --git a/gcc/testsuite/gfortran.dg/initialization_14.f90 b/gcc/testsuite/gfortran.dg/initialization_14.f90
index 4d5b6856cf0..aa1437719ac 100644
--- a/gcc/testsuite/gfortran.dg/initialization_14.f90
+++ b/gcc/testsuite/gfortran.dg/initialization_14.f90
@@ -3,18 +3,18 @@
! Dummy arguments are disallowed in initialization expressions in
! elemental functions except as arguments to the intrinsic functions
! BIT_SIZE, KIND, LEN, or to the numeric inquiry functions listed
-! in 13.11.8
+! in 13.11.8 F95, likewise not allowed in F2003, now allowed in F2008.
MODULE TT
INTEGER M
CONTAINS
ELEMENTAL REAL FUNCTION two(N)
INTEGER, INTENT(IN) :: N
- INTEGER, DIMENSION(N) :: scr ! { dg-error "Dummy argument 'n' not allowed in expression" }
+ INTEGER, DIMENSION(N) :: scr ! Now valid under F2008
END FUNCTION
ELEMENTAL REAL FUNCTION twopointfive(N)
INTEGER, INTENT(IN) :: N
- INTEGER, DIMENSION(MAX(N,2)) :: scr ! { dg-error "Dummy argument 'n' not allowed in expression" }
+ INTEGER, DIMENSION(MAX(N,2)) :: scr ! Now valid under F2008
end FUNCTION twopointfive
REAL FUNCTION three(N)
diff --git a/gcc/testsuite/gfortran.dg/initialization_30.f90 b/gcc/testsuite/gfortran.dg/initialization_30.f90
new file mode 100644
index 000..ff8436bc7c9
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/initialization_30.f90
@@ -0,0 +1,21 @@
+! { dg-do compile }
+! { dg-options "-std=f95" }
+! PR 20851
+! Dummy arguments are disallowed in initialization expressions in
+! elemental functions except as arguments to the intrinsic functions
+! BIT_SIZE, KIND, LEN, or to the numeric inquiry functions listed
+! in 13.11.8
+MODULE TT
+INTEGER M
+CONTAINS
+ ELEMENTAL REAL FUNCTION two(N)
+ INTEGER, INTENT(IN) :: N
+ INTEGER, DIMENSION(N) :: scr ! { dg-error "Dummy argument 'n' not allowed in expression" }
+ END FUNCTION
+
+ ELEMENTAL REAL FUNCTION twopointfive(N)
+ INTEGER, INTENT(IN) :: N
+ INTEGER, DIMENSION(MAX(N,2)) :: scr ! { dg-error "Dummy argument 'n' not allowed in expression" }
+ end FUNCTION twopointfive
+END MODULE
+END
Re: [PATCH, fortran] PR89782 READ/WRITE of a character array when it is a parameter
On 6/22/19 11:32 AM, Steve Kargl wrote:
On Sat, Jun 22, 2019 at 11:23:48AM -0700, Jerry DeLisle wrote:
2019-06-22 Jerry DeLisle
PR fortran/89782
* io.c (gfc_resolve_dt): Check that internal units are not
character PARAMETER.
This part of the patch is missing.
* gfortran.dg/io_constraints.f90: New test.
this part looks fine, but depends on the missing part.
Sorry about that, I missed the HEAD in "git diff HEAD".
Jerry
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index 425c2b86899..cd21c6bcf82 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -3328,6 +3328,14 @@ gfc_resolve_dt (gfc_dt *dt, locus *loc)
return false;
}
+ if (e->symtree && e->symtree->n.sym->attr.flavor == FL_PARAMETER
+ && e->ts.type == BT_CHARACTER)
+{
+ gfc_error ("UNIT specification at %L must "
+ "not be a character PARAMETER", >where);
+ return false;
+}
+
if (gfc_resolve_expr (e)
&& (e->ts.type != BT_INTEGER
&& (e->ts.type != BT_CHARACTER || e->expr_type != EXPR_VARIABLE)))
[PATCH, fortran] PR89782 READ/WRITE of a character array when it is a parameter
Hi all,
The front-end is not consistently checking for errors with character parameters
as internal units. The reason is we never actually checked for this before. In
some cases an error message is triggered from other unrelated causes or
sometimes no error is given at all.
This is fixed by the attached patch that adds the check in gfc_resolve_dt. I had
to place the check before the unit expression is resolved because somewhere in
gfc_resolve_expr the attribute information does not trigger for at least one
test case (lost?).
All cases I found are included in the test case. Regression tested on
x86_64-pc-linux-gnu.
OK for trunk?
Regards,
Jerry
2019-06-22 Jerry DeLisle
PR fortran/89782
* io.c (gfc_resolve_dt): Check that internal units are not
character PARAMETER.
* gfortran.dg/io_constraints.f90: New test.
! { dg-do compile }
program pr89782
character(len=*),parameter :: VALUES(*)=[character(len=10) :: 'NaN','NAN','nan','Inf','INF','inf','Infinity']
character(len=*),parameter :: VALUE='NaN'
real(4) :: var
do i=1,size(VALUES)
read(VALUES(i),*) float ! { dg-error "character PARAMETER" }
write(VALUES(i),*)float ! { dg-error "character PARAMETER" }
enddo
read(var,*)float! { dg-error "INTEGER expression or a CHARACTER" }
read(VALUE,*)float ! { dg-error "character PARAMETER" }
write(VALUE,*)float ! { dg-error "character PARAMETER" }
end program pr89782
Re: *ping* Re: [PATCH] PR fortran/89103 - Allow blank format items in format strings
I will see if I can get this one. On 6/17/19 6:37 AM, Mark Eggleston wrote: On 12/06/2019 19:11, Steve Kargl wrote: On Tue, Jun 11, 2019 at 11:50:40AM +0200, Jakub Jelinek wrote: On Tue, Jun 11, 2019 at 10:30:59AM +0100, Mark Eggleston wrote: Jim MacArthur Mark Eggleston Two spaces before < instead of one. This is not a patch review, just comments: Mark, do you plan to address any of Jakub's comments. Do note, I just 'OK' Jakub's patch that uses G_() forms for the strings. Now that Jakubs's patch has been committed, please find attached an updated patch and updated change logs: gcc/fortran Jim MacArthur Mark Eggleston PR fortran/89103 * gfortran.texi: Add -fdec-blank-format-item * invoke.texi: Add option to list of options. * invoke.texi: Add to section on Commas in FORMAT specifications. * io.c (check_format): At FMT_RPAREN goto finished if -fdec-blank-format-item otherwise set error string. * lang.opt: Add new option. * options.c (set_dec_flags): Add SET_BITFLAG for flag_dec_format_defaults. gcc/testsuite Jim MacArthur Mark Eggleston PR fortran/89103 * gfortran.dg/dec_format_empty_item_1.f: New test. * gfortran.dg/dec_format_empty_item_2.f: New test. * gfortran.dg/dec_format_empty_item_3.f: New test. as before... Please can someone commit this as do not have commit rights. Also, do you have plans to contribute additional patches (either for -fdec* extensions or preferrably to help with bug fixes and new features)? It may be advantageous for you to get a commit bit. Yes, I do intend to contribute additional patches, mostly -fdec- patches, there are also some patches unrelated to -fdec* extensions.
Re: [PATCH,Fortran] -- Check for overflow integer exponentation
On 6/14/19 3:56 PM, Steve Kargl wrote: I have had this patch in my tree since the beginning of May. During constant folding, gfortran would not issue an error for overflow for integer exponentation. Bootstrapped and regression tested multiple times on x86_64-*-freebsd? OK to commit? 2019-06-15 Steven G. Kargl * arith.c (arith_power): Rework overflow of an integer to an integer exponent. 2019-06-15 Steven G. Kargl * gfortran.dg/integer_exponentiation_4.f90: Update test. * gfortran.dg/integer_exponentiation_5.F90: Ditto. * gfortran.dg/no_range_check_1.f90: Ditto. OK, thanks Steve
Re: [PATCH] Add workaround for broken C/C++ wrappers to LAPACK (PR fortran/90329)
On 5/17/19 12:33 PM, Janne Blomqvist wrote: --- snip --- And yes, while I think one year might be a quite optimistic timeframe to get this fixed, I agree we shouldn't keep the workaround indefinitely either. I think the best way would be if CBLAS & LAPACKE would be fixed, and then we could tell people to use those rather than their own in-house broken interfaces. Thankyou for clarifying, so the real bug here is in CBLAS and LAPACK? Gads! Cheers, Jerry
Re: [PATCH] Add workaround for broken C/C++ wrappers to LAPACK (PR fortran/90329)
On 5/17/19 10:48 AM, Jeff Law wrote: On 5/16/19 2:09 AM, Jakub Jelinek wrote: Hi! Fortran subroutines/functions that have CHARACTER arguments have also hidden arguments at the end of the argument list which hold the string length. This is something all Fortran compilers I've tried do and is done in order to support calling unprototyped subroutines/functions where one can't know if the callee is using character(len=constant) or character(len=*) argument, where for the latter one has to pass the extra argument because there is no other way to propagate that info, while for the former it is kind of redundant but still part of the ABI; the compiler just uses the constant directly instead of asking about the real passed string length. Another thing is that until PR87689 has been fixed, the Fortran FE has been broken, used vararg-ish prototypes in most cases and that prevented (all?) tail call optimizations in the Fortran code. Apparently it is a common case that buggy C/C++ wrappers around the Fortran functions just ignore the ABI and don't pass the hidden string length arguments at all, which seemed to work fine in gfortran until recently (because the arguments weren't used). When we started making tail calls from such functions, this has of course changed, because when making a tail call we overwrite the caller's argument slots with the arguments we want to pass to the callee. Not really sure why it seemed to work with other compilers; trying https://fortran.godbolt.org/z/ckMt1t subroutine foo (a, b, c, d, e, f, g, h) integer :: b, c, d, e, f, g, h character(len=1) :: a call bar (a, b, c, d, e, f, g, h) end subroutine foo both older/new gfortran and ifort 19.0.0 emit a tail call which overwrites the hidden string length argument with 1, but when trying the https://fortran.godbolt.org/z/xpsH8e LAPACK routine, ifort for some reason doesn't tail call it. I'm not really happy to provide workarounds for undefined behavior, especially because that will mean it might take longer if ever if those buggy programs are fixed. On the other side, the PR87689 bug fix has been backported to all release branches and so now not only trunk, but also 9.1, 8.3.1 and 7.4.1 are affected. Instead of trying to disable all tail calls, this patch disables tail calls from functions/subroutines that have those hidden string length arguments and don't use character(len=*) (in that case the function wouldn't seem to work previously either, because the argument is really used), where those hidden string length arguments are passed on the stack and where the tail callee also would want to pass arguments on the stack (if we spent even more time on this, we could narrow it down further and check if the tail call would actually store anything overlapping the hidden string length arguments on the stack). This workaround probably needs guarding with some Fortran FE specific option, so that it can be disabled, will defer that to the Fortran maintainers. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and release branches (not sure about LTO on the release branches, does one need to bump anything when changing the LTO format by streaming another bit)? 2019-05-16 Jakub Jelinek PR fortran/90329 * tree-core.h (struct tree_decl_common): Document decl_nonshareable_flag for PARM_DECLs. * tree.h (DECL_HIDDEN_STRING_LENGTH): Define. * calls.c (expand_call): Don't try tail call if caller has any DECL_HIDDEN_STRING_LENGTH PARM_DECLs that are or might be passed on the stack and callee needs to pass any arguments on the stack. * tree-streamer-in.c (unpack_ts_decl_common_value_fields): Use else if instead of series of mutually exclusive ifs. Handle DECL_HIDDEN_STRING_LENGTH for PARM_DECLs. * tree-streamer-out.c (pack_ts_decl_common_value_fields): Likewise. * trans-decl.c (create_function_arglist): Set DECL_HIDDEN_STRING_LENGTH on hidden string length PARM_DECLs if len is constant. My first, second and third thought has been we shouldn't be catering to code that is so clearly broken. Maybe we could do this on the release branches which would in turn give folks roughly a year to fix up this mess? jeff Not that I have much say, but I have been following this thread and the others about broken wrappers and screwed up prototypes being used by R for there use of LAPACK. I have been holding off saying anything. I don't thing we should be doing anything in gfortran at all. I think the R people need to fix their calls. People get caught by not following the proper conventions and then want the compiler to fix it. Its not the compiler writers job to fix users bad code. The Fortran conventions of having the string lengths appended to the end has been known for many many years and well documented everywhere. Sorry for ranting and I understand everyone is just trying to do the right
Re: [patch, fortran] Fix pointers not escaping via C_PTR
On 2/28/19 12:14 PM, Thomas Koenig wrote: Hello world, the attached patch fixes a wrong-code bug for gfortran where pointers were not marked as escaping. A C_PTR can be stashed away and reused later (at least as long as the variable it points to remains active). This is not a regression, but IMHO a bad wrong-code bug. The chances of this patch introducing regressions are really, really low. Regression-tested. OK for trunk? This is Ok except the test case. You are using dg-run but are not testing for any condition. I think you want to to IF STOP instead of printing some test values or dou you just want dg-conpile? Fix test case and OK for trunk. Jerry
Re: [patch, fortran] Fix the rest of PR 71203
On 3/9/19 4:44 AM, Thomas König wrote: Hello world, the attached patch fixes the rest of PR 71203 (i.e. the non-character parts). I have checked in gdb that the shape set with this patch does indeed not create a memory leak. Regression-tested. OK for trunk? (This makes three patches that are currently awaiting review, the other two are https://gcc.gnu.org/ml/fortran/2019-03/msg00022.html and https://gcc.gnu.org/ml/fortran/2019-02/msg00241.html. I'd appreciate somebody looking at these, I think I am close to the limit of concurrent patches in my tree :-) This one looks good to go. Looking at the others. Jerry
[PATCH, libgfortran] PR83387 Defined output does not work for a derived type that has no components
This patch is simple and obvious.
Regression tested on x86_64-pc-linux-gnu.
Test case attached. (Changelog for test case will be included)
I will commit tomorrow.
Regards,
Jerry
2019-02-23 Jerry DeLisle
PR fortran/84387
* trans-io.c (transfer_expr): Do not return if there are no
components to the derived type or class.
diff --git a/gcc/fortran/trans-io.c b/gcc/fortran/trans-io.c
index 9a13af4a630..9e7071dc121 100644
--- a/gcc/fortran/trans-io.c
+++ b/gcc/fortran/trans-io.c
@@ -2407,8 +2407,6 @@ transfer_expr (gfc_se * se, gfc_typespec * ts, tree
addr_expr,
case_bt_struct:
case BT_CLASS:
- if (ts->u.derived->components == NULL)
- return;
if (gfc_bt_struct (ts->type) || ts->type == BT_CLASS)
{
gfc_symbol *derived;
! { dg-do run }
! PR84387 Defined output does not work for a derived type that
! has no components
module m
type :: t
private
!integer :: m_i = 0 !<-- ***
contains
private
procedure, pass(this) :: write_t
generic, public :: write(formatted) => write_t
end type
contains
subroutine write_t(this, lun, iotype, vlist, istat, imsg)
! argument definitions
class(t), intent(in):: this
integer, intent(in) :: lun
character(len=*), intent(in):: iotype
integer, intent(in) :: vlist(:)
integer, intent(out):: istat
character(len=*), intent(inout) :: imsg
write(lun, fmt=*, iostat=istat, iomsg=imsg) "Hello World!"
return
end subroutine write_t
end module
program p
use m, only : t
type(t) :: foo
print "(dt)", foo ! { dg-output " Hello World!" }
end program
Re: [PR fortran/83057, patch] - OPEN without a filename and without STATUS='SCRATCH' could produce a warning
On 2/20/19 2:34 PM, Harald Anlauf wrote: There was a rather obvious bug in the logic for checking the arguments to the OPEN statement when NEWUNIT= was specified, which prohibited the generation of the appropriate error message. Regtested successfully. OK for trunk? Yes and thanks for patch. Jerry
Re: [PR fortran/88248, patch] - [F18] Bogus warning about obsolescent feature: Labeled DO statement
On 2/13/19 2:38 PM, Harald Anlauf wrote: The attached patch moves the check for labeled DO statements to the place where a label is referenced instead of where a label was defined, which lead to false positives. Regtested on x86_64-pc-linux-gnu. OK for trunk? Thanks Harald, All OK with test case. Jerry
Re: [PATCH] Fix -fdec simplification (PR fortran/88649).
On 2/12/19 10:22 PM, Martin Liška wrote: PING^1. On 2/4/19 1:46 PM, Martin Liška wrote: On 2/4/19 10:56 AM, Martin Liška wrote: Hi. Starting from r266926 'switch (e->value.op.op)' is reached when one using -fdec. That's wrong as -fdec causes to create a e->value.function. I hope the proper fix is to skip the mentioned patch and allow simplification at the end of the function? Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin Yes, OK gcc/fortran/ChangeLog: 2019-01-25 Martin Liska PR fortran/88649 * resolve.c (resolve_operator): Initialize 't' right after function entry. Skip switch (e->value.op.op) for -fdec operands that become function calls. --- gcc/fortran/resolve.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) I forgot to include fortran ML. Martin
[patch, fortran] PR52564 Accepts invalid: Missing I/O list after comma
The attached patch is straight-forward and self explanatory.
Regression tested on x86-64-pc-linux-gnu. Test case attached.
OK for trunk?
2019-01-31 Jerry DeLisle
PR fortran/52564
* io.c (match_io): Add check for comma after '*' without subsequent
IO list.
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index fce9228c302..95b30132203 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -4172,6 +4172,23 @@ match_io (io_kind k)
else
gfc_current_locus = where;
}
+
+ if (gfc_match_char ('*') == MATCH_YES
+ && gfc_match_char(',') == MATCH_YES)
+ {
+ locus where2 = gfc_current_locus;
+ if (gfc_match_eos () == MATCH_YES)
+ {
+ gfc_current_locus = where2;
+ gfc_error ("Comma after * at %C not allowed without I/O list");
+ m = MATCH_ERROR;
+ goto cleanup;
+ }
+ else
+ gfc_current_locus = where;
+ }
+ else
+ gfc_current_locus = where;
}
if (gfc_current_form == FORM_FREE)
! { dg-do compile }
! PR52564 Accepts invalid: Missing I/O list after comma
program printbug
print *, 'hello world'
! the following line should not compile:
print *, ! { dg-error "not allowed" }
end program
Re: [patch, libgfortran, committed] PR89020
On 1/27/19 1:13 AM, Janne Blomqvist wrote: On Sat, Jan 26, 2019 at 10:42 PM Jerry DeLisle --- snip --- Checking remove() for an error is a good idea, although speculating why that happened might be confusing if the error happens for some other reason? Particularly so on POSIX systems, where deleting open files is explicitly part of the design. In generate_error(), we already call gf_strerror() to translate errno to a string, which should give a more accurate description of what went wrong? So maybe just say "File cannot be deleted"? And yes, as mentioned in the PR, the second remove should "remove (path)" and not "u->filename". -- Janne Blomqvist Hi Janne, Yes, I fixed the path mistake last nite. I almost changed that error message for the reasons you suggest. I will go ahead and do this later today. Thanks for your suggestions. Jerry
[patch, libgfortran, committed] PR89020
Committed as simple and obvious. (With a ChangeLog Bobble fixed)
Regression tested on x86_64.
Committed r268301
M libgfortran/ChangeLog
M libgfortran/io/close.c
Regards,
Jerry
2019-01-26 Jerry DeLisle
PR libfortran/89020
* io/close.c (st_close): Generate error if calls to 'remove'
return an error.
diff --git a/libgfortran/io/close.c b/libgfortran/io/close.c
index cbcbf4e71a1..2b35e49c9cc 100644
--- a/libgfortran/io/close.c
+++ b/libgfortran/io/close.c
@@ -99,7 +99,11 @@ st_close (st_parameter_close *clp)
else
{
#if HAVE_UNLINK_OPEN_FILE
- remove (u->filename);
+
+ if (remove (u->filename))
+ generate_error (>common, LIBERROR_OS,
+ "File cannot be deleted, possibly in use by"
+ " another process");
#else
path = strdup (u->filename);
#endif
@@ -112,7 +116,10 @@ st_close (st_parameter_close *clp)
#if !HAVE_UNLINK_OPEN_FILE
if (path != NULL)
{
- remove (path);
+ if (remove (u->filename))
+ generate_error (>common, LIBERROR_OS,
+ "File cannot be deleted, possibly in use by"
+ " another process");
free (path);
}
#endif
Re: [patch, fortran] Fix contiguous dummy arguments
On 1/19/19 7:05 AM, Thomas Koenig wrote: Hello world, the attached patch fixes handling of contiguous dummy arguments when the actual arguments are not contiguous. The patch to trans-expr.c itself was written by Paul and attached to the PR. I just added the test case. Regression-testing revealed some failing scan-tree tests due to different code being generated. I put corresponding run time tests into the new test case to make sure that no wrong code is being generated. I have also tested the new test case and the compiler with valgrind. OK for trunk? Looks OK Jerry
Re: [patch,libgfortran] PR88776 Namelist read from stdin: loss of data
On 1/12/19 2:35 PM, Jerry DeLisle wrote:
Hi all,
As stated in the PR, the problem turns out to be an ungraceful return
after an error. Most namelist errors go through nml_err_ret, The one I
am removing did not and in the unique case of UNIT=5 after the error it
falls through and hits some code which modifies pointers to the namelist
data structures.
This patch fixes it.
Regression tested on x86-64 and manually tested with a redirection to
stdin. (cat somefile | ./a.out )
I plan to commit today as simple along with a new testcase.
Regards.
Jerry
2019-01-12 Jerry DeLisle
PR libfortran/88776
* io/list_read.c (namelist_read): Use nml_err_ret path on
read error, not based on stdin_unit.
Committed.
While doing extra testing on the test case for this PR, I noticed a
memory leak with valgrind.
The attached patch fixes this. The problem is when opening a file with a
preconnected unit, the previously initialized format buffer (fbuf) in
the preconnected unit structure gets abandoned (pointer overwritten by
the new fbuf), and a new one allocated later in the code path.
I will commit this additional patch and the test case as simple and obvious.
Regression tested on x86_64. Valgrind clean.
Regards,
Jerry
2019-01-13 Jerry DeLisle
PR libfortran/88776
* io/open.c (newunit): Free format buffer if the unit specified is
for stdin, stdout, or stderr.
2019-01-13 Jerry DeLisle
PR libfortran/88776
* gfortran.dg/namelist_96.f90: New test.
diff --git a/libgfortran/io/open.c b/libgfortran/io/open.c
index 97fb17c7424..b48afabf7a3 100644
--- a/libgfortran/io/open.c
+++ b/libgfortran/io/open.c
@@ -530,6 +530,14 @@ new_unit (st_parameter_open *opp, gfc_unit *u, unit_flags *flags)
if (u2 != NULL)
unlock_unit (u2);
+ /* If the unit specified is preconnected with a file specified to be open,
+ then clear the format buffer. */
+ if ((opp->common.unit == options.stdin_unit ||
+ opp->common.unit == options.stdout_unit ||
+ opp->common.unit == options.stderr_unit)
+ && (opp->common.flags & IOPARM_OPEN_HAS_FILE) != 0)
+fbuf_destroy (u);
+
/* Open file. */
s = open_external (opp, flags);
! ( dg-do run }
program pr88776
implicit none
character(*), parameter :: file = "pr88776.dat"
type t_chan
integer :: ichan = -1
character(len=8) :: flag = ''
integer :: band = -1
end type t_chan
type(t_chan) :: chan
namelist /NML/ chan
open (11,file=file)
write(11,'(a)') trim(" chan = 1 '#1 '10 /")
write(11,'(a)') trim(" chan = 2 '#2 '42.36/")
write(11,'(a)') trim(" chan = 3 '#3 '30 /")
close(11)
call read (unit=10) ! No problem
call read (unit=5) ! problem, now fixed
open (11,file=file)
close (11, status="delete")
contains
subroutine read (unit)
integer, intent(in) :: unit
integer :: stat
open (unit, file=file, action="read")
chan = t_chan(-1,'',-1)
stat = 0
read (unit, nml=NML, iostat=stat)
if (stat /= 0) stop 1
chan = t_chan(-1,'',-1)
read (unit, nml=NML, iostat=stat)
if (stat == 0) stop 2
if (chan% ichan /= 2) then
stop 3
end if
close (unit)
end subroutine read
end program pr88776
[patch,libgfortran] PR88776 Namelist read from stdin: loss of data
Hi all,
As stated in the PR, the problem turns out to be an ungraceful return
after an error. Most namelist errors go through nml_err_ret, The one I
am removing did not and in the unique case of UNIT=5 after the error it
falls through and hits some code which modifies pointers to the namelist
data structures.
This patch fixes it.
Regression tested on x86-64 and manually tested with a redirection to
stdin. (cat somefile | ./a.out )
I plan to commit today as simple along with a new testcase.
Regards.
Jerry
2019-01-12 Jerry DeLisle
PR libfortran/88776
* io/list_read.c (namelist_read): Use nml_err_ret path on
read error, not based on stdin_unit.
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 4a7ccb3ddd5..d9af255a034 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -3614,11 +3614,7 @@ find_nml_name:
while (!dtp->u.p.input_complete)
{
if (!nml_get_obj_data (dtp, _nl, nml_err_msg, sizeof nml_err_msg))
- {
- if (dtp->u.p.current_unit->unit_number != options.stdin_unit)
- goto nml_err_ret;
- generate_error (>common, LIBERROR_READ_VALUE, nml_err_msg);
-}
+ goto nml_err_ret;
/* Reset the previous namelist pointer if we know we are not going
to be doing multiple reads within a single namelist object. */
Re: [PATCH,fortran] Add support for IEEE_SUBNORMAL
On 12/28/18 10:44 AM, Steve Kargl wrote:
Ping.
OK, thanks.
Jerry
On Tue, Dec 25, 2018 at 02:36:40PM -0800, Steve Kargl wrote:
Fortran 2018 has added IEEE_SUBNORMAL, IEEE_POSITIVE_SUBNORMAL, and
IEEE_NEGATIVE_SUBNORMAL as counterparts the same features with the
DENORMAL name. The attached patch allows gfortran to recognize
and do the right thing with these featuers. OK to commit?
2018-12-25 Steven G. Kargl
* expr.c (external_spec_function): Add ieee_support_subnormal to list
of IEEE inquiry functions.
2018-12-25 Steven G. Kargl
* gfortran.map: Expose subnormal functions in dynamic
library.
* ieee/ieee_arithmetic.F90: Add support for IEEE_SUBNORMAL,
IEEE_POSITIVE_SUBNORMAL, and IEEE_NEGATIVE_SUBNORMAL.
* ieee/ieee_helper.c: Ditto.
* ieee/ieee_features.F90: Add IEEE_SUBNORMAL.
--
Steve
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 267418)
+++ gcc/fortran/expr.c (working copy)
@@ -3061,6 +3061,7 @@ external_spec_function (gfc_expr *e)
|| !strcmp (f->name, "ieee_support_halting")
|| !strcmp (f->name, "ieee_support_datatype")
|| !strcmp (f->name, "ieee_support_denormal")
+ || !strcmp (f->name, "ieee_support_subnormal")
|| !strcmp (f->name, "ieee_support_divide")
|| !strcmp (f->name, "ieee_support_inf")
|| !strcmp (f->name, "ieee_support_io")
Index: libgfortran/gfortran.map
===
--- libgfortran/gfortran.map(revision 267418)
+++ libgfortran/gfortran.map(working copy)
@@ -1573,4 +1573,9 @@ GFORTRAN_9 {
_gfortran_sfindloc2_s1;
_gfortran_sfindloc2_s4;
_gfortran_st_wait_async;
+ __ieee_arithmetic_MOD_ieee_support_subnormal_10;
+ __ieee_arithmetic_MOD_ieee_support_subnormal_16;
+ __ieee_arithmetic_MOD_ieee_support_subnormal_4;
+ __ieee_arithmetic_MOD_ieee_support_subnormal_8;
+ __ieee_arithmetic_MOD_ieee_support_subnormal_noarg;
};
Index: libgfortran/ieee/ieee_arithmetic.F90
===
--- libgfortran/ieee/ieee_arithmetic.F90(revision 267418)
+++ libgfortran/ieee/ieee_arithmetic.F90(working copy)
@@ -55,9 +55,11 @@ module IEEE_ARITHMETIC
IEEE_NEGATIVE_INF = IEEE_CLASS_TYPE(3), &
IEEE_NEGATIVE_NORMAL = IEEE_CLASS_TYPE(4), &
IEEE_NEGATIVE_DENORMAL = IEEE_CLASS_TYPE(5), &
+IEEE_NEGATIVE_SUBNORMAL= IEEE_CLASS_TYPE(5), &
IEEE_NEGATIVE_ZERO = IEEE_CLASS_TYPE(6), &
IEEE_POSITIVE_ZERO = IEEE_CLASS_TYPE(7), &
IEEE_POSITIVE_DENORMAL = IEEE_CLASS_TYPE(8), &
+IEEE_POSITIVE_SUBNORMAL= IEEE_CLASS_TYPE(8), &
IEEE_POSITIVE_NORMAL = IEEE_CLASS_TYPE(9), &
IEEE_POSITIVE_INF = IEEE_CLASS_TYPE(10)
@@ -795,6 +797,7 @@ REM_MACRO(4,4,4)
SUPPORTGENERIC(IEEE_SUPPORT_DATATYPE)
SUPPORTGENERIC(IEEE_SUPPORT_DENORMAL)
+SUPPORTGENERIC(IEEE_SUPPORT_SUBNORMAL)
SUPPORTGENERIC(IEEE_SUPPORT_DIVIDE)
SUPPORTGENERIC(IEEE_SUPPORT_INF)
SUPPORTGENERIC(IEEE_SUPPORT_IO)
@@ -1243,7 +1362,7 @@ SUPPORTMACRO(IEEE_SUPPORT_DATATYPE,16,.true.)
#endif
SUPPORTMACRO_NOARG(IEEE_SUPPORT_DATATYPE,.true.)
-! IEEE_SUPPORT_DENORMAL
+! IEEE_SUPPORT_DENORMAL and IEEE_SUPPORT_SUBNORMAL
SUPPORTMACRO(IEEE_SUPPORT_DENORMAL,4,.true.)
SUPPORTMACRO(IEEE_SUPPORT_DENORMAL,8,.true.)
@@ -1254,6 +1373,16 @@ SUPPORTMACRO(IEEE_SUPPORT_DENORMAL,10,.true.)
SUPPORTMACRO(IEEE_SUPPORT_DENORMAL,16,.true.)
#endif
SUPPORTMACRO_NOARG(IEEE_SUPPORT_DENORMAL,.true.)
+
+SUPPORTMACRO(IEEE_SUPPORT_SUBNORMAL,4,.true.)
+SUPPORTMACRO(IEEE_SUPPORT_SUBNORMAL,8,.true.)
+#ifdef HAVE_GFC_REAL_10
+SUPPORTMACRO(IEEE_SUPPORT_SUBNORMAL,10,.true.)
+#endif
+#ifdef HAVE_GFC_REAL_16
+SUPPORTMACRO(IEEE_SUPPORT_SUBNORMAL,16,.true.)
+#endif
+SUPPORTMACRO_NOARG(IEEE_SUPPORT_SUBNORMAL,.true.)
! IEEE_SUPPORT_DIVIDE
Index: libgfortran/ieee/ieee_features.F90
===
--- libgfortran/ieee/ieee_features.F90 (revision 267418)
+++ libgfortran/ieee/ieee_features.F90 (working copy)
@@ -36,6 +36,7 @@ module IEEE_FEATURES
type(IEEE_FEATURES_TYPE), parameter, public :: &
IEEE_DATATYPE = IEEE_FEATURES_TYPE(0), &
IEEE_DENORMAL = IEEE_FEATURES_TYPE(1), &
+IEEE_SUBNORMAL = IEEE_FEATURES_TYPE(1), &
IEEE_DIVIDE = IEEE_FEATURES_TYPE(2), &
IEEE_HALTING= IEEE_FEATURES_TYPE(3), &
IEEE_INEXACT_FLAG = IEEE_FEATURES_TYPE(4), &
Index: libgfortran/ieee/ieee_helper.c
===
--- libgfortran/ieee/ieee_helper.c (revision 267418)
+++ libgfortran/ieee/ieee_helper.c (working copy)
@@ -50,7 +50,8 @@ internal_proto(ieee_class_helper_16);
enum { IEEE_OTHER_VALUE = 0, IEEE_SIGNALING_NAN, IEEE_QUIET_NAN,
IEEE_NEGATIVE_INF,
Re: [PATCH,fortran] Add pre-defined macros for different available types
OK Steve,
Jerry
On 12/28/18 10:43 AM, Steve Kargl wrote:
Ping.
On Tue, Dec 25, 2018 at 01:44:10PM -0800, Steve Kargl wrote:
Here's a Holiday present for Fortranners.
2018-12-25 Steven G. Kargl
* cpp.c (gfc_cpp_init): Add pre-defined macros for INTEGER(1)
INTEGER(2), INTEGER(8) and INTEGER(16) if supported. Add pre-defined
macros for REAL(10) and REAL(16) if available.
* gfortran.texi: Document new macros.
As a Fortran compiler is required to have default integer kind,
default real kind, and double precision, I did not include macros
for these types (ie., there are no __GFC_INTEGER_4__, __GFC_REAL_4__,
and __GFC_REAL_8__).
This allows code like
% cat a.F90
program foo
#ifdef __GFC_REAL_16__
real(16) x
x = 1
print *, x
#endif
end program foo
% gfcx -o z a.F90 && ./z
1.000
--
Steve
Index: gcc/fortran/cpp.c
===
--- gcc/fortran/cpp.c (revision 267418)
+++ gcc/fortran/cpp.c (working copy)
@@ -570,6 +570,8 @@ void
gfc_cpp_init (void)
{
int i;
+ gfc_integer_info *int_info;
+ gfc_real_info *real_info;
if (gfc_option.flag_preprocessed)
return;
@@ -607,6 +609,26 @@ gfc_cpp_init (void)
else if (opt->code == OPT_MT || opt->code == OPT_MQ)
deps_add_target (cpp_get_deps (cpp_in),
opt->arg, opt->code == OPT_MQ);
+}
+
+ for (int_info = gfc_integer_kinds; int_info->kind != 0; int_info++)
+{
+ if (int_info->kind == 1)
+ cpp_define (cpp_in, "__GFC_INT_1__=1");
+ if (int_info->kind == 2)
+ cpp_define (cpp_in, "__GFC_INT_2__=1");
+ if (int_info->kind == 8)
+ cpp_define (cpp_in, "__GFC_INT_8__=1");
+ if (int_info->kind == 8)
+ cpp_define (cpp_in, "__GFC_INT_16__=1");
+}
+
+ for (real_info = gfc_real_kinds; real_info->kind != 0; real_info++)
+{
+ if (real_info->kind == 10)
+ cpp_define (cpp_in, "__GFC_REAL_10__=1");
+ if (real_info->kind == 16)
+ cpp_define (cpp_in, "__GFC_REAL_16__=1");
}
if (gfc_cpp_option.working_directory
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi (revision 267418)
+++ gcc/fortran/gfortran.texi (working copy)
@@ -418,9 +418,17 @@ statement, the included file is not preprocessed. To
files, use the equivalent preprocessor statement @code{#include}.
If GNU Fortran invokes the preprocessor, @code{__GFORTRAN__}
-is defined and @code{__GNUC__}, @code{__GNUC_MINOR__} and
+is defined. The macros @code{__GNUC__}, @code{__GNUC_MINOR__} and
@code{__GNUC_PATCHLEVEL__} can be used to determine the version of the
compiler. See @ref{Top,,Overview,cpp,The C Preprocessor} for details.
+
+GNU Fortran supports a number of @code{INTEGER} and @code{REAL} kind types
+in additional to the kind types required by the Fortran standard.
+The availability of any given kind type is architecture dependent. The
+following pre-defined preprocessor macros can be used to conditional
+include code for these additional kind types: @code{__GFC_INTEGER_1__},
+@code{__GFC_INTEGER_2__}, @code{__GFC_INTEGER_8__}, @code{__GFC_INTEGER_16__},
+@code{__GFC_REAL_10__}, and @code{__GFC_REAL_16__}.
While CPP is the de-facto standard for preprocessing Fortran code,
Part 3 of the Fortran 95 standard (ISO/IEC 1539-3:1998) defines
Re: [PATCH] fortran/88342 -- interaction of -ffpe-trap and IEEE_VALUE
On 12/28/18 10:43 AM, Steve Kargl wrote: Ping. On Mon, Dec 24, 2018 at 11:59:50AM -0800, Steve Kargl wrote: All, The IEEE modules and -ffpe-trap are to some extent orthogonal features of gfortran. Unfortunately, some users have the expectation of using -ffpe-trap for debugging while also using only some of the mechanisms provided by the IEEE modules. For example, % t.f90 program test use, intrinsic :: ieee_arithmetic real :: inf inf = ieee_value(inf, ieee_positive_inf) end program test % gfc8 -o z -ffpe-trap=overflow t.f90 && ./z Floating exception (core dumped) The correct use of the module would be along the lines of program test use, intrinsic :: ieee_arithmetic real :: inf logical h call ieee_get_halting_mode(ieee_overflow, h) ! store halting mode call ieee_set_halting_mode(ieee_overflow, .false.) ! no halting inf = ieee_value(inf, ieee_positive_inf) call ieee_set_halting_mode(ieee_overflow, h) ! restore halting mode end program test Technically (as I have done in the patch), the user should also use 'ieee_support_halting(ieee_overflow)', but that's just a detail. Now, IEEE_VALUE() is specifically included in the Fortran standard to allow it to provide qNaN, sNaN, +inf, and -inf (among a few other questionable constants). The attached patch allows gfortran to generate an executable that does not abort with SIGFPE. 2018-12-24 Steven G. Kargl PR fortran/88342 * ieee/ieee_arithmetic.F90: Prevent exceptions in IEEE_VALUE if -ffpe-trap=invalid or -ffpe-trap=overflow is used. 2018-12-24 Steven G. Kargl PR fortran/88342 * gfortran.dg/ieee/ieee_10.f90: New test. Regression tested on i586-*-freebsd and x86_64-*-freebsd. OK to commit? OK Steve, thanks. Jerry
Re: [PATCH] PR fortran/81509 and fortran/45513
On 12/23/18 10:49 AM, Steve Kargl wrote: This is a re-submission of a patch I submitted 15 months ago. See https://gcc.gnu.org/ml/fortran/2017-09/msg00124.html At that time one reviewer OK'd the patch for committing, and one reviewer raised objections to the patch as I chose to remove dubious extensions to the Fortran standard. I withdrew that patch with the expection that Someone would fix the bug. Well, Someone has not materialized. The patch has been retested on i586-*-freebsd and x86_64-*-freebsd. OK to commit as-is? I say OK to commit. Here's the text from the above URL. In short, F2008 now allows boz-literal-constants in IAND, IOR, IEOR, DSHIFTL, DSHIFTR, and MERGE_BITS. gfortran currently allows a BOZ argument, but she was not enforcing restrictions in F2008. The attach patch causes gfortran to conform to F2008. As a side effect, the patch removes a questionable GNU Fortran extension that allowed arguments to IAND, IOR, and IEOR to have different kind type parameters. The behavior of this extension was not documented. 2017-09-27 Steven G. Kargl PR fortran/45513 PR fortran/81509 * check.c: Rename function gfc_check_iand to gfc_check_iand_ieor_ior. * check.c (boz_args_check): New function. Check I and J not both BOZ. (gfc_check_dshift,gfc_check_iand_ieor_ior, gfc_check_ishft, gfc_check_and, gfc_check_merge_bits): Use it. * check.c (gfc_check_iand_ieor_ior): Force conversion of BOZ to kind type of other agrument. Remove silly GNU extension. (gfc_check_ieor, gfc_check_ior): Delete now unused functions. * intrinsic.c (add_functions): Use gfc_check_iand_ieor_ior. Wrap long line. * intrinsic.h: Rename gfc_check_iand to gfc_check_iand_ieor_ior. Delete prototype for bool gfc_check_ieor and gfc_check_ior * intrinsic.texi: Update documentation for boz-literal-constant. 2017-09-27 Steven G. Kargl PR fortran/45513 PR fortran/81509 * gfortran.dg/graphite/id-26.f03: Fix non-conforming use of IAND. * gfortran.dg/pr81509_1.f90: New test. * gfortran.dg/pr81509_2.f90: New test.
Re: [patch, fortran] Fix PR 88411, wrong code with async I/O
On 12/9/18 8:11 AM, Thomas Koenig wrote: Hello world, the attached patch fixes the wrong-code regression by changing the way synchronous writes are handled on files using asynchronous I/O: The are now handled synchronously. This also means that two places where a wait instruction was issued in such a case are no longer needed. I tried to construct a failing test case for this new behavior, but failed :-) Regression-tested. OK for trunk? Looks good Thomas, thanks for quick fix. Jerry
Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)
On 12/6/18 2:33 AM, Jakub Jelinek wrote: On Wed, Dec 05, 2018 at 06:27:00PM -0800, Jerry DeLisle wrote: I disagree completely. I assume the idea of -fdec-pad-with-spaces is to accomodate some old dec fortran code. The only reason to use some other character is if someone is writing new dec fortran code, which is implying encouraging people to be writing non standard conforming code. Even if it is conforming in the sense that it is processor dependent you are encouraging people to create new non portable code across compilers. Please just stay consistent with Intel. So do you prefer to always use ' ' instead of '\0', or decide based on -fdec without a separate option controlling that? Keep current default of '\0' and use ' ' when -fdec given. Regards, Jerry
Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)
On 12/4/18 9:04 AM, Fritz Reese wrote: On Tue, Dec 4, 2018 at 10:12 AM Jakub Jelinek wrote: Just a couple of random comments. -fdec-pad-with-spaces option name doesn't look right, because it doesn't say what the option affects. So perhaps have transfer in the option name? [...] Wouldn't it be better to allow specifying whatever character you want to pad with, so that users can choose something even different? I concur with this. In that case some option like -ftransfer-pad-char= may be a more appriopriate name, where -fdec may enable a default transfer-pad-char of \x20 rather than \x00. I disagree completely. I assume the idea of -fdec-pad-with-spaces is to accomodate some old dec fortran code. The only reason to use some other character is if someone is writing new dec fortran code, which is implying encouraging people to be writing non standard conforming code. Even if it is conforming in the sense that it is processor dependent you are encouraging people to create new non portable code across compilers. Please just stay consistent with Intel. This whole padding business just stinks to me. There are better ways to accomplish these results without using transfer to convert ascii strings into bit patterns or whatever the heck some programmer is trying to do here, like maybe use 'ABCE ' if thats what is really needed. And, please everyone please quit fiddling with the compiler to fix problems in the source code. Are people so lazy or such cheapskates they won't do this the right way and update the damn source code if it needs to be used. We have truly more serious and real problems/bugs in gfortran that people should be spending the scarce resources on and not this junk. Jerry
Re: [PATCH, libfortran] PR 88137 Initialize backtrace state once
On 11/29/18 11:37 PM, Janne Blomqvist wrote:
PING!
LGTM,
OK and thanks
Jerry
(for the GCC-7 branch, I'll commit it after the 7.4 release)
On Thu, Nov 22, 2018 at 11:17 AM Janne Blomqvist
wrote:
From backtrace.h for backtrace_create_state:
Calling this function allocates resources that can not be freed.
There is no backtrace_free_state function. The state is used to
cache information that is expensive to recompute. Programs are
expected to call this function at most once and to save the return
value for all later calls to backtrace functions.
So instead of calling backtrace_create_state every time we wish to
show a backtrace, do it once and store the result in a static
variable. libbacktrace allows multiple threads to access the state,
so no need to use TLS.
Regtested on x86_64-pc-linux-gnu, Ok for trunk/8/7?
libgfortran/ChangeLog:
2018-11-22 Janne Blomqvist
PR libfortran/88137
* runtime/backtrace.c (show_backtrace): Make lbstate a static
variable, initialize once.
---
libgfortran/runtime/backtrace.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libgfortran/runtime/backtrace.c
b/libgfortran/runtime/backtrace.c
index e0c277044b6..3fc973a5e6d 100644
--- a/libgfortran/runtime/backtrace.c
+++ b/libgfortran/runtime/backtrace.c
@@ -146,11 +146,15 @@ full_callback (void *data, uintptr_t pc, const char
*filename,
void
show_backtrace (bool in_signal_handler)
{
- struct backtrace_state *lbstate;
+ /* Note that libbacktrace allows the state to be accessed from
+ multiple threads, so we don't need to use a TLS variable for the
+ state here. */
+ static struct backtrace_state *lbstate;
struct mystate state = { 0, false, in_signal_handler };
-
- lbstate = backtrace_create_state (NULL, __gthread_active_p (),
- error_callback, NULL);
+
+ if (!lbstate)
+lbstate = backtrace_create_state (NULL, __gthread_active_p (),
+ error_callback, NULL);
if (lbstate == NULL)
return;
--
2.17.1
Re: [patch, libgfortran] PR88052 - Format contravening f2008 constraint C1002 permitted
On 11/24/18 2:51 PM, Dominique d'Humières wrote: Hi Jerry, OK for trunk? Could you give me some time to post some comments in bugzilla? Sure, no rush. TIA Dominique
[patch, libgfortran] PR88052 - Format contravening f2008 constraint C1002 permitted
Hi all,
The attached patch adjusts the constraint of missing commas between
format specifiers by only allowing if std=legacy is given at compile time.
Several existing test cases are adjusted to be standard conforming.
Regression tested on x86-64-linux-gnu.
OK for trunk? (I will include the a change log for the testsuite.)
Jerry
2018-11-24 Jerry DeLisle
PR libfortran/88052
* io/format.c (parse_format_list): Implement constraint which prohibits
missing commas between format specifiers unless -std=legacy is given.
diff --git a/gcc/testsuite/gfortran.dg/comma_format_extension_4.f b/gcc/testsuite/gfortran.dg/comma_format_extension_4.f
index 30f07e803c5..1d018380f9c 100644
--- a/gcc/testsuite/gfortran.dg/comma_format_extension_4.f
+++ b/gcc/testsuite/gfortran.dg/comma_format_extension_4.f
@@ -1,7 +1,7 @@
! PR fortran/13257
-! Note the missing , before i1 in the format.
+! Note the missing , after i4 in the format.
! { dg-do run }
-! { dg-options "" }
+! { dg-options "-std=legacy" }
character*6 c
write (c,1001) 1
if (c .ne. '1 ') STOP 1
diff --git a/gcc/testsuite/gfortran.dg/dollar_edit_descriptor_2.f b/gcc/testsuite/gfortran.dg/dollar_edit_descriptor_2.f
index 437f4dfd811..de583f374dc 100644
--- a/gcc/testsuite/gfortran.dg/dollar_edit_descriptor_2.f
+++ b/gcc/testsuite/gfortran.dg/dollar_edit_descriptor_2.f
@@ -1,5 +1,5 @@
! { dg-do run }
-! { dg-options "-w" }
+! { dg-options "-w -std=legacy" }
! PR25545 internal file and dollar edit descriptor.
program main
character*20 line
diff --git a/gcc/testsuite/gfortran.dg/fmt_error_9.f b/gcc/testsuite/gfortran.dg/fmt_error_9.f
index 1d677509e37..23aee89208d 100644
--- a/gcc/testsuite/gfortran.dg/fmt_error_9.f
+++ b/gcc/testsuite/gfortran.dg/fmt_error_9.f
@@ -4,7 +4,7 @@
! Test case prepared by Jerry DeLisle
character(len=25) :: str
character(len=132) :: msg, line
- str = '(1pd24.15e6)'
+ str = '(1pd24.15,e6)'
line = "initial string"
x = 555.25
@@ -19,11 +19,11 @@
if (istat.ne.5006 .or. msg(1:15).ne."Positive width ") STOP 4
if (x.ne.555.25) STOP 5
- write (line,'(1pd24.15e11.3)') 1.0d0, 1.234
+ write (line,'(1pd24.15,e11.3)') 1.0d0, 1.234
if (line.ne." 1.000D+00 1.234E+00") STOP 6
str = '(1p2d24.15)'
msg = " 1.000D+00 1.23367575073D+00That's it!"
- write (line,'(1p2d24.15a)') 1.0d0, 1.234, "That's it!"
+ write (line,'(1p2d24.15,a)') 1.0d0, 1.234, "That's it!"
if (line.ne.msg) print *, msg
end
diff --git a/gcc/testsuite/gfortran.dg/fmt_g0_5.f08 b/gcc/testsuite/gfortran.dg/fmt_g0_5.f08
index d2a97b1ac80..cafd90b94b5 100644
--- a/gcc/testsuite/gfortran.dg/fmt_g0_5.f08
+++ b/gcc/testsuite/gfortran.dg/fmt_g0_5.f08
@@ -6,13 +6,13 @@ program test_g0_special
call check_all("(g10.3)", "(f10.3)")
call check_all("(g10.3e3)", "(f10.3)")
-call check_all("(spg10.3)", "(spf10.3)")
-call check_all("(spg10.3e3)", "(spf10.3)")
+call check_all("(sp,g10.3)", "(sp,f10.3)")
+call check_all("(sp,g10.3e3)", "(sp,f10.3)")
!print *, "---"
call check_all("(g0)", "(f0.0)")
call check_all("(g0.15)", "(f0.0)")
-call check_all("(spg0)", "(spf0.0)")
-call check_all("(spg0.15)", "(spf0.0)")
+call check_all("(sp,g0)", "(sp,f0.0)")
+call check_all("(sp,g0.15)", "(sp,f0.0)")
contains
subroutine check_all(fmt1, fmt2)
character(len=*), intent(in) :: fmt1, fmt2
diff --git a/gcc/testsuite/gfortran.dg/fmt_t_2.f90 b/gcc/testsuite/gfortran.dg/fmt_t_2.f90
index 01647655de6..56414c54bfb 100644
--- a/gcc/testsuite/gfortran.dg/fmt_t_2.f90
+++ b/gcc/testsuite/gfortran.dg/fmt_t_2.f90
@@ -12,7 +12,7 @@
read (11, '(a040,t1,040a)', end = 999) foost1 , foost2
if (foost1.ne.foost2) STOP 1
- read (11, '(a032,t2,a032t3,a032)', end = 999) foost1 , foost2, foost3
+ read (11, '(a032,t2,a032,t3,a032)', end = 999) foost1 , foost2, foost3
if (foost1(1:32).ne."123456789 123456789 123456789 ") STOP 2
if (foost2(1:32).ne."23456789 123456789 123456789") STOP 3
if (foost3(1:32).ne."3456789 123456789 123456789 ") STOP 4
diff --git a/libgfortran/io/format.c b/libgfortran/io/format.c
index f5d3158d21d..5ad57bef316 100644
--- a/libgfortran/io/format.c
+++ b/libgfortran/io/format.c
@@ -46,7 +46,8 @@ static const char posint_required[] = "Positive width required in format",
bad_string[] = "Unterminated character constant in format",
bad_hollerith[] = &qu
Re: [PATCH] Add -fpad-source option
On 11/22/18 11:43 AM, Jakub Jelinek wrote: On Thu, Nov 22, 2018 at 11:00:13AM +0100, Jakub Jelinek wrote: Ok for trunk if it passes bootstrap/regtest (so far just checked with make check-gfortran RUNTESTFLAGS='dg.exp=pad_source*' )? Note, it passed bootstrap/regtest on x86_64-linux. OK, and thanks for the work. Jerry
Re: [patch, fortran] Fix PR 70260, ICE on invalid
On 11/11/18 7:59 AM, Thomas Koenig wrote: Hello world, the attached patch fixes both ICEs in the PR by adding some tests. It was necessary to shuffle around a bit of code, plus to make sure that double error reporting did not become too bad. Regression-tested. OK for trunk? Regards Thomas On vacation in Florida for a few days with Grandkids. Looks Good To Me. OK Jerry
[patch, libgfortran] Patch committed as obvious
Committed as obvious. I had inserted this line to check effects of the -fdec flags and forgot to delete it before my previous commit. Author: jvdelisle Date: Fri Nov 9 17:29:33 2018 New Revision: 265979 URL: https://gcc.gnu.org/viewcvs?rev=265979=gcc=rev Log: 2018-11-09 Jerry DeLisle PR libfortran/78351 * io/transfer.c (read_sf_internal): Delete leftover debug code. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c
Re: [patch, libgfortran] PR78351 comma not terminating READ of formatted input field
On 11/4/18 1:51 AM, Bernhard Reutner-Fischer wrote: On Sat, 3 Nov 2018 15:33:07 -0700 Jerry DeLisle wrote: diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c index 31198a3cc39..0d26101cef0 100644 --- a/libgfortran/io/transfer.c +++ b/libgfortran/io/transfer.c @@ -260,22 +250,80 @@ read_sf_internal (st_parameter_dt *dtp, size_t *length) sseek (dtp->u.p.current_unit->s, -1, SEEK_CUR); } - lorig = *length; - if (is_char4_unit(dtp)) + /* To support legacy code we have to scan the input string one byte + at a time because we don't no where an early comma may be and the As Andreas said s/no/know/ + requested length could go passed the end of a comma shortened s/passed/past/ + /* Get the first chracter of the string to establish the base s/chracter/character/ + /* Now we scan the rest and exit deal with an end-of-file s/ exit// ? Fixed all my typos, thanks. Jerry
[patch, libgfortran] PR78351 comma not terminating READ of formatted input field
Hi all,
The attached patch adds code in read_sf_internal to handle early
termination of reads in the presence of comma's. This is to support
legacy codes which are not standard conforming as far as we can tell.
The additions are executed only if -std=legacy is given at compile time.
It does not support kind=4 internal units since in legacy years there
should be no kind=4 internal units.
I have provuded a simplified test case for various combinations of comma
embedded strings.
This has been regression tested on x86_64-pc-linux-gnu.
OK for trunk?
This use to work way back in early versions so should probably go to 7
and 8 branches. Opinions welcome.
Regards,
Jerry
2018-11-04 Jerry DeLisle
* io/transfer.c (read_sf_internal): Add support for early
comma termination of internal unit formatted reads.
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 31198a3cc39..0d26101cef0 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -241,16 +241,6 @@ read_sf_internal (st_parameter_dt *dtp, size_t *length)
&& dtp->u.p.current_unit->pad_status == PAD_NO)
hit_eof (dtp);
- /* If we have seen an eor previously, return a length of 0. The
- caller is responsible for correctly padding the input field. */
- if (dtp->u.p.sf_seen_eor)
-{
- *length = 0;
- /* Just return something that isn't a NULL pointer, otherwise the
- caller thinks an error occurred. */
- return (char*) empty_string;
-}
-
/* There are some cases with mixed DTIO where we have read a character
and saved it in the last character buffer, so we need to backup. */
if (unlikely (dtp->u.p.current_unit->child_dtio > 0 &&
@@ -260,22 +250,80 @@ read_sf_internal (st_parameter_dt *dtp, size_t *length)
sseek (dtp->u.p.current_unit->s, -1, SEEK_CUR);
}
- lorig = *length;
- if (is_char4_unit(dtp))
+ /* To support legacy code we have to scan the input string one byte
+ at a time because we don't no where an early comma may be and the
+ requested length could go passed the end of a comma shortened
+ string. We only do this if -std=legacy was given at compile
+ time. We also do not support this on kind=4 strings. */
+ if (unlikely(compile_options.warn_std == 0)) // the slow legacy way.
{
- gfc_char4_t *p = (gfc_char4_t *) mem_alloc_r4 (dtp->u.p.current_unit->s,
- length);
- base = fbuf_alloc (dtp->u.p.current_unit, lorig);
- for (size_t i = 0; i < *length; i++, p++)
- base[i] = *p > 255 ? '?' : (unsigned char) *p;
-}
- else
-base = mem_alloc_r (dtp->u.p.current_unit->s, length);
+ size_t n;
+ size_t tmp = 1;
+ char *q;
+
+ /* If we have seen an eor previously, return a length of 0. The
+ caller is responsible for correctly padding the input field. */
+ if (dtp->u.p.sf_seen_eor)
+ {
+ *length = 0;
+ /* Just return something that isn't a NULL pointer, otherwise the
+ caller thinks an error occurred. */
+ return (char*) empty_string;
+ }
+
+ /* Get the first chracter of the string to establish the base
+ address and check for comma or end-of-record condition. */
+ base = mem_alloc_r (dtp->u.p.current_unit->s, );
+ if (tmp == 0)
+ {
+ dtp->u.p.sf_seen_eor = 1;
+ *length = 0;
+ return (char*) empty_string;
+ }
+ if (*base == ',')
+ {
+ dtp->u.p.current_unit->bytes_left--;
+ *length = 0;
+ return (char*) empty_string;
+ }
- if (unlikely (lorig > *length))
+ /* Now we scan the rest and exit deal with an end-of-file
+ condition or the comma. */
+ for (n = 1; n < *length; n++)
+ {
+ q = mem_alloc_r (dtp->u.p.current_unit->s, );
+ if (tmp == 0)
+ {
+ hit_eof (dtp);
+ return NULL;
+ }
+ if (*q == ',')
+ {
+ dtp->u.p.current_unit->bytes_left -= n;
+ *length = n;
+ break;
+ }
+ }
+}
+ else // the fast way
{
- hit_eof (dtp);
- return NULL;
+ lorig = *length;
+ if (is_char4_unit(dtp))
+ {
+ gfc_char4_t *p = (gfc_char4_t *) mem_alloc_r4 (dtp->u.p.current_unit->s,
+ length);
+ base = fbuf_alloc (dtp->u.p.current_unit, lorig);
+ for (size_t i = 0; i < *length; i++, p++)
+ base[i] = *p > 255 ? '?' : (unsigned char) *p;
+ }
+ else
+ base = mem_alloc_r (dtp->u.p.current_unit->s, length);
+
+ if (unlikely (lorig > *length))
+ {
+ hit_eof (dtp);
+ return NULL;
+ }
}
dtp->u.p.current_unit->bytes_left -= *length;
! { dg-do run }
! { dg-options "-std=legacy" }
! PR78351
program read_csv
implicit none
integer, parameter :: dbl = selected_real_kind(p=14, r=99)
call checkit("101,1.,2.,3.,7,7")
call checkit ("102,1.,,3.,,7")
call checkit (",1.,,3.,, ")
contai
Re: [patch, fortran] Fix PR 86111, ICE on invalid
On 10/6/18 10:53 AM, Thomas Koenig wrote: Hello world, the attached patch fixes an ICE regression by issuing an error when a clever combination of array constructors ends up in gfc_arith_concat with mismatched types, before resultion has a chance to report the error. Regression-tested. OK for trunk? Looks OK. Jerry
Re: [PATCH, libgfortran] Remove recursion check
On 10/6/18 10:00 AM, Janne Blomqvist wrote: On Mon, Sep 24, 2018 at 10:18 PM Janne Blomqvist wrote: On Mon, Sep 24, 2018 at 7:48 PM Thomas Koenig wrote: Hi Janne, libgfortran has a recursion check in the error handling paths. This works by checking the value of a static variable, and if it matches, aborting immediately instead of continuing error processing. Unfortunately, in a multi-threaded program, if two threads report an error at the same time, this can trigger this check, and thus the underlying reason for the error is never reported. I agree that this is a problem that should be addressed. Hm... What do you think, would it be desirable / possible to keep the recursive error check, but ensure thread safety by a suitable locking mechanism? As a first step, we should probably specify what exactly we would like to happen. Let us assume that the aim is to keep the current behavior for normal processes and allow concurrent error processing for multiple threads. This could be done by making the static variable thread-local. I'm not sure that this would work reliably, or if some sort of locking mechanism (probably involving PTHREAD_MUTEX_RECURSIVE) would be required - only have one thread at a time process an error. Do we actually want to keep the current behavior for non-threaded programs? I'd be in favor, but I do not feel strongly about that. What I briefly was thinking about doing, was to use TLS. Or rather, since TLS is not supported on all targets, something like I did in intrinsics/random.c:get_rand_state(). But, since the error handling stuff should be async-signal-safe, the allocation in the setup path should be done separately, e.g. as part of library initialization. In the end I decided against it because 1) It's more complicated, in order to handle a quite unlikely edge case. 2) If recursion happens anyway, it's a bug in our error handling flow which should be fixed and not be papered over. Anyway, I'm not massively against this, if people have any particular opinion lets hear it. PING! Any opinions on the above? Agree it should be fixed. I would think a mutex lock should work. Lock, issue error message, unlock. Even if there is recursion, since there is at least one error somewhere, It should be OK to pause the world to issue the error, and come back and finish. AS I think about it, maybe one global lock variable so that only one thread can get it at a time and others wait until it is unlcoked to proceed with their lock and error. Would there be a problem with some sort of endless loop waiting for the unlock? Jerry
Re: [patch, fortran] Clobber some intent(out) variables on call
Minor typo, see below.
On 9/22/18 10:23 AM, Thomas Koenig wrote:
Hello world,
the attached patch lets the middle-end know that variables
associated with intent(out) arguments become undefined, by
issuing an assignment to a special value (a "clobber")
before entering the procedure.
Originally, I had also planned to do so on entry to the
procedure, see https://gcc.gnu.org/ml/fortran/2018-09/msg00148.html .
This turned out to cause regressions; some details are outlined
in the PR.
Regression-tested. OK for trunk?
! { dg-do compile }
! { dg-options "-O -fno-inline -fdump-tree-optimized -fdump-tree-original" }
! PR fortran/41453
! Check that there is one clobber in the *.original tree, plus that
! the constant 123456789 has been removed tue to the INTENT(OUT).
s/tue/due/
and
program main
use x
implicit none
integer :: a
a = 12345689 < missing 7 digit?
call foo(a)
print *,a
end program main
Otherwise OK.
Jerry
[patch, fortran] PR87318 gfortran.dg/dtio_1.f90 is invalid
Committed as OKed by Janus on bugzilla. Author: jvdelisle Date: Sat Sep 22 17:49:19 2018 New Revision: 264505 URL: https://gcc.gnu.org/viewcvs?rev=264505=gcc=rev Log: 2018-09-22 Jerry DeLisle PR fortran/87318 * gfortran.dg/dtio_1.f90: Update test to valid code. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dtio_1.f90
Re: OpenCoarrays integration with gfortran
On 9/21/18 1:16 PM, Damian Rouson wrote:> On Fri, Sep 21, 2018 at 9:25 AM Jerry DeLisle wrote: > >> The actual library source code is contained mostly in one source file. > > There are as many files as there are options for the underlying > parallel programming > model. The default is MPI, but I've co-authored conference papers last year > and this year in which the OpenCoarrays OpenSHEM option outperformed MPI. > One paper even described a platform on which OpenSHMEM was the only option > beyond a few thousand cores because the required MPI features were immature on > that platform. Early versions of OpenCoarrays also provided GASNet > and ARMCI options. > I recommend against tying gfortran to MPI only. I agree with you on this point. Perhaps the Opencoarrays implementation should somehow do some runtime introspection to allow the library to sync to whatever is desired on a given system. The gfortran interface was designed to be generic. Implementation should be more dynamic in run time linking and abstracted in such a way that OpenCoarrays could be compiled stand alone and use something like "plugins" to allow post build the determination of what which interface to use. I am by no means a software expert in these techniques, but they are becoming common practice in other areas, for example linux/Gnu kernel modules > >> After all the attempts to integrate into the GNU build systems without >> much success my thinking has shifted. > > Thanks for all your efforts! > >> Keep in mind that the OpenCoarrays >> implementation is quite dependent on gfortran and in fact has to do >> special things in the build dependent on the version of gcc/gfortran a >> user happens to use. I dont think this is a good situation. > > I agree. Possibly OpenCoarrays could drop support for older gfortran versions > at some point to avoid maintaining code that exists solely to support compiler > versions that are several years old. See my comments above about pluggable modules. Maybe libgfortran should have this pluggable interface and Opencoarrays provide the plugins. Think how useful it would be to be able to choose the backend at time of execution based on a simple envoronment variable set by the user. > >> >> 1) Focus on distribution packages such as Fedora, Debian, Ubuntu, >> Windows, etc. Building of these packages needs to be automated into the >> distributions. > > This is the option that the OpenCoarrays documentation recommends as easiest for > most users. Agree. > >> 2) Take the one source file, edit out all the macros that define >> prefixes to function calls, hard code the gfortran prefixes etc and fork >> it directly into the libgfortran library under GPL with attributions to >> the original developers as appropriate. > > See above. Also, this means that changes in the gfortran repository would not > propagate back upstream unless each gfortran developer agrees to > distribute his or her > work under both GPL and BSD. Even that is only feasible if the copied > files stay cohesive The flip of this would be to have the OpenCorrays developers to agree to the GPL and release under both. The libgfortran license says: "Under Section 7 of GPL version 3, you are granted additional permissions described in the GCC Runtime Library Exception, version 3.1, as published by the Free Software Foundation." Probably worth a fresh look. > and don't reference code outside the copied file. I think it's more > likely that copying the code > into gfortran would be a branch point, after which the relevant files > would diverge and > work on the GPL side would be harder to fund than the BSD side. > > Most commercial entities are more likely to contribute to a > BSD-licensed project than a > GPL-licensed one. Over the past several months, one commercial compiler vendor > authorized one of their developers to contribute to OpenCoarrays. and > another commercial > compiler vendor invited community input on whether to use OpenCoarrays > during a public > teleconference. The prospect of commercial support is the motivation > for using BSD. I really have no commercial interest. So I will not comment on GPL vs BSD other than referring to the multitude of FSF recommendations about why one should choose one of the FSF flavors rather than BSD. > >> Strategy 2 does have some advantages. For example, eliminating the need >> for separate CAF and CAFRUN scripts which are a wrapper on gfortran. > > Even in the case of just one underlying parallel programming model, > this is tricky. To wit, Cray uses > a compiler wrapper and a program launcher. Intel was able to > eliminate the compiler wrapper, > but still required a p
Re: [PATCH] Use vectored writes when reporting errors and warnings.
Janne, this looks OK. Since you are touching on configuration and posix dependencies have you tested under any other systems? Jerry On 9/21/18 1:41 AM, Janne Blomqvist wrote: PING On Wed, Sep 12, 2018 at 10:17 PM Janne Blomqvist wrote: When producing error and warning messages, libgfortran writes a message by using many system calls. By using vectored writes (the POSIX writev function) when available and feasible to use without major surgery, we reduce the chance that output gets intermingled with other output to stderr. In practice, this is done by introducing a new function estr_writev in addition to the existing estr_write. In order to use this, the old st_vprintf is removed, replaced by direct calls of vsnprintf, allowing more message batching. Regtested on x86_64-pc-linux-gnu, Ok for trunk? libgfortran/ChangeLog: 2018-09-12 Janne Blomqvist * config.h.in: Regenerated. * configure: Regenerated. * configure.ac: Check for writev and sys/uio.h. * libgfortran.h: Include sys/uio.h. (st_vprintf): Remove prototype. (struct iovec): Define if not available. (estr_writev): New prototype. * runtime/backtrace.c (error_callback): Use estr_writev. * runtime/error.c (ST_VPRINTF_SIZE): Remove. (estr_writev): New function. (st_vprintf): Remove. (gf_vsnprintf): New function. (ST_ERRBUF_SIZE): New macro. (st_printf): Use vsnprintf. (os_error): Use estr_writev. (runtime_error): Use vsnprintf and estr_writev. (runtime_error_at): Likewise. (runtime_warning_at): Likewise. (internal_error): Use estr_writev. (generate_error_common): Likewise. (generate_warning): Likewise. (notify_std): Likewise. * runtime/pause.c (pause_string): Likewise. * runtime/stop.c (report_exception): Likewise. (stop_string): Likewise. (error_stop_string): Likewise. --- snip ---
OpenCoarrays integration with gfortran
My apologies for kidnapping this thread: On 9/20/18 1:01 PM, Thomas Koenig wrote: Hi Damian, On a related note, two Sourcery Institute developers have attempted to edit the GCC build system to make the downloading and building of OpenCoarrays automatically part of the gfortran build process. Neither developer succeeded. We addressed integrating OpenCoarray into the gcc source tree at the recent Gcc summit during the gfortran BoF session. Feedback from people working for big Linux distributions was that they would prefer to package OpenCoarrays as a separate library. (They also mentioned it was quite hard to build.) I would like to put in my humble 2 cents worth here. OpenCoarrays was/is intended for a very broad audience, various large systems such as Cray, etc. I think this influenced heavily the path of its development, which is certainly OK. It was/is intended to interface libraries such as OpenMPI or MPICH to gfortran as well as other Fortran compilers. The actual library source code is contained mostly in one source file. After all the attempts to integrate into the GNU build systems without much success my thinking has shifted. Keep in mind that the OpenCoarrays implementation is quite dependent on gfortran and in fact has to do special things in the build dependent on the version of gcc/gfortran a user happens to use. I dont think this is a good situation. So I see two realistic strategies. The first is already talked about a lot and is the cleanest approach for gfortran: 1) Focus on distribution packages such as Fedora, Debian, Ubuntu, Windows, etc. Building of these packages needs to be automated into the distributions. I think mostly this is what is happening and relies on the various distribution maintainers to do so. Their support is greatly appreciated and this really is the cleanest approach. The second option is not discussed as much because it leaves OpenCoarrays behind in a sense and requires an editing cycle in two places to fix bugs or add features. 2) Take the one source file, edit out all the macros that define prefixes to function calls, hard code the gfortran prefixes etc and fork it directly into the libgfortran library under GPL with attributions to the original developers as appropriate. Strategy 2 would lock into specific current standard versions of the MPI interface and would support less bleeding edge changes. It would also require either OpenMPI or MPICH as a new gfortran dependency for building, which not all users may need. So we would need some configuration magic to enable or disable this portion of the build. Something like --with-MPI-support would do the trick. Strategy 2 does add burden to gfortran maintainers who are already overloaded. But, as the code matures the burden would decrease, particularly once TEAMS are finished. Strategy 2 does have some advantages. For example, eliminating the need for separate CAF and CAFRUN scripts which are a wrapper on gfortran. The coarray features are part of the Fortran language and gfortran should just "handle it" transparently using an environment variable to define the number of images at run time. It would also actually eliminate the need to manage all of the separate distribution packages. So from a global point of view the overall maintanance effort would be reduced. Strategy 2 would enable a set of users who are not focused so much on distributions and loading packages, etc etc and those who are dependent on getting through bureaucratic administrations who already are loading gfortran on systems and would not have to also get another package approved. People would just have to stop thinking about it and just use it. So I think there are real advantages to Strategy 2 as well as Strategy 1 and think it should be at least included in discussions. I would even suggest there is likely a combination of 1 and 2 that may hit the mark. For example, keeping OpenCoarrays as a separate package for bleeding edge development and migrating the stable features into libgfortran on a less frequent cycle. As I said, my 2 cents worth. Regards to all, Jerry
[patch, fortran] Fix for modulo checking similar to PR86045
Hi all,
Similar to Steve's fix of 'mod' checking for 86045, the attached patch
fixes an ICE in 'modulo' when P = 0.
Mark pointed this out and greatly assisted with the patch. I have
regression tested and plan to commit to trunk, 8, and 7 so that we are
in sync with the 'mod' patch.
If no objections, later today I will commit with the test case.
Regards,
Jerry
2018-09-03 Jerry DeLisle
* simplify.c (gfc_simplify_modulo): Re-arrange code to test
whether 'P' is zero and issue an error if it is.
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 41997367cf9..d35bbbaaa1b 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -5525,54 +5525,57 @@ gfc_simplify_modulo (gfc_expr *a, gfc_expr *p)
gfc_expr *result;
int kind;
- if (a->expr_type != EXPR_CONSTANT || p->expr_type != EXPR_CONSTANT)
+ /* First check p. */
+ if (p->expr_type != EXPR_CONSTANT)
return NULL;
- kind = a->ts.kind > p->ts.kind ? a->ts.kind : p->ts.kind;
- result = gfc_get_constant_expr (a->ts.type, kind, >where);
-
- switch (a->ts.type)
+ /* p shall not be 0. */
+ switch (p->ts.type)
{
case BT_INTEGER:
if (mpz_cmp_ui (p->value.integer, 0) == 0)
{
- /* Result is processor-dependent. This processor just opts
- to not handle it at all. */
- gfc_error ("Second argument of MODULO at %L is zero", >where);
- gfc_free_expr (result);
+ gfc_error ("Argument %qs of MODULO at %L shall not be zero",
+ "P", >where);
return _bad_expr;
}
- mpz_fdiv_r (result->value.integer, a->value.integer, p->value.integer);
-
break;
-
case BT_REAL:
if (mpfr_cmp_ui (p->value.real, 0) == 0)
{
- /* Result is processor-dependent. */
- gfc_error ("Second argument of MODULO at %L is zero", >where);
- gfc_free_expr (result);
+ gfc_error ("Argument %qs of MODULO at %L shall not be zero",
+ "P", >where);
return _bad_expr;
}
-
- gfc_set_model_kind (kind);
- mpfr_fmod (result->value.real, a->value.real, p->value.real,
- GFC_RND_MODE);
- if (mpfr_cmp_ui (result->value.real, 0) != 0)
- {
- if (mpfr_signbit (a->value.real) != mpfr_signbit (p->value.real))
- mpfr_add (result->value.real, result->value.real, p->value.real,
- GFC_RND_MODE);
- }
- else
- mpfr_copysign (result->value.real, result->value.real,
- p->value.real, GFC_RND_MODE);
break;
-
default:
gfc_internal_error ("gfc_simplify_modulo(): Bad arguments");
}
+ if (a->expr_type != EXPR_CONSTANT)
+return NULL;
+
+ kind = a->ts.kind > p->ts.kind ? a->ts.kind : p->ts.kind;
+ result = gfc_get_constant_expr (a->ts.type, kind, >where);
+
+ if (a->ts.type == BT_INTEGER)
+ mpz_fdiv_r (result->value.integer, a->value.integer, p->value.integer);
+ else
+{
+ gfc_set_model_kind (kind);
+ mpfr_fmod (result->value.real, a->value.real, p->value.real,
+ GFC_RND_MODE);
+ if (mpfr_cmp_ui (result->value.real, 0) != 0)
+{
+ if (mpfr_signbit (a->value.real) != mpfr_signbit (p->value.real))
+mpfr_add (result->value.real, result->value.real, p->value.real,
+ GFC_RND_MODE);
+ }
+ else
+mpfr_copysign (result->value.real, result->value.real,
+ p->value.real, GFC_RND_MODE);
+}
+
return range_check (result, "MODULO");
}
diff --git a/gcc/testsuite/gfortran.dg/modulo_check.f90 b/gcc/testsuite/gfortran.dg/modulo_check.f90
new file mode 100644
index 000..8819a2f8e4e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/modulo_check.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! Test checks on modulo with p == 0
+program p
+ logical :: a(2) = (modulo([2,3],0) == 0) ! { dg-error "shall not be zero" }
+ integer :: b = count(modulo([2,3],0) == 0) ! { dg-error "shall not be zero" }
+ integer :: c = all(modulo([2,3],0) == 0) ! { dg-error "shall not be zero" }
+ integer :: d = any(modulo([2,3],0) == 0) ! { dg-error "shall not be zero" }
+end program
! { dg-do compile }
! Test checks on modulo with p == 0
program p
logical :: a(2) = (modulo([2,3],0) == 0) ! { dg-error "shall not be zero" }
integer :: b = count(modulo([2,3],0) == 0) ! { dg-error "shall not be zero" }
integer :: c = all(modulo([2,3],0) == 0) ! { dg-error "shall not be zero" }
integer :: d = any(modulo([2,3],0) == 0) ! { dg-error "shall not be zero" }
end program
Re: [patch, libgfortran] Fix warning about mismatched type declarations.
On 09/02/2018 04:49 AM, Thomas Koenig wrote: Hi Jerry, The subject patch fixes the declaration for the vlist argument of the formatted_dtio function pointer definition which currently gives a warnings during compilation for mismatched types. Regression tested on x86_64-pc-linux. OK for trunk? OK. Thanks! Regards Thomas Committing to svn+ssh://jvdeli...@gcc.gnu.org/svn/gcc/trunk ... M libgfortran/ChangeLog M libgfortran/io/format.c M libgfortran/io/format.h M libgfortran/io/io.h Committed r264043
[patch, libgfortran] Fix warning about mismatched type declarations.
All,
The subject patch fixes the declaration for the vlist argument of the
formatted_dtio function pointer definition which currently gives a
warnings during compilation for mismatched types.
Regression tested on x86_64-pc-linux.
OK for trunk?
Regards,
Jerry
2018-09-01 Jerry DeLisle
* io/io.h: Change declaration of vlist type to
gfc_full_array_i4 to eliminate warning for mismatched type.
* io/format.c ((parse_format_list): Use gfc_full_array_i4.
* io/io.h: Use gfc_full_array_i4.
diff --git a/libgfortran/ChangeLog b/libgfortran/ChangeLog
diff --git a/libgfortran/io/format.c b/libgfortran/io/format.c
index b4920aaf1f1..f5d3158d21d 100644
--- a/libgfortran/io/format.c
+++ b/libgfortran/io/format.c
@@ -1058,7 +1058,7 @@ parse_format_list (st_parameter_dt *dtp, bool *seen_dd)
{
/* We have parsed the complete vlist so initialize the
array descriptor and save it in the format node. */
- gfc_array_i4 *vp = tail->u.udf.vlist;
+ gfc_full_array_i4 *vp = tail->u.udf.vlist;
GFC_DESCRIPTOR_DATA(vp) = xmalloc (i * sizeof(GFC_INTEGER_4));
GFC_DIMENSION_SET(vp->dim[0],1, i, 1);
memcpy (GFC_DESCRIPTOR_DATA(vp), temp, i * sizeof(GFC_INTEGER_4));
diff --git a/libgfortran/io/format.h b/libgfortran/io/format.h
index ad7e1c14b8f..19882bcf095 100644
--- a/libgfortran/io/format.h
+++ b/libgfortran/io/format.h
@@ -78,7 +78,7 @@ struct fnode
{
char *string;
int string_len;
- gfc_array_i4 *vlist;
+ gfc_full_array_i4 *vlist;
}
udf; /* User Defined Format. */
diff --git a/libgfortran/io/io.h b/libgfortran/io/io.h
index d31213106ed..902eb412848 100644
--- a/libgfortran/io/io.h
+++ b/libgfortran/io/io.h
@@ -100,7 +100,8 @@ array_loop_spec;
/* Subroutine formatted_dtio (struct, unit, iotype, v_list, iostat,
iomsg, (_iotype), (_iomsg)) */
-typedef void (*formatted_dtio)(void *, GFC_INTEGER_4 *, char *, gfc_array_i4 *,
+typedef void (*formatted_dtio)(void *, GFC_INTEGER_4 *, char *,
+ gfc_full_array_i4 *,
GFC_INTEGER_4 *, char *,
gfc_charlen_type, gfc_charlen_type);
Re: [patch, libfortran] correct buffer size in library matmul
On 08/25/2018 12:38 PM, Thomas Koenig wrote: Hello world, the attached patch fixes a regression where the calculation of the size of the buffer for matmul was too small for ine special case. Regression-tested. OK for trunk? Regards Thomas OK Thomas and thanks for the fix. Jerry
Re: [patch, fortran] Fix PR 86837, wrong code regression in implied do loop in i/o
On 08/23/2018 01:12 PM, Thomas König wrote: Hello world, this patch fixes a regression by correctly checking that the innner start, step or end values of an implied do loop do not depend on an outer loop variable. The check was actually done before, but gfc_check_dependency wasn't finding all relevant cases. Regression-tested. OK for trunk and 8.x? Regards Thomas Very OK Thomas. Thanks for patch. Jerry
Re: [PATCH] Signed zero for {max,min}val intrinsics
On 08/22/2018 01:06 PM, Janne Blomqvist wrote:
The Fortran standard specifies (e.g. F2018 7.4.3.2) that intrinsic
procedures shall treat positive and negative real zero as equivalent,
unless it is explicitly specified otherwise. For {max,min}val there
is no such explicit mention. Thus, remove code to handle signed
zeros.
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
Looks good, OK.
Thanks,
Jerry
---snip---
Re: [patch, fortran] Asynchronous I/O, take 3
On 07/15/2018 11:46 AM, Rainer Orth wrote: Hi Jerry, Hmm, interesting. Which linux are you using? Fedora 27. Rainer Works for me. Fedora 28. Do not know for other OS's Jerry
Re: [patch, fortran] Asynchronous I/O, take 3
On 07/15/2018 10:47 AM, Rainer Orth wrote:
Hi Thomas,
However, I still don't understand why you insist on the hack with
putting the async_io_*.f90 tests into the libgomp testsuite. Why not
just make the pthread requirement explicit with
{ dg-require-effective-target pthread }
{ dg-additional-options "-pthread" }
and put them in gfortran.dg where they belong?
Because this does not appear to work with Linux. I, like
most gfortran developers, work on Linux, and I would like to
catch any failure during regression-testing on my own system,
if possible.
huh, what doesn't work? I've just finished an x86_64-pc-linux-gnu
bootstrap with your patch included, added the above to the
async_io_?.f90 tests, linked them to gfortran.dg and ran the tests there
(both 32 and 64-bit multilibs), all PASSed and I verified that they were
linked with -lpthread.
We have had this discussion with Jakub, and he advised
us to put all the stuff requiring pthreads into libgomp.
Do you have a pointer to that previous discussion?
It is debatable if this is a good thing, or if we should
at least make one round of tests with -pthread enabled.
However, this is something for the future, and requires knowledge
of dejagnu that I don't currently have :-)
First of all, we need to see and understand the failure mode, if any.
Making this work with the testsuite is a secondary matter only, and I
can certainly help with that if necessary.
Rainer
Hmm, interesting. Which linux are you using?
I will try it here as well.
Jerry
