[Bug fortran/90504] Improved NORM2 algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90504 --- Comment #2 from Janne Blomqvist --- (In reply to anlauf from comment #1) > (In reply to Janne Blomqvist from comment #0) > > Hanson, Hopkins, Remark on Algorithm 539: A Modern Fortran Reference > > Implementation for Carefully Computing the Euclidean Norm, > > https://dl.acm.org/citation.cfm?id=3134441 > > > > Above article tests different algorithms for NORM2 and tests performance and > > numerical accuracy. > > This article is behind a paywall. > > Is there a publicly available description? https://kar.kent.ac.uk/67205/1/remark.pdf (Found via the https://unpaywall.org/ browser extension)
[Bug fortran/108131] New: Incorrect bound calculation when bound intrinsic used in size expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108131 Bug ID: 108131 Summary: Incorrect bound calculation when bound intrinsic used in size expression Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- This is from https://stackoverflow.com/questions/74814027/where-to-report-possible-gfortran-compiler-bug . Consider program test integer, parameter :: mg(0:10) = 0 integer, parameter :: u = ubound(mg, dim=1) integer, parameter :: cx(-1:ubound(mg, dim=1)) = 1 integer, parameter :: cy(-1:10) = 2 integer, parameter :: cz(-1:u) = 3 write(*,*) lbound(mg, dim=1), ubound(mg, dim=1) write(*,*) lbound(cx, dim=1), ubound(cx, dim=1) write(*,*) lbound(cy, dim=1), ubound(cy, dim=1) write(*,*) lbound(cz, dim=1), ubound(cz, dim=1) end program test Obviously the ubounds of all the 4 arrays should be 10. However running the program results in: $ ./a.out 0 10 -1 11 -1 10 -1 10 This affects master as of today, an earlier 12.x snapshot I had lying around, and 11.3.0 as shipped with Ubuntu 22.04. Based on a comment on the stackoverflow question, versions 7, 8, 9, and 10 are ok. Looking at -fdump-tree-original output, the error occurs already in the gfortran frontend.
[Bug fortran/107373] Unexpected result with loop optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107373 --- Comment #3 from Janne Blomqvist --- 63ee540430c3 might be related wrt fixing it?
[Bug libfortran/103886] Use 64-bit time_t on 32-bit glibc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886
--- Comment #4 from Janne Blomqvist ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Janne Blomqvist from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Is there anything to be done as the time_t is now defaults to 64bit on the
> > > trunk of glibc?
> >
> > AFAIU it's not the default, you need to explicitly opt-in by setting the
> > _TIME_BITS preprocessor macro to 64 (64-bit time_t is the default on musl,
> > and {Net,Open}BSD ).
> >
> > Or are you saying that since the _TIME_BITS thing was introduced (with glibc
> > 2.34), the upcoming 2.35/trunk has changed the default?
>
> Yes, the upcoming 2.35 has changed the default:
> https://sourceware.org/pipermail/libc-alpha/2021-December/134576.html
I'm not super-familiar with glibc, but it seems that this changes the default
(in ./bits/timesize.h) to 64 for targets not overriding it, however it
adds/modifies a number of target-specific overrides to retain the previous
behavior? In particular for x86 there is
./sysdeps/unix/sysv/linux/x86/bits/timesize.h which says:
#if defined __x86_64__ && defined __ILP32__
/* For x32, time is 64-bit even though word size is 32-bit. */
# define __TIMESIZE 64
#else
/* For others, time size is word size. */
# define __TIMESIZE __WORDSIZE
#endif
If my reading of the above is correct, on 32-bit x86 __TIMESIZE is set to
__WORDSIZE, that is, 32.
Similarly for ./sysdeps/unix/sysv/linux/arm/bits/timesize.h it says
#define __TIMESIZE 32
[Bug libfortran/103886] Use 64-bit time_t on 32-bit glibc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886
--- Comment #2 from Janne Blomqvist ---
(In reply to Andrew Pinski from comment #1)
> Is there anything to be done as the time_t is now defaults to 64bit on the
> trunk of glibc?
AFAIU it's not the default, you need to explicitly opt-in by setting the
_TIME_BITS preprocessor macro to 64 (64-bit time_t is the default on musl, and
{Net,Open}BSD ).
Or are you saying that since the _TIME_BITS thing was introduced (with glibc
2.34), the upcoming 2.35/trunk has changed the default?
[Bug libfortran/103886] New: Use 64-bit time_t on 32-bit glibc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886 Bug ID: 103886 Summary: Use 64-bit time_t on 32-bit glibc targets Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- In order to solve the Y2038 problem glibc now supports 64-bit time_t on 32-bit platforms. As this is an ABI change, it has to be explicitly enabled through setting the _TIME_BITS=64 preprocessor macro (similar to _FILE_OFFSET_BITS=64 to enable support for files larger than 2 GB). See https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html and https://sourceware.org/glibc/wiki/Y2038ProofnessDesign I don't think any time_t (or structs containing time_t members) are part of the libgfortran ABI, so this should be an internal change not requiring any ABI bumping. Some other 32-bit targets already have 64-bit time_t; At least NetBSD, OpenBSD and Linux with musl libc 1.2+, https://musl.libc.org/time64.html .
[Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #5 from Janne Blomqvist --- (In reply to anlauf from comment #1) > Not a confirmation, just an observation: libgfortran/intrinsics/time_1.h > prefers gettimeofday over clock_gettime, whereas the Linux manpages have: > > GETTIMEOFDAY(2) Linux Programmer's Manual > GETTIMEOFDAY(2) > > CONFORMING TO >SVr4, 4.3BSD. POSIX.1-2001 describes gettimeofday() but not > settimeofday(). >POSIX.1-2008 marks gettimeofday() as obsolete, recommending the use > of clock_get- >time(2) instead. > > > Janne chose this prioritization in 2012, but there is no comment explaining > his choice. Should this be revisited? Usage of gettimeofday() was, and still is, ubiquitous. In find it hard to imagine any C library would remove it just because POSIX has deprecated it, unless they want a significant fraction of applications to stop working. That being said, my main motivation for preferring gettimeofday() was that back then clock_gettime was not found in the glibc libc.so but rather in librt (which is part of glibc, but not linked by default for single-threaded programs). See the weakref trickery in intrinsics/system_clock.c for how using clock_gettime on glibc < 2.17 was done, where there was a real motivation for using clock_gettime, namely to access the monotonic clock. So preferring gettimeofday() in time_1.h:gf_gettime() meant that as many targets as possible used the same code path as glibc targets, reducing the risk of target-specific bugs that I would have difficulty deciphering considering I was developing on Linux myself. However, this is all water under the bridge by now, as clock_gettime is part of glibc libc.so since glibc 2.17. So I think switching the order now in 2021 is perfectly fine. As an additional datapoint, per https://man7.org/linux/man-pages/man7/vdso.7.html all Linux targets that provide gettimeofday() as a VDSO also provide clock_gettime() as a VDSO, so no concerns there either. As a minor nit, now that clock_gettime() is the "main" implementation for gf_gettime() you might want to change it to return nanoseconds rather than microseconds, and update the callers.
[Bug fortran/101632] NON_RECURSIVE procedure prefix is unsupported. F2018 defaults to recursive procedures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101632 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org Depends on||91413 --- Comment #4 from Janne Blomqvist --- In PR91413 we discussed the issue of stack overflows if recursive is made the default. Some decision and solution on that issue is needed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413 [Bug 91413] [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe
[Bug fortran/96319] New: Don't warn for LOGICAL kind conversion with -Wconversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96319 Bug ID: 96319 Summary: Don't warn for LOGICAL kind conversion with -Wconversion Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- From https://stackoverflow.com/questions/62937435/compilation-warning-with-gfortran-on-assignment-of-logicalc-bool-variable Consider the program PROGRAM boolean USE ISO_C_BINDING IMPLICIT NONE LOGICAL (KIND = C_BOOL) :: cbool INTEGER :: i, j i = 1 j = 2 cbool = i /= j WRITE(*,*) cbool END PROGRAM boolean Compiling with gfortran boolean.f90 -o boolean -Wall results in the warning boolean.f90:8:11: 8 |cbool = i /= j | 1 Warning: Possible change of value in conversion from LOGICAL(4) to LOGICAL(1) at (1) [-Wconversion] The warning is incorrect here as there's only one value bit in the LOGICAL variable regardless of the kind, and thus there is no risk of losing data even if this is a narrowing conversion.
[Bug libfortran/92836] segfault with inquire()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836 Janne Blomqvist changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #18 from Janne Blomqvist --- Assigning to myself, looking into the locking errors.
[Bug libfortran/92836] segfault with inquire()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836 --- Comment #17 from Janne Blomqvist --- (In reply to Jerry DeLisle from comment #15) > Did we conclude that this is an expected race condition? > > I run the example comment 14 and it just hangs for me. Well, hangs in what sense? For me it runs the while loop forever, as it should.
[Bug fortran/91413] [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413 --- Comment #7 from Janne Blomqvist --- (In reply to Tobias Burnus from comment #6) > Currently, direct recursive use is still not permitted: > > Error: Function ‘faculty’ at (1) cannot be called recursively, as it is not > RECURSIVE > > This has to be turned into "Error: Fortran 2018: ... without RECURSIVE". The more I think about this, the more I think the correct course of action is to just bite the bullet and make -frecursive the default. Having some threshold where we switch from stack to heap allocation is certainly less bad than switching to static memory like we do now, but it's still going behind the back of the user doing something the user didn't actually request (by using allocatables). > We also have to think about how to handle the -f(no-)automatic -frecursive > etc. with this change. – As "SAVE" is also allowed in recursive functions, > we just need to ensure that the old semantic stays the same and write a few > more words to the documentation. Yes, of course, variables with the SAVE attribute should always be placed in static memory to fulfill the standard requirements. > Regarding -fmax-stack-var-size=n and -fstack-arrays, one also needs to > should point out the implications regarding recursive use, possibly the > effect of an explicit RECURSIVE and Fortran >= 2018. Yes, if we make -frecursive the default this should be documented, along with instructions what to do if the program starts crashing due to running out of stack space. I.e. emphasizing using allocatables, and flashing "Danger Will Robinson" signs around -fmax-stack-var-size and -fno-automatic options that can be used to work around the issue without modifying the program. > Regarding the stack to static handling: I think we currently also print the > message if the user has explicitly given "NON_RECURSIVE" as the flag is > currently binary (recursive - true/false) but it should keep track of > (nonspecified, recursive, non_recursive). Currently the parser doesn't understand NON_RECURSIVE. But even when that is fixed, does it need to be non-binary? It can still be a binary flag, in case it's not specified the flag can be set based on the chosen std flags?
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 --- Comment #19 from Janne Blomqvist --- This latest commit fixes the testsuite failure. Thanks for the quick fix.
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 Janne Blomqvist changed: What|Removed |Added Status|RESOLVED|REOPENED CC||jb at gcc dot gnu.org Resolution|FIXED |--- --- Comment #13 from Janne Blomqvist --- Running the testsuite on today's master (2020-01-18) on x86_64-pc-linux-gnu fails with FAIL: gfortran.dg/pr93263_1.f90 -O scan-tree-dump-not original "integer\\(kind=4\\) a"
[Bug libfortran/92836] segfault with inquire()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836 --- Comment #13 from Janne Blomqvist --- To clarify my previous message, instead of inquire(..., exist=exist) if (exist) then open(...) else ! Handle file not existing end if you can do open(..., status='old', iostat=stat) if (stat /= o) then ! Handle file not existing end if If you open a file with status='old', then opening the file will fail if it doesn't exist, and thus there is no race between checking whether the file exists with inquire and trying to open it. Similarly, if you want to make sure that the file is created, i.e. that it doesn't exist previously, instead of doing inquire(..., exist=exist) if (!exist) then open(...) else ! Handle if the file does exist end if You should do open(..., status='new', iostat=stat) if (stat /= 0) then ! Handle file existing end if With status='new', the file will be created and opened with O_CREAT|O_EXCL which is guaranteed to be atomic.
[Bug libfortran/92836] segfault with inquire()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836 --- Comment #9 from Janne Blomqvist --- (In reply to Thomas Koenig from comment #8) > > No. The inquire() is used only to see if the file exists already. If it > > does, the code branches to read the file, if it does not, the code branches > > to generate the data for the file and then write it. > > You have to watch out here. > > If you are > > a) using INQUIRE to check if the file exists > > b) using OPEN if it does not > > in a thread, this is classic race condition - separate threads > may INQUIRE and then try to open, in parallel. This is not atomic, > and is a classic race condition. > > You should always put such a sequence into OMP CRITICAL. This has > the nice side effect that you will also avoid this bug (which should > be fixed regardless). > > Also, why do you use inquire at all? AFAIK, it is not an error > to OPEN a file more than one if you don't change anything, so > a simple > > open (10,file="foo.dat",status="unknown") > > should, in principle, work even with OpenMP; if it doesn't, this is > another bug that needs fixing. The best way in cases like this is usually to skip the inquire, try to open the file with a suitable value for status=, and if the open fails handle the error. That avoids the race condition. That being said, like you say, this is still a case that GFortran should handle without crashing, so yes it's a bug that should be fixed.
[Bug libfortran/92836] segfault with inquire()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #5 from Janne Blomqvist --- (In reply to Andrew Benson from comment #1) > Running with -fsanitize=thread (suggested by Tobias) gives: > > == > WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) > (pid=9982) > Cycle in lock order graph: M26 (0x7f02bb31c340) => M84 (0x7b58002efee0) => > M26 > > Mutex M84 acquired here while holding mutex M26 in thread T63: > #0 pthread_mutex_lock > ../../../../gcc-trunk/libsanitizer/sanitizer_common/ > sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x5095a) > #1 __gthread_mutex_lock ../libgcc/gthr-default.h:749 (libgfortran.so. > 5+0x1e25c9) > #2 insert_unit ../../../gcc-trunk/libgfortran/io/unit.c:244 > (libgfortran.so.5+0x1e25c9) > #3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so. > 1+0x198a5) > > Mutex M26 previously acquired by the same thread here: > #0 pthread_mutex_lock > ../../../../gcc-trunk/libsanitizer/sanitizer_common/ > sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x5095a) > #1 __gthread_mutex_lock ../libgcc/gthr-default.h:749 (libgfortran.so. > 5+0x1e265c) > #2 get_gfc_unit ../../../gcc-trunk/libgfortran/io/unit.c:332 > (libgfortran.so.5+0x1e265c) > #3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so. > 1+0x198a5) > > Mutex M26 acquired here while holding mutex M84 in thread T63: > #0 pthread_mutex_lock > ../../../../gcc-trunk/libsanitizer/sanitizer_common/ > sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x5095a) > #1 __gthread_mutex_lock ../libgcc/gthr-default.h:749 (libgfortran.so. > 5+0x1e336b) > #2 close_unit_1 ../../../gcc-trunk/libgfortran/io/unit.c:735 > (libgfortran.so.5+0x1e336b) > #3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so. > 1+0x198a5) > > Mutex M84 previously acquired by the same thread here: > #0 pthread_mutex_trylock ../../../../gcc-trunk/libsanitizer/tsan/ > tsan_interceptors_posix.cpp:1246 (libtsan.so.0+0x4340a) > #1 __gthread_mutex_trylock ../libgcc/gthr-default.h:758 (libgfortran.so. > 5+0x1e26f1) > #2 get_gfc_unit ../../../gcc-trunk/libgfortran/io/unit.c:380 > (libgfortran.so.5+0x1e26f1) > #3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so. > 1+0x198a5) > > Thread T63 (tid=10047, running) created by main thread at: > #0 pthread_create ../../../../gcc-trunk/libsanitizer/tsan/ > tsan_interceptors_posix.cpp:962 (libtsan.so.0+0x5bb22) > #1 gomp_team_start ../../../gcc-trunk/libgomp/team.c:839 (libgomp.so. > 1+0x19eba) > #2 main (a.out+0x400ef9) > > SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) > ../libgcc/ > gthr-default.h:749 in __gthread_mutex_lock > == FWIW, this is a known problem (don't know if there's a PR for it). As far as I've been able to see, the problem is that threadsanitizer cannot prove that the unit locking scheme is correct even though it is. Of course, it would be nice if we could redesign the locking so that threadsanitizer would be happy, as then threadsanitizer would be more useful for us.
[Bug middle-end/92463] Cleanups due to minimum MPFR version bump to 3.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 Janne Blomqvist changed: What|Removed |Added Component|fortran |middle-end --- Comment #4 from Janne Blomqvist --- Fortran parts done, reassigning to middle-end as there are similar MPFR modernization opportunities there.
[Bug fortran/92463] Cleanups due to minimum MPFR version bump to 3.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 --- Comment #3 from Janne Blomqvist --- Author: jb Date: Wed Nov 20 20:08:29 2019 New Revision: 278525 URL: https://gcc.gnu.org/viewcvs?rev=278525&root=gcc&view=rev Log: PR 92463 MPFR modernization: Revert r269139 Commit r269139 fixed an accidental dependency on MPFR 3.0. As we now require at least MPFR 3.1.0+ we can revert it and instead use the simpler MPFR 3.0+ code. ChangeLog entry of the original commit was: 2019-02-23 David Malcolm Jakub Jelinek PR middle-end/88074 * simplify.c (norm2_do_sqrt, gfc_simplify_norm2): Use mpfr_number_p && !mpfr_zero_p instead of mpfr_regular_p. (norm2_add_squared): Likewise. Use mp_exp_t rather than mpfr_exp_t. ChangeLog for this commit: 2019-11-20 Janne Blomqvist PR fortran/92463 Revert r269139 * simplify.c (norm2_do_sqrt, gfc_simplify_norm2): Use mpfr_regular_p instead of mpfr_number_p && !mpfr_zero_p. (norm2_add_squared): Likewise. Use mpfr_exp_t rather than mp_exp_t. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c
[Bug tree-optimization/88074] [7 Regression] g++ hangs on math expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074 --- Comment #38 from Janne Blomqvist --- Author: jb Date: Wed Nov 20 20:08:29 2019 New Revision: 278525 URL: https://gcc.gnu.org/viewcvs?rev=278525&root=gcc&view=rev Log: PR 92463 MPFR modernization: Revert r269139 Commit r269139 fixed an accidental dependency on MPFR 3.0. As we now require at least MPFR 3.1.0+ we can revert it and instead use the simpler MPFR 3.0+ code. ChangeLog entry of the original commit was: 2019-02-23 David Malcolm Jakub Jelinek PR middle-end/88074 * simplify.c (norm2_do_sqrt, gfc_simplify_norm2): Use mpfr_number_p && !mpfr_zero_p instead of mpfr_regular_p. (norm2_add_squared): Likewise. Use mp_exp_t rather than mpfr_exp_t. ChangeLog for this commit: 2019-11-20 Janne Blomqvist PR fortran/92463 Revert r269139 * simplify.c (norm2_do_sqrt, gfc_simplify_norm2): Use mpfr_regular_p instead of mpfr_number_p && !mpfr_zero_p. (norm2_add_squared): Likewise. Use mpfr_exp_t rather than mp_exp_t. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c
[Bug fortran/92463] Cleanups due to minimum MPFR version bump to 3.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 --- Comment #2 from Janne Blomqvist --- Author: jb Date: Wed Nov 20 20:01:25 2019 New Revision: 278523 URL: https://gcc.gnu.org/viewcvs?rev=278523&root=gcc&view=rev Log: PR 92463 MPFR modernization in GFortran Now that we require a minimum of MPFR 3.1.0+ to build GCC, we can do some modernization of the MPFR usage in the GFortran frontend. This patch replaces 1) GMP_RND* with MPFR_RND* 2) mp_exp_t with mpfr_exp_t 3) mp_prec_t with mpfr_prec_t 4) mp_rnd_t with mpfr_rnd_t gcc/fortran/ChangeLog: 2019-11-20 Janne Blomqvist PR fortran/92463 * arith.c (gfc_mpfr_to_mpz): Change mp_exp_t to mpfr_exp_t. (gfc_check_real_range): Likewise. * gfortran.h (GFC_RND_MODE): Change GMP_RNDN to MPFR_RNDN. * module.c (mio_gmp_real): Change mp_exp_t to mpfr_exp_t. * simplify.c (degrees_f): Change mp_rnd_t to mpfr_rnd_t. (radians_f): Likewise. (fullprec_erfc_scaled): Change mp_prec_t to mpfr_prec_t. (asympt_erfc_scaled): Likewise. (gfc_simplify_nearest): Change mp_exp_t to mpfr_exp_t, and GMP_RND* to MPFR_RND*. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/module.c trunk/gcc/fortran/simplify.c
[Bug fortran/92463] Cleanups due to minimum MPFR version bump to 3.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 --- Comment #1 from Janne Blomqvist --- Seems r269139 can be reverted, that's apparently a patch to fix some accidental breakage due to depending on a too new MPFR version.
[Bug fortran/92463] Cleanups due to minimum MPFR version bump to 3.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 Bug 92463 depends on bug 91828, which changed state. Bug 91828 Summary: gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR 3.0.0, unavailable in mpfr-2.4.2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91828 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/91828] gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR 3.0.0, unavailable in mpfr-2.4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91828 Janne Blomqvist changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Janne Blomqvist --- Fixed on trunk, closing. Also added a note to https://gcc.gnu.org/gcc-10/changes.html .
[Bug fortran/92463] New: Cleanups due to minimum MPFR version bump to 3.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 Bug ID: 92463 Summary: Cleanups due to minimum MPFR version bump to 3.1.0 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- As part of resolving PR 91828, the minimum MPFR version required to build GCC was bumped to 3.1.0 from the previous 2.4.0. This enables a bunch of cleanups, mostly in the Fortran frontend (hence assigning this bug to the fortran component). From https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01544.html : > For example, you could justify a move to requiring MPFR 3.0.0 or later with cleanups to use MPFR_RND* instead of the older GMP_RND*, and similarly mpfr_rnd_t instead of the older mp_rnd_t and likewise mpfr_exp_t and mpfr_prec_t in fortran/. You could justify a move to requiring MPC 1.0.0 (or 1.0.2) by optimizing clog10 using mpc_log10. I don't know what if any newer GMP interfaces would be beneficial in GCC. And as always in such cases, it's a good idea to look at e.g. how widespread the newer versions are in GNU/Linux distributions, which indicates how many people might be affected by an increase in the version requirement.
[Bug fortran/91828] gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR 3.0.0, unavailable in mpfr-2.4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91828 --- Comment #6 from Janne Blomqvist --- Author: jb Date: Mon Nov 11 15:59:48 2019 New Revision: 278058 URL: https://gcc.gnu.org/viewcvs?rev=278058&root=gcc&view=rev Log: Bump minimum MPFR version to 3.1.0 Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this requirement one can still build GCC with the operating system provided MPFR on old but still supported operating systems like SLES 12 (MPFR 3.1.2) or RHEL/CentOS 7.x (MPFR 3.1.1). This allows removing some code in the Fortran frontend, as well as fixing PR 91828. ChangeLog: 2019-11-11 Janne Blomqvist PR fortran/91828 * configure.ac: Bump minimum MPFR to 3.1.0, recommended to 3.1.6+. * configure: Regenerated. gcc/ChangeLog: 2019-11-11 Janne Blomqvist PR fortran/91828 * doc/install.texi: Document that the minimum MPFR version is 3.1.0. gcc/fortran/ChangeLog: 2019-11-11 Janne Blomqvist PR fortran/91828 * simplify.c (gfc_simplify_fraction): Remove fallback path for MPFR < 3.1.0. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/doc/install.texi trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c
[Bug fortran/91413] [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413 --- Comment #5 from Janne Blomqvist --- Author: jb Date: Sun Nov 10 21:25:25 2019 New Revision: 278027 URL: https://gcc.gnu.org/viewcvs?rev=278027&root=gcc&view=rev Log: Don't print warning when moving to static with -fno-automatic As part of PR 91413, GFortran now prints a warning when a variable is moved from the stack to static storage. However, when the user explicitly specifies that all local variables should be put in static storage with the -fno-automatic option, don't print this warning. Regtested on x86_64-pc-linux-gnu, committed as obvious. gcc/fortran/ChangeLog: 2019-11-10 Janne Blomqvist PR fortran/91413 * trans-decl.c (gfc_finish_var_decl): Don't print warning when -fno-automatic is enabled. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c
[Bug fortran/91828] gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR 3.0.0, unavailable in mpfr-2.4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91828 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-11/msg00676.ht ||ml Last reconfirmed||2019-11-09 Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Janne Blomqvist --- Assigning to myself, patch at https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00676.html
[Bug fortran/91828] gcc/fortran/check.c requires mpfr_set_z_2exp from MPFR 3.0.0, unavailable in mpfr-2.4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91828 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #4 from Janne Blomqvist --- FWIW, on the RHEL/CentOS side of the fence, RHEL 6 has MPFR 2.4.1, which is already older than the 2.4.2 we require now. RHEL 7 has 3.1.1.
[Bug libfortran/91543] [10 Regression] nf failure ( Handling stack overflow more sensibly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91543 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #5 from Janne Blomqvist --- Is https://gcc.gnu.org/viewcvs?rev=274264&root=gcc&view=rev the culprit? And if so, should be reduce it back to the previous default of 32 kB? (A bummer, I had hoped to eventually make -frecursive the default..)
[Bug fortran/48419] [ABI cleanup] Reduce gfortran stack usage for procedures doing IO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48419
--- Comment #9 from Janne Blomqvist ---
Like Jerry said, we've recently had an ABI break (two, actually!), and I think
we should try hard to avoid yet another one. I think it should be possible to
create some new st_parameter_dt_2 or such, as well as a new
data_transfer_init_2 entry point, and keep the old ones around for backwards
compatibility, rewriting data_transfer_init to wrap the new way of doing
things.
We can actually start with that, by moving private fields from st_parameter_dt
to gfc_unit. Or maybe make a separate per-data-transfer struct that is part of
gfc_unit, so that it can easily be memset() to 0 when starting a new data
transfer instead of having to separately touch every field.
I'm also thinking one way to speed up IO statements, if instead of memset()ing
said struct to zero, then go through every possible I/O specifier and set it to
the default value if missing etc., what if we had a few "ready-made" structs
(say one for formatted sequential, one for unformatted sequential, one for
unformatted direct etc.), and we just memcpy() the default struct. Then we'd
need to modify only the few fields that the flags variable say are present in
the I/O statement. But this can be done later.
Finally, for the new ABI entry points to save stack space, if for
data_transfer_init_2 we adopt approach b) that I described in the first message
in this PR, the st_parameter_dt_2 struct need to only contain the pointer to
the gfc_unit structure, and maybe a few other things.
That is, what the frontend passes is the unit number (that can be handled
separately since it's always present), the flags variable, the
st_parameter_dt_2 struct which contains the pointer to the gfc_unit struct (and
maybe a few other fields?), and a pointer to an array (that the frontend
creates on the stack prior to calling data_transfer_init_2) with elements
union dt_elem {
void* ptr;
int c_int;
size_t usize;
ptrdiff_t isize;
GFC_IO_INT io_int;
}
and then popcount(flags) would tell the number of elements in the array, except
for character arguments which would take two elements, one for the pointer to
the string and another for the length. And the order of the elements in the
array would be determined by the flags argument.
[Bug fortran/91413] [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413 Janne Blomqvist changed: What|Removed |Added Assignee|jb at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #4 from Janne Blomqvist --- Unassigning myself. Pointer to effort to start discussion on how to properly solve this at https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00687.html
[Bug fortran/91443] -Wargument-mismatch does not catch mismatch for global procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91443 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #3 from Janne Blomqvist --- I'm seeing a failure in the testcase libgomp.fortran/appendix-a/a.28.5.f90 which looks like it might(?) be caused by this: $ gfortran a.28.5.f90 a.28.5.f90:29:20: 29 | CALL SUB1(A) |1 Error: Rank mismatch in argument ‘x’ at (1) (rank-1 and scalar) Or is this something else?
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 Bug 91300 depends on bug 68401, which changed state. Bug 68401 Summary: improve 'Allocation would exceed memory limit' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Janne Blomqvist --- Fixed on trunk, closing.
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 --- Comment #13 from Janne Blomqvist --- Author: jb Date: Sat Aug 17 05:45:37 2019 New Revision: 274599 URL: https://gcc.gnu.org/viewcvs?rev=274599&root=gcc&view=rev Log: PR fortran/68401 Improve allocation error message Improve the error message that is printed when a memory allocation fails, by including the location, and the size of the allocation that failed. Regtested on x86_64-pc-linux-gnu. gcc/fortran/ChangeLog: 2019-08-17 Janne Blomqvist PR fortran/68401 * trans-decl.c (gfc_build_builtin_function_decls): Replace os_error with os_error_at decl. * trans.c (trans_runtime_error_vararg): Modify so the error function decl is passed directly. (gfc_trans_runtime_error): Pass correct error function decl. (gfc_trans_runtime_check): Likewise. (trans_os_error_at): New function. (gfc_call_malloc): Use trans_os_error_at. (gfc_allocate_using_malloc): Likewise. (gfc_call_realloc): Likewise. * trans.h (gfor_fndecl_os_error): Replace with gfor_fndecl_os_error_at. libgfortran/ChangeLog: 2019-08-17 Janne Blomqvist PR fortran/68401 * gfortran.map: Add GFORTRAN_10 node, add _gfortran_os_error_at symbol. * libgfortran.h (os_error_at): New prototype. * runtime/error.c (os_error_at): New function. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Janne Blomqvist changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-08/msg01172.ht ||ml --- Comment #12 from Janne Blomqvist --- Patch at https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01172.html With this the test.f90 in the original report prints something like: In file 'test.f90', around line 5: Error allocating 4294967296 bytes: Cannot allocate memory Error termination. Backtrace: #0 0x400874 in test at /home/janne/src/gfortran/my-patches/pr68401-oserror/test.f90:4 #1 0x4008d3 in main at /home/janne/src/gfortran/my-patches/pr68401-oserror/test.f90:4 (yes, the location is off a little bit)
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Janne Blomqvist changed: What|Removed |Added Status|WAITING |NEW CC||jb at gcc dot gnu.org Blocks||91300 Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #11 from Janne Blomqvist --- The variadic os_error type function is probably also necessary for solving PR 91300. Taking a stab at this. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 [Bug 91300] Wrong runtime error message with allocate and errmsg=
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Janne Blomqvist --- Fixed on trunk, and improved seeding backported to 9 and 8 branches. Closing.
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 --- Comment #8 from Janne Blomqvist --- Author: jb Date: Tue Aug 13 09:04:18 2019 New Revision: 274365 URL: https://gcc.gnu.org/viewcvs?rev=274365&root=gcc&view=rev Log: PR fortran/91414 Bugfix for previous commit Correctly fill master_seed from os_seed. Modified: trunk/libgfortran/intrinsics/random.c
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 --- Comment #7 from Janne Blomqvist --- Author: jb Date: Tue Aug 13 09:02:25 2019 New Revision: 274364 URL: https://gcc.gnu.org/viewcvs?rev=274364&root=gcc&view=rev Log: PR fortran/91414 Correctly fill master_state from os_seed. Modified: branches/gcc-9-branch/libgfortran/intrinsics/random.c
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 --- Comment #6 from Janne Blomqvist --- Author: jb Date: Tue Aug 13 09:00:46 2019 New Revision: 274363 URL: https://gcc.gnu.org/viewcvs?rev=274363&root=gcc&view=rev Log: PR fortran/91414 Improve initialization of PRNG As part of PR 91414 an improved PRNG was contributed to trunk. This is a partial backport of some related changes to the PRNG. Namely when seeding the PRNG, it needs only 8 bytes of randomness from the OS, and uses a simple splitmix64 PRNG to fill in the rest of the state, instead of getting all the state from the OS. This can be useful for operating systems that can run out of entropy. libgfortran/ChangeLog: 2019-08-13 Janne Blomqvist Partial backport from trunk PR fortran/91414 * intrinsics/random.c (lcg_parkmiller): Replace with splitmix64. (splitmix64): New function. (getosrandom): Fix return value, simplify. (init_rand_state): Use getosrandom only to get 8 bytes, splitmix64 to fill rest of state. Modified: branches/gcc-8-branch/libgfortran/ChangeLog branches/gcc-8-branch/libgfortran/intrinsics/random.c
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 --- Comment #5 from Janne Blomqvist --- Author: jb Date: Tue Aug 13 08:42:43 2019 New Revision: 274362 URL: https://gcc.gnu.org/viewcvs?rev=274362&root=gcc&view=rev Log: PR fortran/91414 Improve initialization of PRNG As part of PR 91414 an improved PRNG was contributed to trunk. This is a partial backport of some related changes to the PRNG. Namely when seeding the PRNG, it needs only 8 bytes of randomness from the OS, and uses a simple splitmix64 PRNG to fill in the rest of the state, instead of getting all the state from the OS. This can be useful for operating systems that can run out of entropy. libgfortran/ChangeLog: 2019-08-13 Janne Blomqvist Partial backport from trunk PR fortran/91414 * intrinsics/random.c (lcg_parkmiller): Replace with splitmix64. (splitmix64): New function. (getosrandom): Fix return value, simplify. (init_rand_state): Use getosrandom only to get 8 bytes, splitmix64 to fill rest of state. Modified: branches/gcc-9-branch/libgfortran/ChangeLog branches/gcc-9-branch/libgfortran/intrinsics/random.c
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 --- Comment #4 from Janne Blomqvist --- Author: jb Date: Tue Aug 13 08:24:43 2019 New Revision: 274361 URL: https://gcc.gnu.org/viewcvs?rev=274361&root=gcc&view=rev Log: PR fortran/91414: Improved PRNG Update the PRNG from xorshift1024* to xoshiro256** by the same author. For details see http://prng.di.unimi.it/ and the paper at https://arxiv.org/abs/1805.01407 Also the seeding is slightly improved, by reading only 8 bytes from the operating system and using the simple splitmix64 PRNG to fill in the rest of the PRNG state (as recommended by the xoshiro author), instead of reading the entire state from the OS. Regtested on x86_64-pc-linux-gnu, Ok for trunk? gcc/fortran/ChangeLog: 2019-08-13 Janne Blomqvist PR fortran/91414 * check.c (gfc_check_random_seed): Reduce seed_size. * intrinsic.texi (RANDOM_NUMBER): Update to match new PRNG. gcc/testsuite/ChangeLog: 2019-08-13 Janne Blomqvist PR fortran/91414 * gfortran.dg/random_seed_1.f90: Update to match new seed size. libgfortran/ChangeLog: 2019-08-13 Janne Blomqvist PR fortran/91414 * intrinsics/random.c (prng_state): Update state struct. (master_state): Update to match new size. (get_rand_state): Update to match new PRNG. (rotl): New function. (xorshift1024star): Replace with prng_next. (prng_next): New function. (jump): Update for new PRNG. (lcg_parkmiller): Replace with splitmix64. (splitmix64): New function. (getosrandom): Fix return value, simplify. (init_rand_state): Use getosrandom only to get 8 bytes, splitmix64 to fill rest of state. (random_r4): Update to new function and struct names. (random_r8): Likewise. (random_r10): Likewise. (random_r16): Likewise. (arandom_r4): Liekwise. (arandom_r8): Likewise. (arandom_r10): Likwewise. (arandom_r16): Likewise. (xor_keys): Reduce size to match new PRNG. (random_seed_i4): Update to new function and struct names, remove special handling of variable p used in previous PRNG. (random_seed_i8): Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/random_seed_1.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/random.c
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-08-12 CC||jb at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Janne Blomqvist --- AFAICT this is a valid bug report, albeit maybe not of the highest priority. The problem is that the code in the fortran frontend for handling this is a flaming mess. Without stat=, it properly generates a call to an error handling function in libgfortran, which examines errno and uses strerror() (or depending on what is available on the target, strerror_l() or strerror_r() ) to convert errno to a string describing the error why the allocation fails. However, if stat= and errmsg= are present, the only possible errmsg= value is a string literal with the value "Attempt to allocate an allocated object", which in this case is not correct. GFortran should do something similar to the allocate without stat= also in this case, that is, use one of the strerror() family functions to translate the errno value set by malloc() to a useful error message. (In reply to zed.three from comment #2) > The perceived wisdom is that it is best > practice to always use `stat` with `allocate`, and the addition of `errmsg` > now gives us something portable to hopefully get a sensible error message. Perceived wisdom is wrong, then, if all you do with stat= is print the errmsg= error message and stop the program, because that's what the compiler already does for you if you omit the stat= specifier (or, modulo bugs like this one, should do). allocate(stat=) is useful only if you can somehow recover usefully from failing to allocate. E.g. switch to another less memory-hungry algorithm, sparser grid, or whatever. And even so, thanks to overcommit in many operating systems such as Linux, this isn't likely to work usefully anyway. > I'm certainly not saying this is a show-stopper, but I don't think it's at > all stupid to expect useful error messages. I agree.
[Bug fortran/91413] [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413 --- Comment #3 from Janne Blomqvist --- Author: jb Date: Sun Aug 11 09:42:41 2019 New Revision: 274264 URL: https://gcc.gnu.org/viewcvs?rev=274264&root=gcc&view=rev Log: PR fortran/91413 Generate warning when making array static When moving a local variable from the stack to static storage, the procedure is no longer safe to be called recursively or concurrently from multiple threads. Thus generate a warning when this is done. Also double the default limit for switching from stack to static. Regtested on x86_64-pc-linux-gnu. gcc/fortran/ChangeLog: 2019-08-11 Janne Blomqvist PR fortran/91413 * invoke.texi (-fmax-stack-var-size): Document increased default. * options.c (gfc_post_options): Increase default stack var size to 65536 bytes. * trans-decl.c (gfc_finish_var_decl): Generate warning when local array moved to static storage. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-decl.c
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 Janne Blomqvist changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-08/msg00686.ht ||ml --- Comment #3 from Janne Blomqvist --- Patch at https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00686.html
[Bug fortran/91414] Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 Janne Blomqvist changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #2 from Janne Blomqvist --- I have a cunning plan..
[Bug fortran/91413] [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413 Janne Blomqvist changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-08/msg00679.ht ||ml Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #2 from Janne Blomqvist --- Patch at https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00679.html
[Bug fortran/91414] New: Improved PRNG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91414 Bug ID: 91414 Summary: Improved PRNG Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- Currently GFortran uses the xorshift1024* PRNG. The author of that PRNG has an improved PRNG "xoshiro" at http://prng.di.unimi.it/ , described in detail at https://arxiv.org/abs/1805.01407 . GFortran could (should?) switch to this improved algorithm.
[Bug fortran/91413] New: [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413 Bug ID: 91413 Summary: [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- As of Fortran 2018, procedures are recursive by default. However, currently GFortran places automatic arrays larger than the limit specified by -fmax-stack-var-size= (default 32768 bytes(?)) in static memory, which breaks reentrancy and thread-safety. Removing this outright, in effect making -frecursize the default, is probably not OK either as that would cause many applications to crash due to exhausting stack space. The remaining option then would be to switch to using heap memory rather than static memory for local arrays going over the limit. For a thread on this topic, see https://gcc.gnu.org/ml/fortran/2017-12/msg00082.html
[Bug fortran/53796] I/O INQUIRE of RECL: If not specified in OPEN, the default value should be returned (sequential access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53796 --- Comment #23 from Janne Blomqvist --- Author: jb Date: Wed Aug 7 07:34:10 2019 New Revision: 274160 URL: https://gcc.gnu.org/viewcvs?rev=274160&root=gcc&view=rev Log: PR 53796 Make inquire(file=, recl=) conform to F2018 In my original patch to fix PR 53796 I forgot to fix the behavior for unconnected units when inquiring via filename. This patch fixes that. Regtested on x86_64-pc-linux-gnu, committed as obvious. libgfortran/ChangeLog: 2019-08-07 Janne Blomqvist PR fortran/53796 * io/inquire.c (inquire_via_filename): Set recl to -1 for unconnected units. gcc/testsuite/ChangeLog: 2019-08-07 Janne Blomqvist PR fortran/53796 * gfortran.dg/inquire_recl_f2018.f90: Test for unconnected unit with inquire via filename. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/inquire_recl_f2018.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/inquire.c
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #39 from Janne Blomqvist --- Now, with the fixed benchmark in the previous comment, on Lustre (version 2.5) system I get: Test using 25000 bytes Block size of file system: 4096 bs = 1024, 53.27 MiB/s bs = 2048, 73.99 MiB/s bs = 4096, 222.41 MiB/s bs = 8192, 351.38 MiB/s bs = 16384, 483.86 MiB/s bs = 32768, 583.76 MiB/s bs = 65536, 677.11 MiB/s bs = 131072, 748.60 MiB/s bs = 262144, 700.69 MiB/s bs = 524288, 811.76 MiB/s bs =1048576, 1032.99 MiB/s bs =2097152, 1034.03 MiB/s bs =4194304, 1063.74 MiB/s bs =8388608, 1030.15 MiB/s bs = 16777216, 1084.82 MiB/s bs = 33554432, 1067.05 MiB/s bs = 67108864, 1063.79 MiB/s On the same system, on a NFS filesystem connected with Infiniband I get: Test using 25000 bytes Block size of file system: 1048576 bs = 1024, 301.41 MiB/s bs = 2048, 351.51 MiB/s bs = 4096, 471.39 MiB/s bs = 8192, 444.61 MiB/s bs = 16384, 510.88 MiB/s bs = 32768, 527.99 MiB/s bs = 65536, 516.57 MiB/s bs = 131072, 481.38 MiB/s bs = 262144, 514.29 MiB/s bs = 524288, 462.06 MiB/s bs =1048576, 528.30 MiB/s bs =2097152, 526.76 MiB/s bs =4194304, 501.09 MiB/s bs =8388608, 493.61 MiB/s bs = 16777216, 550.24 MiB/s bs = 33554432, 532.20 MiB/s bs = 67108864, 532.82 MiB/s So for Lustre, a buffer size bigger than the current 8 kB at least seems justified. While Lustre sees improvements all the way to 1 MB buffer size, such large buffers by default seems a bit excessive.
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #38 from Janne Blomqvist ---
First, I think there's a bug in the benchmark in comment #c20. It writes
blocksize * sizeof(double), but then advances only blocksize for each iteration
of the loop. Fixed version writing just bytes below:
#include
#include
#include
#include
#include
#include
#include
#include
double walltime (void)
{
struct timeval TV;
double elapsed;
gettimeofday(&TV, NULL);
elapsed = (double) TV.tv_sec + 1.0e-6*((double) TV.tv_usec);
return elapsed;
}
#define NAME "out.dat"
#define N 25000
int main()
{
int fd;
unsigned char *p, *w;
long i, size, blocksize, left, to_write;
int bits;
double t1, t2;
struct statvfs buf;
printf ("Test using %ld bytes\n", (long) N);
statvfs (".", &buf);
printf ("Block size of file system: %ld\n", buf.f_bsize);
p = malloc(N * sizeof (*p));
for (i=0; i 0)
{
if (left >= blocksize)
to_write = blocksize;
else
to_write = left;
write (fd, w, blocksize);
w += to_write;
left -= to_write;
}
close (fd);
t2 = walltime ();
printf ("%.2f MiB/s\n", N / (t2-t1) / 1048576);
}
free (p);
unlink (NAME);
return 0;
}
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #37 from Janne Blomqvist --- One thing we could do would be to switch to pread and pwrite instead of using lseek. That would avoid a few syscalls when updating the record length marker. Though I guess the issue with GPFS isn't directly related to the number of syscalls?
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #36 from Janne Blomqvist --- I have access to a system with Lustre, which is another parallel file system popular in HPC. Unfortunately I don't have gcc trunk setup there, but I can easily test the C benchmark; give me a day or two.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #50 from Janne Blomqvist --- Jakub, should your fix be backported to the gcc-7 branch as well, considering that the PR 87689 fix was applied to that branch as well?
[Bug other/91048] Recent changes to contrib/mklog cause failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91048 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #2 from Janne Blomqvist --- Thanks for the report. Fixed, closing.
[Bug other/91048] Recent changes to contrib/mklog cause failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91048 --- Comment #1 from Janne Blomqvist --- Author: jb Date: Tue Jul 2 05:54:31 2019 New Revision: 272921 URL: https://gcc.gnu.org/viewcvs?rev=272921&root=gcc&view=rev Log: mklog/91048: Open ~/.mklog in string mode. 2019-07-02 Janne Blomqvist PR other/91048 * mklog (read_user_info): Open ~/.mklog in string mode. Modified: trunk/contrib/ChangeLog trunk/contrib/mklog
[Bug fortran/65921] GFortran should use __builtin_mul_overflow when checking allocation sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65921 --- Comment #3 from Janne Blomqvist --- Author: jb Date: Thu Jun 20 20:26:39 2019 New Revision: 272520 URL: https://gcc.gnu.org/viewcvs?rev=272520&root=gcc&view=rev Log: libfortran/65921: Add forgotten PR number to ChangeLog 2019-06-14 Janne Blomqvist PR fortran/65921 * runtime/memory.c (SIZE_MAX):Remove macro definition. (xmallocarray): Use __builtin_mul_overflow. Modified: trunk/libgfortran/ChangeLog
[Bug fortran/65921] GFortran should use __builtin_mul_overflow when checking allocation sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65921 --- Comment #2 from Janne Blomqvist --- libgfortran/runtime/memory.c (xmallocarray) has been fixed for GCC 10, frontend part still todo.
[Bug fortran/89100] Default widths for i, f and g format specifiers in format strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100 --- Comment #12 from Janne Blomqvist --- Author: jb Date: Wed May 22 11:56:01 2019 New Revision: 271511 URL: https://gcc.gnu.org/viewcvs?rev=271511&root=gcc&view=rev Log: fortran/89100: Default widths with -fdec-format-defaults gcc/fortran ChangeLog: 2019-05-22 Jeff Law Mark Eggleston PR fortran/89100 * gfortran.texi: Add Default widths for F, G and I format descriptors to Extensions section. * invoke.texi: Add -fdec-format-defaults * io.c (check_format): Use default widths for i, f and g when flag_dec_format_defaults is enabled. * lang.opt: Add new option. * options.c (set_dec_flags): Add SET_BITFLAG for flag_dec_format_defaults. gcc/testsuite ChangeLog: 2019-05-22 Mark Eggleston PR fortran/89100 * gfortran.dg/fmt_f_default_field_width_1.f90: New test. * gfortran.dg/fmt_f_default_field_width_2.f90: New test. * gfortran.dg/fmt_f_default_field_width_3.f90: New test. * gfortran.dg/fmt_g_default_field_width_1.f90: New test. * gfortran.dg/fmt_g_default_field_width_2.f90: New test. * gfortran.dg/fmt_g_default_field_width_3.f90: New test. * gfortran.dg/fmt_i_default_field_width_1.f90: New test. * gfortran.dg/fmt_i_default_field_width_2.f90: New test. * gfortran.dg/fmt_i_default_field_width_3.f90: New test. libgfortran ChangeLog: 2019-05-22 Jeff Law PR fortran/89100 * io/format.c (parse_format_list): set default width when the IOPARM_DT_DEC_EXT flag is set for i, f and g. * io/io.h: add default_width_for_integer, default_width_for_float and default_precision_for_float. * io/write.c (write_boz): extra parameter giving length of data corresponding to the type's kind. (write_b): pass data length as extra parameter in calls to write_boz. (write_o): pass data length as extra parameter in calls to write_boz. (write_z): pass data length as extra parameter in calls to write_boz. (size_from_kind): also set size is default width is set. * io/write_float.def (build_float_string): new paramter inserted before result parameter. If default width use values passed instead of the values in fnode. (FORMAT_FLOAT): macro modified to check for default width and calls to build_float_string to pass in default width. (get_float_string): set width and precision to defaults when needed. Added: trunk/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_1.f90 trunk/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_2.f90 trunk/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90 trunk/gcc/testsuite/gfortran.dg/fmt_g_default_field_width_1.f90 trunk/gcc/testsuite/gfortran.dg/fmt_g_default_field_width_2.f90 trunk/gcc/testsuite/gfortran.dg/fmt_g_default_field_width_3.f90 trunk/gcc/testsuite/gfortran.dg/fmt_i_default_field_width_1.f90 trunk/gcc/testsuite/gfortran.dg/fmt_i_default_field_width_2.f90 trunk/gcc/testsuite/gfortran.dg/fmt_i_default_field_width_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/io.c trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/io.h trunk/libgfortran/io/read.c trunk/libgfortran/io/write.c trunk/libgfortran/io/write_float.def
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 --- Comment #13 from Janne Blomqvist --- Author: jb Date: Tue May 21 15:24:30 2019 New Revision: 271470 URL: https://gcc.gnu.org/viewcvs?rev=271470&root=gcc&view=rev Log: libfortran/90038: Document new wait=.false. implementation 2019-05-21 Janne Blomqvist PR libfortran/90038 * intrinsic.texi (EXECUTE_COMMAND_LINE): Explain new wait=.false. implementation. Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/intrinsic.texi
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 --- Comment #12 from Janne Blomqvist --- Author: jb Date: Tue May 21 15:17:44 2019 New Revision: 271468 URL: https://gcc.gnu.org/viewcvs?rev=271468&root=gcc&view=rev Log: libfortran/90038: Document new wait=.false. implementation 2019-05-21 Janne Blomqvist PR libfortran/90038 * intrinsic.texi (EXECUTE_COMMAND_LINE): Explain new wait=.false. implementation. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 --- Comment #11 from Janne Blomqvist --- Author: jb Date: Mon May 20 17:43:05 2019 New Revision: 271427 URL: https://gcc.gnu.org/viewcvs?rev=271427&root=gcc&view=rev Log: libfortran/90038 Use posix_spawn, reap dead children when wait=.false. Backport from trunk. When using posix_spawn or fork to launch a child process, the parent needs to wait for the child, otherwise the dead child is left as a zombie process. For this purpose one can install a signal handler for SIGCHLD. 2019-05-20 Janne Blomqvist PR libfortran/90038 * intrinsics/execute_command_line (sigchld_handler): New function. (execute_command_line): Install handler for SIGCHLD. * configure.ac: Check for presence of sigaction and waitpid. * config.h.in: Regenerated. * configure: Regenerated. fork() semantics can be problematic. Most unix style OS'es have posix_spawn which can be used to replace fork + exec in many cases. For more information see e.g. https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf This replaces the one use of fork in libgfortran with posix_spawn. 2019-05-20 Janne Blomqvist PR libfortran/90038 * configure.ac (AC_CHECK_FUNCS_ONCE): Check for posix_spawn. * intrinsics/execute_command_line (execute_command_line): Use posix_spawn. * Makefile.in: Regenerated. * config.h.in: Regenerated. * configure: Regenerated. Regtested on x86_64-pc-linux-gnu. Modified: branches/gcc-9-branch/libgfortran/ChangeLog branches/gcc-9-branch/libgfortran/Makefile.in branches/gcc-9-branch/libgfortran/config.h.in branches/gcc-9-branch/libgfortran/configure branches/gcc-9-branch/libgfortran/configure.ac branches/gcc-9-branch/libgfortran/intrinsics/execute_command_line.c
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 Janne Blomqvist changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Janne Blomqvist --- Fixed on trunk, closing.
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 --- Comment #9 from Janne Blomqvist --- Author: jb Date: Sun May 19 19:38:11 2019 New Revision: 271384 URL: https://gcc.gnu.org/viewcvs?rev=271384&root=gcc&view=rev Log: libfortran/90038 Reap dead children when wait=.false. When using posix_spawn or fork to launch a child process, the parent needs to wait for the child, otherwise the dead child is left as a zombie process. For this purpose one can install a signal handler for SIGCHLD. 2019-05-19 Janne Blomqvist PR libfortran/90038 * intrinsics/execute_command_line (sigchld_handler): New function. (execute_command_line): Install handler for SIGCHLD. * configure.ac: Check for presence of sigaction and waitpid. * config.h.in: Regenerated. * configure: Regenerated. Regtested on x86_64-pc-linux-gnu. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/execute_command_line.c
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 --- Comment #8 from Janne Blomqvist --- Actually, wasn't this simple as the above patch broke the synchronous version. Need to think more what to do.
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #7 from Janne Blomqvist ---
This should fix it:
--- a/libgfortran/intrinsics/execute_command_line.c
+++ b/libgfortran/intrinsics/execute_command_line.c
@@ -34,6 +34,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#endif
#ifdef HAVE_POSIX_SPAWN
#include
+#include
extern char **environ;
#endif
@@ -83,6 +84,9 @@ execute_command_line (const char *command, bool wait, int
*exitstat,
set_cmdstat (cmdstat, EXEC_NOERROR);
#ifdef HAVE_POSIX_SPAWN
+ /* As of POSIX.1-2001, setting SIGCHLD to SIG_IGN makes the
+kernel automatically reap zombies. */
+ signal (SIGCHLD, SIG_IGN);
const char * const argv[] = {"sh", "-c", cmd, NULL};
if (posix_spawn (&pid, "/bin/sh", NULL, NULL,
(char * const* restrict) argv, environ))
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 --- Comment #5 from Janne Blomqvist --- (In reply to kargl from comment #4) > What does 'it' refer to? fork() is leaving a zombie? > posix_spawn() is leaving a zombie? posix_spawn. Though I guess the old fork() code suffers from the same issue as well, though I don't think anything is using that anymore.
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038
--- Comment #3 from Janne Blomqvist ---
Further testing revealed that it leaves zombie processes around as the child is
never wait()'ed for. E.g.
program cmd
implicit none
call execute_command_line("echo hi", wait=.FALSE.)
call sleep(30)
end program cmd
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 --- Comment #2 from Janne Blomqvist --- Author: jb Date: Fri May 17 18:18:04 2019 New Revision: 271340 URL: https://gcc.gnu.org/viewcvs?rev=271340&root=gcc&view=rev Log: libfortran/90038: Use posix_spawn instead of fork fork() semantics can be problematic. Most unix style OS'es have posix_spawn which can be used to replace fork + exec in many cases. For more information see e.g. https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf This replaces the one use of fork in libgfortran with posix_spawn. 2019-05-17 Janne Blomqvist PR libfortran/90038 * configure.ac (AC_CHECK_FUNCS_ONCE): Check for posix_spawn. * intrinsics/execute_command_line (execute_command_line): Use posix_spawn. * Makefile.in: Regenerated. * config.h.in: Regenerated. * configure: Regenerated. Regtested on x86_64-pc-linux-gnu. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.in trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/execute_command_line.c
[Bug libfortran/90038] execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 Janne Blomqvist changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-05/msg00992.ht ||ml Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #1 from Janne Blomqvist --- Patch at https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00992.html
[Bug fortran/90504] New: Improved NORM2 algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90504 Bug ID: 90504 Summary: Improved NORM2 algorithm Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- Hanson, Hopkins, Remark on Algorithm 539: A Modern Fortran Reference Implementation for Carefully Computing the Euclidean Norm, https://dl.acm.org/citation.cfm?id=3134441 Above article tests different algorithms for NORM2 and tests performance and numerical accuracy.
[Bug fortran/90461] [F18] Allow opening same file on separate units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90461 Janne Blomqvist changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Janne Blomqvist --- Fixed on trunk, closing.
[Bug fortran/90461] [F18] Allow opening same file on separate units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90461 --- Comment #2 from Janne Blomqvist --- Author: jb Date: Wed May 15 18:02:36 2019 New Revision: 271260 URL: https://gcc.gnu.org/viewcvs?rev=271260&root=gcc&view=rev Log: Allow opening file on multiple units As of Fortran 2018 it's allowed to open the same file on multiple units. libgfortran/ChangeLog: 2019-05-15 Janne Blomqvist PR fortran/90461 * io/open.c (new_unit): Don't check if the file is already open for F2018. testsuite/ChangeLog: 2019-05-15 Janne Blomqvist PR fortran/90461 * gfortran.dg/open_errors_2.f90: Add -std=f2008, adjust line number. * gfortran.dg/open_errors_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/open_errors_3.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/open_errors_2.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/open.c
[Bug fortran/90461] New: [F18] Allow opening same file on separate units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90461 Bug ID: 90461 Summary: [F18] Allow opening same file on separate units Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- Fortran 2018 removes the restriction that a file can be opened only on one unit at a time.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #21 from Janne Blomqvist --- I filed https://github.com/Reference-LAPACK/lapack/issues/339 to start a discussion about fixing CBLAS and LAPACKE in upstream LAPACK.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #18 from Janne Blomqvist --- (In reply to Thomas Koenig from comment #15) > Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9, > I would suggest that we make -fno-optimize-sibling-calls > the default on these branches. Maintaining binary compatibility > (even if it is bug compatibility) with existing packages is > something we should strive for, especially with such > important software packages as BLAS and LAPACK. +1. Especially considering Steve's benchmark suggesting there's practically no difference, although there may of course be other code where sibling call optimization makes a difference. > For current trunk, I would recommend keeping the current > hehavior and contact the LAPACK maintainers to a) give them > a heads-up for this problem, and b) a year to work out > the problem. Yes. Closer to GCC 10, we can revisit this. I suspect we'll have to make -fno-optimize-sibling-calls the default for GCC 10 as well; while we might be able to help LAPACK maintainers fix LAPACKE there's in this timeframe there's certainly a lot of other code out there with custom C-Fortran interfaces which might be affected.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #12 from Janne Blomqvist ---
(In reply to Tomas Kalibera from comment #11)
> At least in the case I debugged, I think gfortran could do better by not
> writing the 1 as string length to the place on the stack where the compiler
> knows there is already 1 as string length.
The problem is not that the compiler gets the wrong string length, in this case
when the procedure argument is defined to have a length of 1, the compiler
never needs to access the hidden string length argument [1].
The problem is that both the caller and the callee need to agree on the number
(and type) of arguments. And because in Fortran implicit interfaces
("F77"-style interfaces, without modules, interface blocks or any other
newfangled "modern Fortran" stuff) the only information about the interface of
a procedure that the caller knows is the name of the procedure. So for an
example compiling the code
call foo("abc")
the compiler has no knowledge of the procedure beyond the name "foo". From this
code the compiler can then deduce that it must be a subroutine, and that it
takes one argument of type character. But the compiler cannot verify this, it
must assume the programmer knows what he's doing. Now, the problem is that the
definition of the procedure can be
subroutine foo(a)
character(len=1) :: a
end subroutine foo
or
subroutine foo(a)
character(len=3) :: a ! Or len=2
end subroutine foo
or
subroutine foo(a)
character(len=*) :: a
end subroutine foo
In the first two the hidden string length argument is not needed, but because
the procedure ABI must match for all the possibilities, and for the third case
the hidden length IS needed, the hidden string length argument is always
needed, although it's unused when the length is fixed.
[1] It would be possible to have some optional debugging option which inserts
code to verify that the actual argument length >= the dummy argument length.
But that's not really related to this issue.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #8 from Janne Blomqvist ---
(In reply to Janne Blomqvist from comment #3)
> 1) When compiling an external procedure, for character(len=1) arguments we
> don't generate the hidden string length argument. And similarly when calling
> an external procedure, if a len=1 character is passed, we omit the hidden
> string length argument. This, I believe, is what Paul is suggesting in the
> previous comment?
Having already shot down my (2) proposal, I thought a bit more about this one,
that is omitting the hidden length argument for dummy arguments with len=1, and
when calling a procedure with a len=1 argument.
Unfortunately, beyond being a somewhat fragile heuristic, it's also
fundamentally broken. Consider
subroutine foo(a)
character(len=1) :: a
...
end subroutine foo
So with this suggestion, this procedure would be generated without the hidden
length argument. The brokenness comes from
call foo("ab")
which would generate a call to a procedure WITH the hidden string length
argument. However, this code is perfectly standard conforming, F2018 15.5.2.4
says that a character dummy argument must have a length less than or equal to
the actual argument, which is fulfilled by the above (1 <= 2). That is, we
can't special case len=1 procedures and calls in any way.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #5 from Janne Blomqvist ---
(In reply to Thomas Koenig from comment #4)
> (In reply to Janne Blomqvist from comment #3)
> > 1) When compiling an external procedure, for character(len=1) arguments we
> > don't generate the hidden string length argument. And similarly when calling
> > an external procedure, if a len=1 character is passed, we omit the hidden
> > string length argument. This, I believe, is what Paul is suggesting in the
> > previous comment?
>
> Unfortunately, this would not work :-(
>
> While looking at the R source, I have also found some occurences
> where 'F' was spelled out 'Full'.
Ah, indeed.
> Also, what could be done with CALL FOO ('a', 'bcd') ?
My idea would be to not pass the hidden string length for the 'a' argument, but
pass it for the 'bcd' argument.
But as you mention above, there are indeed several ways in which his heuristic
can be broken.
I have a vague memory that other Fortran compilers have special-cased length-1
string arguments, though.
> > 2) External procedures with character arguments are compiled and called as
> > varargs functions. This is what Thomas is suggesting, except unconditionally
> > and not controlled by an option.
>
> Not an option, unfortunately :-(
>
> This would bring back PR 87689, and this was an ABI breakage on
> a primary GCC platform (POWER) with perfectly standard-compliant
> code.
Wasn't the problem here that the caller was using varargs, while the callee was
compiled as a normal function, thus causing the mismatch?
So my suggestion was that external procedures be compiled as varargs as well,
which would make the caller and callee ABI's to match.
But now that I think about it, it wouldn't help this LAPACK case, as here the C
side has a non-varargs prototype so the C caller will in any case not use the
varargs convention. And I've never seen any C code defining prototypes to
Fortran procedures as varargs either, so I guess this option is a non-starter.
Bluh.
> > I'm not really happy with either of these, but the third option, of fixing
> > all Fortran-calling code out there isn't realistic either.
>
> Currently, I am leaning towards using an option with a mandatory
> warning (no way to turn it off) which does not push any string lenghts
> onto the stack at all, something like -fbroken-character-abi,
> which we would use for external procedures without an explicit interface.
Hmm, wouldn't this completely break procedures with "character(len=*)" dummy
arguments? Or did mean that it would be used only for length=1 strings?
> I can also extend -fc-prototypes so that it also issues prototypes
> for any global procedures outside of BIND(C), or add a new option.
This might be useful.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #3 from Janne Blomqvist --- Ooof! (Just for the record, I don't think we should revert to the previous behavior. Whatever we do should be robust in the face of LTO etc.) I'd rather not see extra command-line arguments. For something which modifies the ABI and somehow works by accident part of the time, this is just too difficult to keep track of for end users, IMHO. My suggestions: 1) When compiling an external procedure, for character(len=1) arguments we don't generate the hidden string length argument. And similarly when calling an external procedure, if a len=1 character is passed, we omit the hidden string length argument. This, I believe, is what Paul is suggesting in the previous comment? 2) External procedures with character arguments are compiled and called as varargs functions. This is what Thomas is suggesting, except unconditionally and not controlled by an option. I'm not really happy with either of these, but the third option, of fixing all Fortran-calling code out there isn't realistic either.
[Bug fortran/90230] newunit in open function is not threadsafe with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90230 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jb at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Janne Blomqvist --- It's not a thread-safety issue. If you uncomment the line close(lun) you get the same error message also without OpenMP. The reason is that GFortran follows the Fortran standard which says that you may not open the same file on multiple units. That being said, Fortran 2018 removes that restriction, so future versions of GFortran may behave differently.
[Bug libfortran/90038] New: execute_command_line should not use fork()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038 Bug ID: 90038 Summary: execute_command_line should not use fork() Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- Occasionally there are problems like https://stackoverflow.com/questions/55120720/fortran-execute-command-line-runtime-error-depends-on-memory-consumption where execute_command_line (or system()) fails because the calling process uses a lot of memory. As of October 2018 glibc system() uses posix_spawn() instead of fork(), so this problem should largely solve itself over time on Linux/glibc targets. However, in execute_command_line there is still a usage of fork() remaining (in case WAIT=.FALSE.). This should be fixed. See also https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf
[Bug libfortran/52879] Pathological reseeding of PRNG generator genernates poor sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52879 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Janne Blomqvist --- I think the current implementation has a decent protection against bad seeds, so lets close this as fixed.
[Bug fortran/32770] [Meta-bug] -fdefault-integer-8 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770 Bug 32770 depends on bug 84509, which changed state. Bug 84509 Summary: STOP and ERROR STOP statements with -fdefault-integer-8 and large stop code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84509 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug fortran/84509] STOP and ERROR STOP statements with -fdefault-integer-8 and large stop code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84509 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Janne Blomqvist --- Closing this as WONTFIX, since GCC 8 has been released, and adding new ABI entry points just for this corner case isn't worth it. Or if somebody feels differently, please reopen and contribute a patch.
[Bug fortran/80408] Problems with SIGNAL, pthread and print together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80408 --- Comment #5 from Janne Blomqvist --- (In reply to Raphael Monod from comment #4) > Thank you for your answer. But I don't understand why adding -lpthread > option change the behavior if I do not use any thread. In libgfortran, if a thread library is not linked in, thread-related stuff such as mutexes are stubbed out in order to improve performance. With -lpthread it's thus more likely that the code deadlocks. Note that there's no guarantee it works without -lpthread either, it's just an accident. > Moreover, if I refer > to this page ( > https://docs.oracle.com/cd/E19455-01/806-5257/gen-26/index.html ) write > statement seems to be async-signal safe ? Where am I wrong ? > Finaly, what can I do if I want to print a message in my trap function ? > Thank you for your interest to my problem. That link refers to the POSIX write() function, which is a much lower level interface than the Fortran write statement. POSIX write() is async-signal-safe, but Fortran write has no such guarantees. As the things you can do in a signal handler is extremely limited, one way to handle it is to just set a flag variable, and then in the normal code you regularly check that flag variable, and print messages or whatever. Another way is the so-called self-pipe trick, where you create a pipe, and the signal handler can then write to the pipe. A thread in your program can then poll on the other end of the pipe. Handling pipes, and the need to use POSIX write/read rather than Fortran READ/WRITE probably means you'll have to implement that part of the program in C.
[Bug fortran/77908] Array operation fails for arrays with "long" indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77908 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #5 from Janne Blomqvist --- Confirmed on x86_64-apple-darwin16.7.0 with "8.2.0 (Homebrew GCC 8.2.0)". If I change bignumber to "huge(1_long) -1" the testcase works correctly. Unless someone has an idea how to generate the loop so the index doesn't wrap around while at the same time not regressing in performance, I'd say we close this as WONTFIX.
[Bug fortran/80408] Problems with SIGNAL, pthread and print together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80408 Janne Blomqvist changed: What|Removed |Added Status|WAITING |RESOLVED CC||jb at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Janne Blomqvist --- Indeed, this is invalid, as the GFortran I/O library is anything by async-signal-safe.
[Bug fortran/82480] KIND array returned by STAT too small for many values on CygWin platforms (and probably others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #3 from Janne Blomqvist --- Actually, libgfortran already has a version of stat with integer(kind=int64) arguments. If you compile with -fdefault-integer-8 you get that one, and the expected output. However, there seems to be no way of calling the int64 version without redefining the default integer kind. That should be fixable.
[Bug libfortran/89274] Inconsistent list directed output of INTEGER(16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89274 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #1 from Janne Blomqvist --- Seems obvious, Ok for trunk with a ChangeLog. Another point of view would be that for list-directed we should always use width=0 for all kinds; that would make list-directed more useful for things like print *, 'Frobnicator value is ', frob, ' frobs.' but would make it less useful for outputting tables.
[Bug fortran/81552] -finit-integer=n is restricted to 32-bit INTEGER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81552 Janne Blomqvist changed: What|Removed |Added Status|WAITING |RESOLVED CC||jb at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Janne Blomqvist --- Fixed on trunk, closing. The patch uses strtol() since that is in C89 and thus available everywhere. This close to the GCC 9 release I didn't want to risk breaking some targets I don't have a GCC development environment setup on. strtoll and int64_t are in C99 and with some GCC headers and libiberty they should be available everywhere, which would make this patch work on 32-bit and LLP64 (e.g. win64) targets. If anyone is interested in pursuing this I suggest reopening this bug report and submitting a patch when GCC is in stage 1.
[Bug fortran/81552] -finit-integer=n is restricted to 32-bit INTEGER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81552 --- Comment #5 from Janne Blomqvist --- Author: jb Date: Thu Feb 14 21:33:29 2019 New Revision: 268906 URL: https://gcc.gnu.org/viewcvs?rev=268906&root=gcc&view=rev Log: PR 81552 Improve and document -flag-init-integer Make the option handling code parse the -flag-init-integer value as a C long type, allowing a larger range on systems where long is a larger type than int. Document the behavior. Regtested on x86_64-pc-linux-gnu, committed as obvious. 2019-02-14 Janne Blomqvist PR fortran/81552 * gfortran.h (gfc_option_t): Make flag_init_integer_value a long. * options.c (gfc_handle_option): Use strtol instead of atoi. * invoke.texi: Document -finit-integer behavior in more detail Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/options.c
[Bug libfortran/88805] hidden symbol `__cpu_model' is referenced by DSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88805 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #3 from Janne Blomqvist --- (In reply to Andrew Pinski from comment #2) > >/usr/bin/ld: a.out: hidden symbol `__cpu_model' in > >/tmp/gcc9/bin/../lib/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc.a(cpuinfo.o) is > >referenced by DSO > > > Could you figure out which shared library references __cpu_model ? I doubt > it is one that GCC just built. > > I suspect it is libc which means your libc is broken. You will most likely > need a newer libc which does not reference __cpu_model any more. libgfortran/generated/matmul_*.c uses __cpu_model. As to why it does that instead of using the function multiversioning support, well, beats me.
[Bug c/88430] New: -Wmissing-attributes warnings when including libquadmath headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88430 Bug ID: 88430 Summary: -Wmissing-attributes warnings when including libquadmath headers Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- When building libgfortran trunk one nowadays (within the past month or two, maybe?) gets lots of warnings like below: In file included from ../../../../trunk/libgfortran/libgfortran.h:61, from ../../../../trunk/libgfortran/ieee/ieee_helper.c:26: ../../../../trunk/libgfortran/../libquadmath/quadmath_weak.h:36:33: warning: ‘__qmath_crealq’ specifies less restrictive attribute than its target ‘crealq’: ‘nothrow’ [-Wmissing-attributes] 36 | #define __qmath3(name) __qmath2(__qmath_ ## name,name,name) | ^~~~ ../../../../trunk/libgfortran/../libquadmath/quadmath_weak.h:28:25: note: in definition of macro ‘__qmath2’ 28 | static __typeof(type) name __attribute__ ((__weakref__(#name2))); | ^~~~ ../../../../trunk/libgfortran/../libquadmath/quadmath_weak.h:113:1: note: in expansion of macro ‘__qmath3’ 113 | __qmath3 (crealq) | ^~~~ According to 'git blame', there has been no recent changes to the quadmath header files recently, thus I suspect the implementation of -Wmissing-attributes is to blame. Though since libquadmath lives in-tree, a feasible solution would be to fix the quadmath headers, if the missing attribute warning otherwise works as intended? Please reassign to libquadmath if so. See thread starting at https://gcc.gnu.org/ml/fortran/2018-12/msg00055.html
[Bug fortran/88137] BACKTRACE seems to have a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88137 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Janne Blomqvist --- Fixed on trunk/8/7 branches, closing. The commit to the gcc-7 branch is a merge of the two separate commits to trunk.
[Bug fortran/88137] BACKTRACE seems to have a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88137 --- Comment #8 from Janne Blomqvist --- Author: jb Date: Thu Dec 6 15:38:25 2018 New Revision: 266858 URL: https://gcc.gnu.org/viewcvs?rev=266858&root=gcc&view=rev Log: Initialize backtrace state once 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, but use atomic load/store to access the static variable. Regtested on x86_64-pc-linux-gnu. libgfortran/ChangeLog: 2018-12-06 Janne Blomqvist Backport from trunk PR libfortran/88137 * runtime/backtrace.c (show_backtrace): Store backtrace state in a static variable, initialize once. Modified: branches/gcc-7-branch/libgfortran/ChangeLog branches/gcc-7-branch/libgfortran/runtime/backtrace.c
[Bug fortran/88137] BACKTRACE seems to have a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88137 --- Comment #7 from Janne Blomqvist --- Author: jb Date: Sun Dec 2 15:14:51 2018 New Revision: 266725 URL: https://gcc.gnu.org/viewcvs?rev=266725&root=gcc&view=rev Log: Use atomic load/store to access static backtrace state pointer As the static backtrace state pointer can be accessed from multiple threads, use atomics to access it. Regtested on x86_64-pc-linux-gnu. libgfortran/ChangeLog: 2018-12-02 Janne Blomqvist Backport from trunk PR libfortran/88137 * runtime/backtrace.c (show_backtrace): Use atomic load/store to access the static lbstate pointer. Modified: branches/gcc-8-branch/libgfortran/ChangeLog branches/gcc-8-branch/libgfortran/runtime/backtrace.c
