Re: [PATCH] Fortran: fix documentation of -fno-underscoring [PR109216]
On 3/20/23 14:05, Harald Anlauf via Gcc-patches wrote: Dear all, as reported, the implicit documentation of -funderscoring, which is found under -fno-underscoring, has gone sideways long time ago. The attached patch should fix it. OK for mainline, or did I miss something? This is OK. -Sandra
Re: [patch, fortran, doc] Explicitly mention undefined overflow
Hi Thomas, Am 20.03.23 um 08:14 schrieb Thomas Koenig via Gcc-patches: so it the general problem is not restricted to -O3 and not to current trunk, it depends on the details. I doubt that the result from 9.4.0 was expected, but rather nobody noticed. Or, bringing out the pseudo-RNG into a different setting changed things. So... any suggestions on how to improve the current wording? how about changing: "... relying on a specific, non-standard behavior may now generate unexpected results." to "... relying on a specific, non-standard behavior may generate unexpected results depending on optimization level and other compiler flags." We cannot know all the codes used in the wild ... Cheers, Harald Best regards Thomas
[PATCH] Fortran: reject MODULE PROCEDURE outside generic module interface [PR99036]
Dear all,
the attached trivial patch catches a MODULE PROCEDURE outside of a
module interface before we run into an internal error.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This PR is marked as an 11/12/13 regression, so this is a candidate
for backporting.
Thanks,
Harald
From 9c59709fad91c99041a9cb770b98da17af01d260 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 20 Mar 2023 21:50:59 +0100
Subject: [PATCH] Fortran: reject MODULE PROCEDURE outside generic module
interface [PR99036]
gcc/fortran/ChangeLog:
PR fortran/99036
* decl.cc (gfc_match_modproc): Reject MODULE PROCEDURE if not in a
generic module interface.
gcc/testsuite/ChangeLog:
PR fortran/99036
* gfortran.dg/pr99036.f90: New test.
---
gcc/fortran/decl.cc | 1 +
gcc/testsuite/gfortran.dg/pr99036.f90 | 9 +
2 files changed, 10 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/pr99036.f90
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index c8f0bb83c2c..b29f491fe1f 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -9998,6 +9998,7 @@ gfc_match_modproc (void)
if ((gfc_state_stack->state != COMP_INTERFACE
&& gfc_state_stack->state != COMP_CONTAINS)
|| gfc_state_stack->previous == NULL
+ || !current_interface.type
|| current_interface.type == INTERFACE_NAMELESS
|| current_interface.type == INTERFACE_ABSTRACT)
{
diff --git a/gcc/testsuite/gfortran.dg/pr99036.f90 b/gcc/testsuite/gfortran.dg/pr99036.f90
new file mode 100644
index 000..a6e396f6f71
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr99036.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/99036 - ICE in gfc_current_interface_head
+! Contributed by G. Steinmetz
+
+module m
+contains
+ module procedure s ! { dg-error "must be in a generic module interface" }
+ end
+end
--
2.35.3
[PATCH] Fortran: fix documentation of -fno-underscoring [PR109216]
Dear all,
as reported, the implicit documentation of -funderscoring, which
is found under -fno-underscoring, has gone sideways long time ago.
The attached patch should fix it.
OK for mainline, or did I miss something?
Thanks,
Harald
From c296196044248f974b4907bb2f5bdeeea24adb5b Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 20 Mar 2023 20:55:00 +0100
Subject: [PATCH] Fortran: fix documentation of -fno-underscoring [PR109216]
gcc/fortran/ChangeLog:
PR fortran/109216
* invoke.texi: Correct documentation of how underscores are appended
to external names.
---
gcc/fortran/invoke.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 5679e2f2650..cbe7f377507 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1573,7 +1573,7 @@ Do not transform names of entities specified in the Fortran
source file by appending underscores to them.
With @option{-funderscoring} in effect, GNU Fortran appends one
-underscore to external names with no underscores. This is done to ensure
+underscore to external names. This is done to ensure
compatibility with code produced by many UNIX Fortran compilers.
@emph{Caution}: The default behavior of GNU Fortran is
@@ -1596,7 +1596,7 @@ I = J() + MAX_COUNT (MY_VAR, LVAR)
@noindent
is implemented as something akin to:
@smallexample
-i = j_() + max_count__(_var__, );
+i = j_() + max_count_(_var, );
@end smallexample
With @option{-fno-underscoring}, the same statement is implemented as:
--
2.35.3
Re: [PATCHv3, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]
Hi,
sorry for the belated reply.
On 07.03.23 09:55, HAO CHEN GUI wrote:
2023-03-07 Haochen Gui
gcc/
PR target/103628
* fortran/target-memory.cc (gfc_interpret_float): Return FAIL when
native_interpret_expr gets a NULL tree.
* fortran/arith.cc (gfc_hollerith2real): Return NULL when
gfc_interpret_float fails.
* fortran/error.cc (gfc_buffered_p): Define.
* fortran/gfortran.h (gfc_buffered_p): Declare.
* fortran/intrinsic.cc: Add diagnostic.h to include list.
(do_simplify): Save errorcount and check it at finish. Report a
"Cannot simplify expression" error on a bad result if error count
doesn't change and no other errors buffered.
gcc/testsuite/
PR target/103628
* gfortran.dg/pr103628.f90: New.
Co-Authored-By: Tobias Burnus
...
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
...
@@ -4708,7 +4710,12 @@ do_simplify (gfc_intrinsic_sym *specific, gfc_expr *e)
finish:
if (result == _bad_expr)
-return false;
+{
+ if (errorcount == old_errorcount
+ && (gfc_buffered_p () && !gfc_error_flag_test ()))
+ gfc_error ("Cannot simplify expression at %L", >where);
+ return false;
+}
The condition looks wrong. Shouldn't it be something like
+ && (!gfc_buffered_p () || !gfc_error_flag_test ()))
Namely:
* If there is no buffering, we know that no error has been printed → call error.
* With buffering, we additionally need to check for buffered errors.
No buffered error → call error.
Otherwise LGTM.
Thus, if my comment makes sense to you + it regtests, modify it, and
go ahead and commit it.
Sorry for the delay - and thanks again for the patch!
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Re: [patch, fortran, doc] Explicitly mention undefined overflow
I wrote: Yes, that's fine for trunk. I wonder if it is worth being explicit that linear congruential pseudo-random number generators can and do fail at -O3? I don't think we should put this into the docs, because that can change at any time. Maybe into porting_to.html, though (where I have only mentioned this as a general issue with linear congruential generators, without mentioning specific options. Current text can be seen at https://gcc.gnu.org/gcc-13/porting_to.html ). Hm Breaking things actually goes back further than I thought. Taking the random number generator from rnseed and running it 10 times with my system gfortran 9.4.0 gets me, at different levels of optimization: $ for a in -O0 -O1 -O2; do echo $a; gfortran $a genuni.f90 && ./a.out; done -O0 0.269411892 0.891386986 0.444042951 0.779210865 0.500058949 0.666437685 0.666963458 0.462416053 0.376364112 2.90278494E-02 -O1 0.269411892 0.891386986 0.444042951 0.779210865 0.500058949 0.666437685 0.666963458 0.462416053 0.376364112 2.90278494E-02 -O2 -0.730588138 0.891386986 -0.555957019 -0.220789105 -0.499941051 0.666437685 -0.333036542 0.462416053 0.376364112 2.90278494E-02 and for current trunk it is $ for a in -O0 -O1 -O2; do echo $a; gfortran $a genuni.f90 && ./a.out; done -O0 0.269411892 0.891386986 0.444042951 0.779210865 0.500058949 0.666437685 0.666963458 0.462416053 0.376364112 2.90278494E-02 -O1 0.269411892 0.891386986 0.444042951 0.779210865 0.500058949 0.666437685 0.666963458 0.462416053 0.376364112 2.90278494E-02 -O2 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 0.211324871 so it the general problem is not restricted to -O3 and not to current trunk, it depends on the details. I doubt that the result from 9.4.0 was expected, but rather nobody noticed. Or, bringing out the pseudo-RNG into a different setting changed things. So... any suggestions on how to improve the current wording? Best regards Thomas
