Re: [Patch] gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305] (was: [PATCH 3/3] [PR libfortran/101305] Fix ISO_Fortran_binding.h paths in gfortran testsuite)
On Thu, Jul 29, 2021 at 12:56:32AM +0200, Jakub Jelinek wrote: > On Wed, Jul 28, 2021 at 01:22:53PM +0200, Tobias Burnus wrote: > > gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305] > > > > gcc/testsuite/ > > PR libfortran/101305 > > * gfortran.dg/dg.exp: Add '-I /libgfortran' > > compile flag. > > Wouldn't it be better to do that in gcc/testsuite/lib/gfortran.exp > to GFORTRAN_UNDER_TEST there next to > -B$specpath/libgfortran/ ? > So that we don't add it for the installed gfortran testing - there > we want to test what installed gfortran will do, > and will affect also libgomp testing. Though, I guess we need that mostly for the C FE, so perhaps it needs to go at the start of additional_flags=, whether TEST_ALWAYS_FLAGS is empty or not. Jakub
[Patch] testsuite/lib/gfortran.exp: Add -I for ISO*.h [PR101305, PR101660] (was: Re: [Patch] gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305] (was: [PATCH 3/3] [PR libfortran/10130
On 29.07.21 09:09, Jakub Jelinek wrote:
On Thu, Jul 29, 2021 at 12:56:32AM +0200, Jakub Jelinek wrote:
On Wed, Jul 28, 2021 at 01:22:53PM +0200, Tobias Burnus wrote:
gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305]
Wouldn't it be better to do that in gcc/testsuite/lib/gfortran.exp
to GFORTRAN_UNDER_TEST there next to
-B$specpath/libgfortran/ ?
I guess so – and that's what I did. However, I had to ensure that it
gets reset otherwise it picks up the wrong header in multilib runs; this
also affects the -B$specpath/libgfortran bit, but I think that makes sense.
Though, I guess we need that mostly for the C FE, so perhaps it needs to go
at the start of additional_flags=, whether TEST_ALWAYS_FLAGS is empty or
not.
For the main testsuite (gcc/testsuite/*fortran*/), I believe the patch
above is sufficient as everything runs through GFORTRAN_UNDER_TEST.
I am also inclined not to add flags to TEST_ALWAYS_FLAGS which then
might get applied to other/pure C/C++ tests.
Regarding libgomp: that one uses xgcc for the compilation. I don't
really see a need to use the Fortran array descriptor from a C program
in libgomp's testsuite. Thus, I am inclined to ignore libgomp.
Otherwise, as libgomp does not gfortran_init and handles libraries
separately, I think the code needs to be put into
libgomp.*fortran/fortran.exp.
Thoughts? Okay?
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
testsuite/lib/gfortran.exp: Add -I for ISO*.h [PR101305, PR101660]
This patch adds -I$specdir/libgfortran to GFORTRAN_UNDER_TEST, when
set by proc gfortran_init. As the $specdir depends on the multilib
setting, it has to be re-set for a different multilib; hence, we track
whether a previous call to gfortran_init set that var or whether it
was set differently.
gcc/testsuite/
PR libfortran/101305
PR fortran/101660
* lib/gfortran.exp (gfortran_init): Add -I $specdir/libgfortran to
GFORTRAN_UNDER_TEST; update it when set by previous gfortran_init call.
* gfortran.dg/ISO_Fortran_binding_1.c: Use <...> not "..." for
ISO_Fortran_binding.h's #include.
* gfortran.dg/ISO_Fortran_binding_10.c: Likewise.
* gfortran.dg/ISO_Fortran_binding_11.c: Likewise.
* gfortran.dg/ISO_Fortran_binding_12.c: Likewise.
* gfortran.dg/ISO_Fortran_binding_15.c: Likewise.
* gfortran.dg/ISO_Fortran_binding_16.c: Likewise.
* gfortran.dg/ISO_Fortran_binding_17.c: Likewise.
* gfortran.dg/ISO_Fortran_binding_18.c: Likewise.
* gfortran.dg/ISO_Fortran_binding_3.c: Likewise.
* gfortran.dg/ISO_Fortran_binding_5.c: Likewise.
* gfortran.dg/ISO_Fortran_binding_6.c: Likewise.
* gfortran.dg/ISO_Fortran_binding_7.c: Likewise.
* gfortran.dg/ISO_Fortran_binding_8.c: Likewise.
* gfortran.dg/ISO_Fortran_binding_9.c: Likewise.
* gfortran.dg/PR94327.c: Likewise.
* gfortran.dg/PR94331.c: Likewise.
* gfortran.dg/bind_c_array_params_3_aux.c: Likewise.
* gfortran.dg/iso_fortran_binding_uint8_array_driver.c: Likewise.
* gfortran.dg/pr93524.c: Likewise.
diff --git a/gcc/testsuite/lib/gfortran.exp b/gcc/testsuite/lib/gfortran.exp
index 1e7da1110bc..cae6738b4b8 100644
--- a/gcc/testsuite/lib/gfortran.exp
+++ b/gcc/testsuite/lib/gfortran.exp
@@ -151,6 +151,7 @@ proc gfortran_init { args } {
global gcc_warning_prefix
global gcc_error_prefix
global TEST_ALWAYS_FLAGS
+global gfortran_init_set_GFORTRAN_UNDER_TEST
# We set LC_ALL and LANG to C so that we get the same error messages as expected.
setenv LC_ALL C
@@ -166,7 +167,11 @@ proc gfortran_init { args } {
setenv LANG C.ASCII
}
-if ![info exists GFORTRAN_UNDER_TEST] then {
+# GFORTRAN_UNDER_TEST as set below contains $specpath, which depends on
+# the used multilib config. Thus, its value may need to be reset;
+# that's tracked via gfortran_init_set_GFORTRAN_UNDER_TEST.
+if { ![info exists GFORTRAN_UNDER_TEST]
+ || [info exists gfortran_init_set_GFORTRAN_UNDER_TEST] } then {
if [info exists TOOL_EXECUTABLE] {
set GFORTRAN_UNDER_TEST $TOOL_EXECUTABLE
} else {
@@ -178,7 +183,8 @@ proc gfortran_init { args } {
} else {
set specpath [get_multilibs]
}
- set GFORTRAN_UNDER_TEST [findfile $base_dir/../../gfortran "$base_dir/../../gfortran -B$base_dir/../../ -B$specpath/libgfortran/" [findfile $base_dir/gfortran "$base_dir/gfortran -B$base_dir/" [transform gfortran]]]
+ set gfortran_init_set_GFORTRAN_UNDER_TEST 1
+ set GFORTRAN_UNDER_TEST [findfile $base_dir/../../gfortran "$base_dir/../../gfortran -B$base_dir/../../ -B$specpath/libgfortran/ -I$specpath/libgfortran" [findfile $base_dir/gfortran "$base_dir/gfortran -B$base_dir/" [transform gfortran]]]
}
}
}
diff --git a/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c b/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_1.c
--- a/gcc/testsuite
Fwd: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4
At a first look, this does not seem to involve anything Darwin-specific (particularly, since this is x86_64, so nothing using experimental support). … perhaps someone here can see what the issue might be? Iain > Begin forwarded message: > > From: Lawrence Doctors > Subject: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS > Big Sur Version 11.4 > Date: 29 July 2021 at 11:58:40 BST > To: "g...@gcc.gnu.org" > Cc: Lawrence Doctors > > Dear Sir/Madam: > > I would firstly like to thank the folks at GCC for their fine work on > developing the Fortran compilers, which I have been using for about 12 years > now, on a series of four MacBook Pro computers. In total, I have had over 50 > years experience using Fortran, this being on a variety of different > platforms. I therefore do consider myself as being a very experienced > programmer. > > I have recently installed your gfortran-10.2-catalina.dmg on macOS Big Sur > Version 11.4 with a 2.4 GHz 8-core Intel Core i9 processor. The computer has > 64 GB 2667 MHz DDR4 of memory, with a disk capacity of 8 TB. During my > previous experience, when I switched to a new computer on about six or seven > occasions, most of my programs (now 553 in number) compiled successfully the > first time, but some of the programs required minor modifications. On this > occasion, I encountered the following new challenges: > > (1) I see that you now check consistency of the argument types and rank, in > CALL statements. Thus, if an argument would normally be an array, but is > unused in some CALL statements, my practice was to use a dummy argument with > a short name, such as "d". This has worked for over 50 years without trouble. > However, you now check for consistency. Obviously this was easy to fix, as I > simple declared a dummy array in a DIMENSION statement with the name "d (1)", > which solved the problem. On reflection, I would say that this is an > improvement, because it forces the programmer to think carefully when writing > the CALL statement. > > (2) I encountered a curious failure on compilation with the following > statement using integer arithmetic: > n= (m + 4)/5 > with the message > Error: Integer division truncated to constant ‘2’ at (1) > [-Werror=integer-division] > f951: all warnings being treated as errors > > This error only occurs if both (a) the value of "m" would lead to a > truncation (say 7 but not 6), and ALSO if (b) the value of "m" was set in a > PARAMETER statement. I can work my way around this difficulty by rewriting > the statement as: > n= int ((1.0*m + 4)/5) > but it does seem clumsy. > > (3) The new compiler seems to dislike large fixed DIMENSION statements, such > as the following at the beginning of the program unit: > parameter (n= 105) > dimension a (n) > > The compiler then issues the following message: >3 | dimension a (n) > | 1 > Error: Array ‘a’ at (1) is larger than limit set by ‘-fmax-stack-var-size=’, > moved from stack to static storage. This makes the procedure unsafe when > called recursively, or concurrently from multiple threads. Consider using > ‘-frecursive’, or increase the ‘-fmax-stack-var-size=’ limit, or change the > code to use an ALLOCATABLE array. [-Werror=surprising] > f951: all warnings being treated as errors > > I agree that the message is clear and I was able to follow the suggestion to > use an ALLOCATABLE statement, but I still wonder why you consider the program > unsatisfactory in the first place. I can understand (to some degree) why such > a large array is frowned upon, because one should economize on the size of > arrays. On the other hand, if the use of a large array makes the task of the > programmer easier, it should be allowed. Furthermore, an array size of > 100 elements or so is very small, considering the size of the RAM and the > disk available nowadays. > > I would be pleased if you have the time to respond and I would like to > express my appreciation again for the considerable effort that your group has > invested in the Fortran compilers over the years. > > Sincerely, > > Larry > > Lawrence J. Doctors > Emeritus Professor > Naval Architecture Program > School of Mechanical and Manufacturing Engineering > The University of New South Wales > Sydney, NSW 2052, Australia > Email: l.doct...@unsw.edu.au > Telephone: +61-2-9371 4158 >
Re: Fwd: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4
On 29.07.21 13:26, Iain Sandoe wrote: … perhaps someone here can see what the issue might be? Lawrence Doctors wrote: (1) I see that you now check consistency of the argument types and rank, in CALL statements. Thus, if an argument would normally be an array, but is unused in some CALL statements, my practice was to use a dummy argument with a short name, such as "d". This has worked for over 50 years without trouble. However, you now check for consistency. Obviously this was easy to fix, as I simple declared a dummy array in a DIMENSION statement with the name "d (1)", which solved the problem. On reflection, I would say that this is an improvement, because it forces the programmer to think carefully when writing the CALL statement. I note that the Fortran standard requires that the actual argument must be an array (including array element see also "Storage Sequence") if the dummy argument is an (assumed-/explicit-size) array. Namely, Fortran Fortran 2018 requires in "15.5.2.4 Ordinary dummy variables": "If the actual argument is a noncoindexed scalar, the corresponding dummy argument shall be scalar unless • the actual argument is default character, of type character with the C character kind (18.2.2), or is an element or substring of an element of an array that is not an assumed-shape, pointer, or polymorphic array, • the dummy argument has assumed-rank, or • the dummy argument is an assumed-type assumed-size array." And "15.5.2.11 Sequence association" "Sequence association only applies when the dummy argument is an explicit-shape or assumed-size array. [...] An actual argument represents an element sequence if it is an array expression, an array element designator, a default character scalar, or a scalar of type character with the C character kind" [...] "An actual argument that represents an element sequence and corresponds to a dummy argument that is an arrayis sequence associated with the dummy argument. The rank and shape of the actual argument need not agreewith the rank and shape of the dummy argument, but the number of elements in the dummy argument shallnot exceed the number of elements in the element sequence of the actual argument. If the dummy argument is assumed-size, the number of elements in the dummy argument is exactly the number of elements in the element sequence." (2) I encountered a curious failure on compilation with the following statement using integer arithmetic: n= (m + 4)/5 with the message Error: Integer division truncated to constant ‘2’ at (1) [-Werror=integer-division] This error only occurs if both (a) the value of "m" would lead to a truncation (say 7 but not 6), and ALSO if (b) the value of "m" was set in a PARAMETER statement. I am confused. Can you give an example? I do get a warning (or with -Werror an error) for: implicit none integer :: n integer,parameter :: m = 7 n= (m + 4)/5 end But not for 6 (→ 6+4 = 10). That seems to be fine. Or did I miss something? (3) The new compiler seems to dislike large fixed DIMENSION statements, such as the following at the beginning of the program unit: parameter (n= 105) dimension a (n) The compiler then issues the following message: 3 | dimension a (n) | 1 Error: Array ‘a’ at (1) is larger than limit set by ‘-fmax-stack-var-size=’, moved from stack to static storage. This makes the procedure unsafe when called recursively, or concurrently from multiple threads. Consider using ‘-frecursive’, or increase the ‘-fmax-stack-var-size=’ limit, or change the code to use an ALLOCATABLE array. [-Werror=surprising] This kinds of makes sense, but not for the main program. All variable in the main program have implicitly the SAVE attribute and by construction, the main program cannot be called neither recursively nor concurrently. Thus: That's a (known) bug. You can use an explicit "save :: a" to silence this warning – in newer than May 17, 2021 versions of GCC - or wait for the proper fix. See the existing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 In both cases, I note that you do not have to use -Werror; try -Wno-error=surprising and -Wno-error=integer-division to downgrade those two error categories back to warnings. 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
