[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 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 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/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 --- 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/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 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] 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/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 --- 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 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 #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 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 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 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 --- 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 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 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/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 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 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/30162] [4.7/4.8 Regression] I/O with named pipes does not work on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #46 from Janne Blomqvist 2013-02-18 20:16:28 UTC --- (In reply to comment #44) > If unformatted sequential ever worked, it was by chance. > > Look at this piece of code: > > /* Seek to the head and overwrite the bogus length with the real > length. */ > > if (unlikely (sseek (dtp->u.p.current_unit->s, - m - 2 * record_marker, >SEEK_CUR) < 0)) > goto io_error; > > This works if it happens within a buffer, but you cannot rely on that. > > I would therefore suggest to resolve this PR by issuing a well-defined > error if we encounter a pipe on opening. > > I'll prepare a patch. As I explained in comment #23, this is already handled. When opening a file, we stat() the fd, and use the buffered I/O functions only if it's a regular file, otherwise the unbuffered raw I/O functions are used.
[Bug libfortran/30162] [4.7/4.8 Regression] Unformatted sequential I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #50 from Janne Blomqvist 2013-02-19 10:59:30 UTC --- (In reply to comment #47) > Am 18.02.2013 21:16, schrieb jb at gcc dot gnu.org: > >> Look at this piece of code: > >> > > >> > /* Seek to the head and overwrite the bogus length with the real > >> > length. */ > >> > > >> > if (unlikely (sseek (dtp->u.p.current_unit->s, - m - 2 * record_marker, > >> >SEEK_CUR) < 0)) > >> > goto io_error; > >> > > >> >This works if it happens within a buffer, but you cannot rely on that. > >> > > >> >I would therefore suggest to resolve this PR by issuing a well-defined > >> >error if we encounter a pipe on opening. > >> > > >> >I'll prepare a patch. > > As I explained in comment #23, this is already handled. When opening a > > file, we > > stat() the fd, and use the buffered I/O functions only if it's a regular > > file, > > otherwise the unbuffered raw I/O functions are used. > > This is part of the precipitate, not part of the solution ;-) > > For unformatted sequential, we first write a dummy record marker, write > the data and the final record marker, then seek to the first marker > and re-write that. Of course, this fails for an unbuffered fifo. > > If we want this to work, we should make sure we always use > _buffered_ I/O for unformatted sequential, setting a maximum > record length on open that we can handle with our buffer. The buffered I/O functions generally assume that the underlying fd is a regular file; if you break that be prepared to handle a bunch of subtle fallout. I tried playing that whack-a-mole game a few years ago until I got tired of it and restricted buffered I/O to regular files. Wrt to pipes, one regression we had (I don't remember the PR number) was a deadlock due to the buffering. E.g. one process writes "hello" to the pipe, the other one answers "hello, neighbor". The write part could be handled by executing the FLUSH statement, but I recall there was some problem on the read side as well, something to do with read() hanging due to there not being any data available in the pipe when it tried to fill the buffer. Anyway, I don't think this is something libgfortran can, or should, try to fix. If the user tries to do something requiring seeking on a special file that doesn't support seeking, they get what they deserve. The real bug here is that we try to seek even though the Fortran semantics don't require it (mind that the complaint in comment #22 which reopened this PR refers to formatted I/O).
[Bug libfortran/30162] [4.7/4.8 Regression] Unformatted sequential I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #51 from Janne Blomqvist 2013-02-19 22:48:50 UTC --- (In reply to comment #22) > Revision 180701 removed all checks for special files in > unit.c:unit_truncate(). > As a consequence programs compiled with gfortran 4.6.3 and newer cannot to > write (formatted) to Unix named pipes as ftruncate() fails with EINVAL: > > (64-bit code) > > lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) > write(3, " Hello, world!\n", 15)= 15 > lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) > ftruncate(3, 18446744073709551615) = -1 EINVAL (Invalid argument) > > (32-bit code) > > _llseek(3, 0, 0xffba8fa0, SEEK_CUR) = -1 ESPIPE (Illegal seek) > write(3, " Hello, world!\n", 15)= 15 > _llseek(3, 0, 0xffba9080, SEEK_CUR) = -1 ESPIPE (Illegal seek) > ftruncate64(3, 18446744073709551615)= -1 EINVAL (Invalid argument) This bug (http://stackoverflow.com/questions/11780556/write-to-fifo-named-pipe , presumably) should be fixed by the patch at http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00923.html
[Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379 --- Comment #11 from Janne Blomqvist 2013-02-20 21:20:44 UTC --- Looking at the frontend, calls to runtime_error_at are generated from gfc_trans_runtime_check() and gfc_trans_runtime_error(). I went through calls to these functions, and IMHO they all look like serious errors worthy of a backtrace, with the exception of ALLOCATE/DEALLOCATE failures when STAT= is not specified. In that case F2008 specifies that the processor must proceed with error termination, and printing a backtrace for this case would be a bit inconsistent with other cases of error termination.
[Bug libfortran/30162] [4.7/4.8 Regression] Unformatted sequential I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #52 from Janne Blomqvist 2013-02-21 19:03:19 UTC --- Author: jb Date: Thu Feb 21 19:03:10 2013 New Revision: 196210 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196210 Log: Fix regression when writing formatted sequential to a pipe. 2013-02-21 Janne Blomqvist PR libfortran/30162 * io/open.c (test_endfile): Call stell only if size != 0. * io/unix.c (raw_tell): Revert r194679. (raw_size): Return size field only for regular files, otherwise 0. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/open.c trunk/libgfortran/io/unix.c
[Bug libfortran/30162] [4.7/4.8 Regression] Unformatted sequential I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #53 from Janne Blomqvist 2013-02-21 20:13:12 UTC --- Author: jb Date: Thu Feb 21 20:13:04 2013 New Revision: 196212 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196212 Log: Fix regression when writing formatted sequential to a pipe. 2013-02-21 Janne Blomqvist PR libfortran/30162 * io/open.c (test_endfile): Call stell only if size != 0. * io/unix.c (raw_tell): Revert r194694. (raw_size): Return size field only for regular files, otherwise 0. Modified: branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/io/open.c branches/gcc-4_7-branch/libgfortran/io/unix.c
[Bug libfortran/30162] [4.7/4.8 Regression] Unformatted sequential I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #54 from Janne Blomqvist 2013-02-21 20:39:58 UTC --- I'd suggest to close the unformatted sequential part of this PR as WONTFIX. Maybe it worked sometime in the past for small record sizes when buffered IO was used for pipes, but that was by accident not by design. I think re-enabling buffering for pipes would open up a can of worms for very little benefit. A way to "properly" enable this would be to rework the IO library so that we know how much we're writing before writing the initial record marker (so that we don't need to seek back and fill in the correct value later), however that implies a rather major rework of how we do IO, so IMHO the benefit is not worth it.
[Bug fortran/40958] module files too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 Janne Blomqvist changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-04/msg00554.htm ||l CC||jb at gcc dot gnu.org --- Comment #8 from Janne Blomqvist 2013-04-09 18:35:46 UTC --- Patch for compressing module files with zlib at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00554.html .
[Bug fortran/56919] [4.6/4.7/4.8/4.9 Regression] Wrong result for SYSTEM_CLOCK on Cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919 --- Comment #2 from Janne Blomqvist 2013-04-11 18:32:19 UTC --- (In reply to comment #0) > The problem is that Cygwin does not support CLOCK_MONOTONIC; using it will > return always return 0. > > Note that Cygwin not only defines CLOCK_MONOTONIC but since Cygwin-1.7.6 also > "_POSIX_MONOTONIC_CLOCK 200112L" [1]. Thus, _POSIX_MONOTONIC_CLOCK [2] can > also > not be used. Aagh, one wonders what demented logic caused them to claim they support it and then not actually do so in any kind of useful manner.. *sigh* > Nick suggests to simply call gf_gettime unconditionally. [3] I wonder what, if any, specific issues there actually are.. Anyways, clock_gettime works fine on Linux, and IMHO it would be an annoying regression to replace the current high-resolution monotonic clock with a lower resolution non-monotonic clock, particularly since with recent glibc it should be available to all users and not only those who link in librt (e.g. implicitly via -fopenmp). I don't know how cygwin implements CLOCK_MONOTONIC, but anyway, AFAIK on windows a robust monotonic clock is available via the GetTickCount (and on Vista/2008 and up, GetTickCount64 as well) function. Thus I'd suggest that both MINGW and CYGWIN version should use those functions in the implementation of the SYSTEM_CLOCK intrinsic. An overview of various timing functions can be found e.g. at http://www.python.org/dev/peps/pep-0418/ > [3] http://gcc.gnu.org/ml/fortran/2013-04/msg00086.html
[Bug fortran/56919] [4.7/4.8/4.9 Regression] Wrong result for SYSTEM_CLOCK on Cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919 Janne Blomqvist changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-04/msg00835.htm ||l --- Comment #5 from Janne Blomqvist 2013-04-12 18:49:24 UTC --- Patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00835.html
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 --- Comment #4 from Janne Blomqvist 2013-04-17 10:50:07 UTC --- The reason why gfortran is slow here is that for non-regular files we use unbuffered I/O. If you write to a regular file instead of /dev/null, you'll see us doing ~8 KB writes at a time. On my system, timing writing to /dev/null gives real0m0.727s user0m0.272s sys 0m0.452s whereas writing to a file gives real0m0.202s user0m0.180s sys 0m0.020s The reason for this is that non-regular files (a.k.a. special files) are special in many ways wrt seeking. Some allow seeking just fine, some always return 0, some return an error (and which special files behave in which way is to some extent different on different OS'es). As the buffered IO keeps track of the logical file pointer position, it can easily get out of sync with the physical position if it doesn't behave as for a regular file. Also, for special files users often expect non-buffered IO, e.g. they want output on the terminal directly instead of waiting until the 8 KB buffer fills up, programs communicating via pipes can deadlock if data sits in the buffers, etc. One could of course make "unbuffered" I/O in gfortran really mean "flush the buffer at the end of each I/O statement" rather than not using a buffer at all and instead using the raw POSIX I/O syscalls. This would perhaps not be a bad idea per se, but would require making the buffered I/O code handle special files in some sensible way. Another reason for gfortran slowness is that we do quite a lot of checking in data_transfer_init(), which means that there's quite a lot of per-record overhead. Writing a single element unformatted is thus the worst case. One way to speed up data_transfer_init, I think, is that instead of checking each flag bit (which says which I/O specifiers are present) separately, create a variable with forbidden flags for each I/O type (unformatted/formatted, sequential/direct/stream => 6x), and check the entire flag variable once (flag & forbidden_flags == 0). Only if there is an error, do the bit-by-bit checking in order to generate the error message.
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 Janne Blomqvist changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-04/msg01127.htm ||l --- Comment #7 from Janne Blomqvist 2013-04-19 10:34:20 UTC --- Patch implementing the "unbuffered really means buffered but flush after every write" idea: http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01127.html
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 Janne Blomqvist changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | --- Comment #2 from Janne Blomqvist 2013-04-24 15:28:52 UTC --- Thanks for notifying, this is certainly due to my patch to compress fortran module files. However, I'm a bit lost. I thought zlib was needed in any case as java and lto already use it. Furthermore, we have a copy of zlib in-tree already, shouldn't that be used unless --with-system-zlib is specified to configure (in which the user assumes responsibility for providing zkib.h)? Any ideas?
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 Janne Blomqvist changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-04/msg01464.htm ||l --- Comment #4 from Janne Blomqvist 2013-04-24 20:03:17 UTC --- Patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01464.html .
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 Janne Blomqvist changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2013-04/msg01464.htm |atches/2013-04/msg01517.htm |l |l --- Comment #6 from Janne Blomqvist 2013-04-25 11:04:42 UTC --- Updated patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01517.html
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 --- Comment #8 from Janne Blomqvist 2013-04-25 19:19:05 UTC --- Author: jb Date: Thu Apr 25 19:16:46 2013 New Revision: 198318 URL: http://gcc.gnu.org/viewcvs?rev=198318&root=gcc&view=rev Log: PR 57028 Bootstrap regression wrt zlib. 2013-04-25 Janne Blomqvist PR bootstrap/57028 * Make-lang.in (f951): Link in ZLIB. (CFLAGS-fortran/module.o): Add zlib include directory. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/Make-lang.in
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 --- Comment #9 from Janne Blomqvist 2013-04-25 19:19:59 UTC --- (In reply to comment #7) > (In reply to comment #6) > > Updated patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01517.html > > This one works. Thanks. Thanks for the confirmation. Committed as obvious.
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #10 from Janne Blomqvist 2013-04-25 19:20:40 UTC --- Ugh, sorry for the email spam, closing for real this time..
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #2 from Janne Blomqvist 2012-09-16 08:33:42 UTC --- (In reply to comment #1) > You need unwind frames present for this to work, i.e. the space (and to some > extent optimization-reducing - yes I'm sure) overhead of -funwind-tables. > (Only > x86_64 has this on, effectively.) How is this different from the current backtracing implementation in libgfortran? (That being said, we should probably modify the driver program to always add -funwind-tables, which IIRC isn't done today)
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #27 from Janne Blomqvist 2012-11-10 20:21:41 UTC --- (In reply to comment #26) > Is this caused by > > http://gcc.gnu.org/viewcvs?view=revision&revision=180701 > > ? > > Maybe we need to remember if we have a special file after all, or just ignore > the error on the truncate. IMHO the correct fix is to not seek and/or truncate the file unless the Fortran semantics require it; that way libgfortran does not need to care whether the file is special or not. As explained in #c23, special files are special in different ways (also different on different OS'es), and trying to enumerate all the ways in which they are special is bound to fail. I think Tobias comment #c24 pinpoints the place which needs to be fixed, but unfortunately I haven't had time to look into it.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #13 from Janne Blomqvist 2010-12-20 08:48:18 UTC --- Also vaguely related: PR 36857 I don't think it's a good idea to call setlocale() in the library - I suspect this would (subtly?) break a lot of programs that set the locale and then at some later point call a Fortran library function.
[Bug libfortran/47154] [4.6 Regression] END= does not work in namelist read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47154 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #5 from Janne Blomqvist 2011-01-04 14:53:40 UTC --- Ok for trunk. Thanks for the patch. Per se, I suspect the problem was not multiple calls to generate_error(), as generate_error has some logic to return early in case an error has already been recorded. Rather I think the culprit is multiple calls to hit_eof(), I've been bitten by this myself. The first call tells us that we've hit EOF, and we're at the endfile record. The second one moves the position to after the endfile record, which is another type of error. Unfortunately I don't have any good idea how to solve this.
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296 Janne Blomqvist changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #5 from Janne Blomqvist 2011-01-15 09:18:18 UTC --- Nice catch. Looking at the code, when creating a SCRATCH file fails, unix.c:tempfile() returns -1, then as a result open_external() returns NULL, but then in open.c:new_unit() even though we have checked that open_external() returns NULL, we still call unpack_filename(), as well as accessing opp->file_len. Just to be sure, I suspect it would be prudent to set opp->file to NULL and opp->file_len to 0 in tempfile() in case fd < 0. Or are we sure that the entire opp struct is set to 0 sometime before?
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296 --- Comment #8 from Janne Blomqvist 2011-01-15 19:31:17 UTC --- I suppose one thing that could be done is to set opp->file and opp->file_len regardless of whether mkstemp() succeeds or not, that is lines 1987:1093 in unix.c, and then in open.c:new_unit() one can free opp->file after generating a suitable error message. Even if the file name is automatically generated, maybe it would be helpful to provide the user with info exactly what failed, e.g. so that the user knows what failed was opening a file under /tmp which might otherwise not be obvious to the user.
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296 --- Comment #10 from Janne Blomqvist 2011-01-16 20:12:55 UTC --- Well, I was thinking more something like the patch I just posted at http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01086.html
[Bug libfortran/46267] strerror() is not necessarily thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46267 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.20 14:44:26 Ever Confirmed|0 |1 --- Comment #5 from Janne Blomqvist 2011-01-20 14:44:26 UTC --- Assigning to myself.
[Bug libfortran/46267] strerror() is not necessarily thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46267 Janne Blomqvist changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg01400.htm ||l --- Comment #6 from Janne Blomqvist 2011-01-20 18:14:17 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01400.html
[Bug libfortran/47375] GETLOG not threadsafe, causes warnings/wrong-code with static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47375 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.21 13:44:37 CC||jb at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #5 from Janne Blomqvist 2011-01-21 13:44:37 UTC --- Assigning to myself. The linking issues is probably not solvable, but at least we should use the _r() functions if available.
[Bug libfortran/46267] strerror() is not necessarily thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46267 Janne Blomqvist changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2011-01/msg01400.htm |atches/2011-01/msg01486.htm |l |l AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | --- Comment #7 from Janne Blomqvist 2011-01-21 17:26:08 UTC --- Updated patch: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01486.html
[Bug libfortran/46267] strerror() is not necessarily thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46267 --- Comment #8 from Janne Blomqvist 2011-01-21 22:42:26 UTC --- Author: jb Date: Fri Jan 21 22:42:17 2011 New Revision: 169110 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169110 Log: PR 46267 strerror thread safety Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/gerror.c trunk/libgfortran/io/unix.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c
[Bug libfortran/46267] strerror() is not necessarily thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46267 Janne Blomqvist changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Janne Blomqvist 2011-01-22 18:59:41 UTC --- Fixed, closing
[Bug libfortran/47431] New: ctime() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47431 Summary: ctime() not thread-safe Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org In libgfortran/intrinsics/ctime.c we call the POSIX ctime() function, which need not be thread safe. Instead, we should use ctime_r() if available.
[Bug libfortran/47431] ctime() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47431 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.24 09:55:30 AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug libfortran/47432] New: ttyname() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47432 Summary: ttyname() not thread-safe Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org In libgfortran/io/unix.c we call the POSIX ttyname() function, which need not be thread-safe. Instead we should call ttyname_r(), if available.
[Bug libfortran/47432] ttyname() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47432 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.24 09:57:38 AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug fortran/47439] Fun with scratch files on Windows MKTEMP only allows for 26 files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47439 --- Comment #1 from Janne Blomqvist 2011-01-25 09:28:14 UTC --- Seems the reason for Windows _mktemp() behavior is due to replicating some age-old BSD behavior. From the Linux mktemp(3) manpage: BUGS Never use mktemp(). Some implementations follow 4.3BSD and replace XX by the current process ID and a single letter, so that at most 26 different names can be returned. Since on the one hand the names are easy to guess, and on the other hand there is a race between testing whether the name exists and opening the file, every use of mktemp() is a security risk. The race is avoided by mkstemp(3). (Needless to say, libgfortran use mkstemp() ifavailable, mktemp() is just a fallback.)
[Bug fortran/25071] dummy argument larger than actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071 Janne Blomqvist changed: What|Removed |Added Status|RESOLVED|REOPENED CC||jb at gcc dot gnu.org Resolution|FIXED | --- Comment #7 from Janne Blomqvist 2011-01-25 12:01:17 UTC --- Reopening.. (In reply to comment #6) > I believe this is fixed by PR30940. > > The first example gives: > Warnung: Actual argument contains too few elements for dummy argument 'i' > (4/6) > at (1) > > The second example: > Warnung: Character length of actual argument shorter than of dummy argument > 'y' > (10/20) at (1) > > It currently gives only warnings since I failed to get any comments when an > error and when only a warning should be given. Sorry for being 'a bit' late with comments, but IMHO this should be an error and not just a warning, because 1) The standard says so 2) Other compilers reject it (so we can't argue that we must support this common extension) 3) Not rejecting it makes it really easy to corrupt memory. Consider program x character(len=10) :: a, b, c a = "1234567890" b = a c = a call xx2(b) print *, '::', a, '::', b, '::', c, '::' contains subroutine xx2(name) character(len=20), intent(inout) :: name name = 'hi' end subroutine xx2 end program This prints (gfortran 4.4, x86_64 Linux): $ ./chardummy2 ::567890::hi::1234567890:: That is, blanking out the remaining 18 characters at the end of the character b passed to xx2 overwrites part of the character a (why are only 4 characters overwritten and not all 10? because they are allocated 4/8/16? byte aligned on the stack). Note that neither bounds checking nor valgrind detects this error. > > Missing is the check for array element designators: PR32616. I haven't looked, but maybe PR30940 and PR32616 would need to be fixed as well?
[Bug libfortran/47375] GETLOG not threadsafe, causes warnings/wrong-code with static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47375 --- Comment #6 from Janne Blomqvist 2011-01-25 16:46:07 UTC --- Author: jb Date: Tue Jan 25 16:46:00 2011 New Revision: 169243 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169243 Log: PR 47375 getlog thread safety Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/getlog.c
[Bug fortran/47491] [4.6 Regression] libgfortran: getpwuid_r (for GETLOG) breaks bootstrapping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47491 --- Comment #2 from Janne Blomqvist 2011-01-27 16:10:41 UTC --- Some git-grepping showed that at least libjava has in configure.ac AC_DEFINE(_POSIX_PTHREAD_SEMANTICS, 1, [Required define if using POSIX threads]) and in case Boehm GC is not used (which libgfortran never uses): AC_DEFINE(_REENTRANT, 1, [Required define if using POSIX threads]) However, if I understand gcc/config/ correctly, _REENTRANT should be automatically set for all targets that need it. Also in gcc/config a few targets set -D_POSIX_C_SOURCE=199506L (not Solaris, though). But apparently we shouldn't go and set this somewhere in libgfortran? That is, at least no other library does this.. Moreover, in config/extensions.m4 there is the macro AC_USE_SYSTEM_EXTENSIONS that seems to define _POSIX_PTHREAD_SEMANTICS on Solaris. This seems to me the most sensible solution. Would that work?
[Bug fortran/47491] [4.6 Regression] libgfortran: getpwuid_r (for GETLOG) breaks bootstrapping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47491 Janne Blomqvist changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg02026.htm ||l --- Comment #4 from Janne Blomqvist 2011-01-27 17:10:42 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02026.html (In reply to comment #3) > > --- Comment #2 from Janne Blomqvist 2011-01-27 > > 16:10:41 UTC --- > > Some git-grepping showed that at least libjava has in configure.ac > > > > AC_DEFINE(_POSIX_PTHREAD_SEMANTICS, 1, [Required define if using POSIX > > threads]) > > > > and in case Boehm GC is not used (which libgfortran never uses): > > > > AC_DEFINE(_REENTRANT, 1, [Required define if using POSIX threads]) > > > > However, if I understand gcc/config/ correctly, _REENTRANT should be > > automatically set for all targets that need it. > > At least on Solaris (and I think on other targets as well), only with > -pthread. I think that's Ok. If we're not building with threads, and lack of _REENTRANT causes the _r() functions not to be seen, gfortran falls back to the non-_r() functions, which is no problem on a non-threaded build. > > Also in gcc/config a few targets set > > > > -D_POSIX_C_SOURCE=199506L > > > > (not Solaris, though). But apparently we shouldn't go and set this > > somewhere in > > libgfortran? That is, at least no other library does this.. > > That may not provide the best guidance. I'd rather look for autoconf > and/or gnulib here. On Solaris, this may not be enough: starting with > Solaris 10, there's POSIX.1-2001 support via -D_POSIX_C_SOURCE=200112L. The comments at http://blogs.gnome.org/tthurman/2008/11/23/_posix_c_source/ suggests defining POSIX_C_SOURCE might not be such a good idea, so I think it's best to avoid this. Also, for GNU platforms http://www.gnu.org/s/libc/manual/html_node/Feature-Test-Macros.html seems _GNU_SOURCE is sort of a superset of POSIX_C_SOURCE and the kitchen sink. Which is what we're using today, hopefully the AC_USE_SYSTEM_EXTENSIONS thing is enough to make things work on other targets.
[Bug fortran/47491] [4.6 Regression] libgfortran: getpwuid_r (for GETLOG) breaks bootstrapping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47491 --- Comment #5 from Janne Blomqvist 2011-01-27 17:34:18 UTC --- Author: jb Date: Thu Jan 27 17:34:14 2011 New Revision: 169334 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169334 Log: PR 47491 getpwuid_r() bootstrap regression on Solaris Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac
[Bug fortran/47491] [4.6 Regression] libgfortran: getpwuid_r (for GETLOG) breaks bootstrapping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47491 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | --- Comment #6 from Janne Blomqvist 2011-01-27 19:42:58 UTC --- Fixed, closing. Please reopen if it still doesn't work on Solaris.
[Bug libfortran/47375] GETLOG not threadsafe, causes warnings/wrong-code with static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47375 Janne Blomqvist changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Janne Blomqvist 2011-01-27 19:43:53 UTC --- Fixed, closing.
[Bug libfortran/47432] ttyname() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47432 --- Comment #4 from Janne Blomqvist 2011-01-27 20:05:49 UTC --- Author: jb Date: Thu Jan 27 20:05:45 2011 New Revision: 169337 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169337 Log: PR 47432 Use ttyname_r() if available Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/io/inquire.c trunk/libgfortran/io/intrinsics.c trunk/libgfortran/io/unix.c trunk/libgfortran/io/unix.h
[Bug libfortran/47432] ttyname() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47432 --- Comment #5 from Janne Blomqvist 2011-01-27 20:08:44 UTC --- Fixed, closing.
[Bug libfortran/47432] ttyname() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47432 Janne Blomqvist changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Janne Blomqvist 2011-01-27 20:09:27 UTC --- Really closing.
[Bug libfortran/47431] ctime() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47431 --- Comment #3 from Janne Blomqvist 2011-01-27 20:22:46 UTC --- Author: jb Date: Thu Jan 27 20:22:37 2011 New Revision: 169338 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169338 Log: Pr 47431 CTIME/FDATE thread-safety using ctime_r() Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/ctime.c
[Bug libfortran/47431] ctime() not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47431 Janne Blomqvist changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Janne Blomqvist 2011-01-27 20:25:42 UTC --- Fixed, closing.
[Bug fortran/47552] CTIME: Valgrind warning "depends on uninitialised value"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47552 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.31 12:57:07 Ever Confirmed|0 |1 --- Comment #1 from Janne Blomqvist 2011-01-31 12:57:07 UTC --- FWIW, I see the same problem with gfortran 4.4 @work, so probably not something due to my recent ctime_r() patch.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #2 from Janne Blomqvist 2011-02-01 15:08:13 UTC --- On Linux/Glibc libgfortran is built with _GNU_SOURCE, which according to the glibc manual is a superset of all kinds of _POSIX_C_SOURCE=[latest_supported_standard] XOPEN_SOURCE=[latest_supported_standard] and so forth. My guess is that the issue is due to mismatch between the build environment and the environment where gfortran is executed. It might be that the OP is running on some old distro that doesn't provide librt.so which is needed by clock_gettime() on Glibc. OP, what does "ldd /path/to/libgfortran.so.3" say? FWIW, I have no idea what "Patch 81226" refers to.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #6 from Janne Blomqvist 2011-02-01 15:50:52 UTC --- (In reply to comment #3) > clock_gettime is defined in librt, so if libgfortran started using librt > symbols, it needs to a) link against it dynamically for libgfortran.so Yes, that's what it does, using a configure.ac snippet lifted from libgomp. On my system, ldd libgfortran.so shows: linux-vdso.so.1 => (0x7fff71ae9000) libquadmath.so.0 => /home/janne/src/gfortran/trunk/install/lib/../lib64/libquadmath.so.0 (0x7f885a485000) libm.so.6 => /lib/libm.so.6 (0x7f885a1df000) librt.so.1 => /lib/librt.so.1 (0x7f8859fd7000) libc.so.6 => /lib/libc.so.6 (0x7f8859c54000) libpthread.so.0 => /lib/libpthread.so.0 (0x7f8859a36000) /lib64/ld-linux-x86-64.so.2 (0x7f885a9cf000) where the librt and libpthread dependencies are due to using clock_gettime() from librt. > b) > arrange for gfortran driver to pass in -lrt when linking libgfortran > statically. Right, I haven't considered this part. Anyone have any idea how that could be done?
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Janne Blomqvist changed: What|Removed |Added Target|i686-pc-linux-gnu | Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.01 16:02:50 Host|i686-pc-linux-gnu | AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Build|i686-pc-linux-gnu | --- Comment #7 from Janne Blomqvist 2011-02-01 16:02:50 UTC --- So using -static I was able to reproduce this bug on x86_64-unknown-linux-gnu. As Jakub mentioned, the driver must link in librt when linking statically. I'll look into how this could be done. As a workaround for the reporter, dynamic linking works fine.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #11 from Janne Blomqvist 2011-02-01
16:20:06 UTC ---
(In reply to comment #8)
> (In reply to comment #6)
> > > clock_gettime is defined in librt, so if libgfortran started using librt
> > > symbols, it needs to a) link against it dynamically for libgfortran.so
> >
> > Yes, that's what it does
>
> But why doesn't it work then, cf. comment 4? openSUSE 11.3 is neither old nor
> very special.
Because the original report links statically (as can be deduced from the
presence of libgfortran.a). As I mentioned, static linking is broken but
dynamic works. FWIW, I suspect the output of ldd in comment #4 refers to the
system provided libgfortran, as neither librt nor libquadmath is present.
>
> > > b)
> > > arrange for gfortran driver to pass in -lrt when linking libgfortran
> > > statically.
> > Right, I haven't considered this part. Anyone have any idea how that could
> > be
> > done?
>
> Via libgfortran/libgfortran.spec.in and some configure script?
>
> Cf. libgomp and libgomp/configure.ac's
>
> # Set up the set of libraries that we need to link against for libgomp.
> # Note that the GOMP_SELF_SPEC in gcc.c will force -pthread for -fopenmp,
> # which will force linkage against -lpthread (or equivalent for the system).
> # That's not 100% ideal, but about the best we can do easily.
> if test $enable_shared = yes; then
> link_gomp="-lgomp %{static: $LIBS}"
> else
> link_gomp="-lgomp $LIBS"
> fi
> AC_SUBST(link_gomp)
>
>
> By the way, there is also -lrt added via libgomp/configure.tgt for HPUX.
Thanks, I'll have to take a look at this later tonight.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #13 from Janne Blomqvist 2011-02-01 20:02:38 UTC --- (In reply to comment #9) > How many fortran users actually need to more precise DATE_AND_TIME though? None, since the DATE_AND_TIME API is limited to millisecond precision. The motivation for using clock_gettime() is the SYSTEM_CLOCK intrinsic, whose purpose is precise measurement of wall clock intervals. In this case, the SYSTEM_CLOCK API allows us to expose the extra precision to user code, and perhaps more importantly, we use CLOCK_MONOTONIC which is better suited for this purpose than CLOCK_REALTIME. The reason why DATE_AND_TIME now also uses clock_gettime() is that part of the patch was some cleanup centralizing #ifdefs under a single gf_gettime() function rather than sprinkling them around the code. > Bringing in -lpthread (as dependency of -lrt) certainly has some extra > overhead, e.g. everything that uses gthr* will suddenly use real locking. > You could e.g. use clock_gettime only through a weakref, thus let the users > choose if clock_gettime should be used or not. If they don't link in librt, > less precise implementation would be used, if they do link it in, it would > become more precise (-lrt would be linked in automatically e.g. for -fopenmp > compilations). The above being said, this sounds like a good idea. I'll look into this rather than trying to link librt statically. (FWIW I don't think the extra locking overhead would matter in practice, as libgfortran uses quite coarse grained locking, and AFAIK uncontested futexes are very fast)
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Janne Blomqvist changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-02/msg00075.htm ||l --- Comment #14 from Janne Blomqvist 2011-02-01 21:14:18 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00075.html I'm a bit unsure about the whole weakref stuff, but this seems to work for me on x86_64-unknown-linux-gnu.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #15 from Janne Blomqvist 2011-02-02 08:48:27 UTC --- Author: jb Date: Wed Feb 2 08:48:24 2011 New Revision: 169517 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169517 Log: PR 47571 Weakref trickery for clock_gettime() Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/time_1.h
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #18 from Janne Blomqvist 2011-02-03
09:53:50 UTC ---
To add to Tobias comment, in the patch the only place where a weakref is used
is
+#ifdef SUPPORTS_WEAK
+static int weak_gettime (clockid_t, struct timespec *)
+ __attribute__((__weakref__("clock_gettime")));
+#else
+static inline int weak_gettime (clockid_t clk_id, struct timespec *res)
+{
+ return clock_gettime (clk_id, res);
+}
+#endif
That is, for some reason SUPPORTS_WEAK must be defined on HPUX even though weak
references are not actually supported. Why is this?
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Janne Blomqvist changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2011-02/msg00075.htm |atches/2011-02/msg00196.htm |l |l --- Comment #19 from Janne Blomqvist 2011-02-03 12:47:59 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00196.html This is my previous janitorial patch, + a kludge which I believe should fix the issue on HP-UX and other targets that support weak references but not weak undefined references.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #22 from Janne Blomqvist 2011-02-05 16:22:09 UTC --- Author: jb Date: Sat Feb 5 16:22:04 2011 New Revision: 169852 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169852 Log: PR 47571 Fix HPUX bootstrap regression, cleanup Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/date_and_time.c trunk/libgfortran/intrinsics/system_clock.c trunk/libgfortran/intrinsics/time_1.h
[Bug fortran/42434] Documentation should provide advice about clock resolutions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42434 Janne Blomqvist changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-02/msg00331.htm ||l AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | --- Comment #1 from Janne Blomqvist 2011-02-05 20:06:48 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00331.html
[Bug fortran/42434] Documentation should provide advice about clock resolutions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42434 --- Comment #2 from Janne Blomqvist 2011-02-05 20:20:52 UTC --- Author: jb Date: Sat Feb 5 20:20:48 2011 New Revision: 169854 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169854 Log: PR 42434 Update SYSTEM_CLOCK documentation Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi
[Bug fortran/42434] Documentation should provide advice about clock resolutions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42434 Janne Blomqvist changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Janne Blomqvist 2011-02-05 20:22:45 UTC --- Closing. CPU_TIME documentation already mentions the achievable resolution, now SYSTEM_CLOCK, and for DATE_AND_TIME the interface specifies millisecond resolution which we achieve provided the target supports gettimeofday().
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Janne Blomqvist changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #23 from Janne Blomqvist 2011-02-07 18:36:33 UTC --- Fixed, closing.
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #11 from Janne Blomqvist 2011-02-15 09:42:12 UTC --- Unfortunately I don't think I'll have time to look into it this week. As can be seen from Tobias patch, reading one character at a time is very slow. But, the comment in read_sf() is wrong, it's not actually needed to read one character at a time; what we need to do is to handle short reads correctly. One fix, I suspect, would be to convert read_sf() to use fbuf_getc() instead, which gives the impression of reading a character at a time, even though fbuf takes care of doing buffered reads in the background. But in order to do that, the read_sf() API needs to be changed so that a buffer is passed as an argument, and this buffer is then filled with data, rather than returning a pointer to the fbuf buffer.
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #13 from Janne Blomqvist 2011-02-17 12:13:53 UTC --- (In reply to comment #12) > the "file" is not seekable so the position eturne by seek always returns > zero. If you mean sseek(), don't count on that; the unix.c:raw_*() functions are more-or-less 1:1 mappings to the POSIX IO API, where the lseek() documentation http://pubs.opengroup.org/onlinepubs/9699919799/functions/lseek.html says "The behavior of lseek() on devices which are incapable of seeking is implementation-defined. The value of the file offset associated with such a device is undefined." and also in the errors section there is: [ESPIPE] The fildes argument is associated with a pipe, FIFO, or socket. FWIW, the need to handle seeking within a record (due to T* and some other edit descriptors) was one of the main motivations to introduce the fbuf layer in the first place. > I plane to see if we can do something with the seek to get it to return a > position within fbuf. If that does not seem reasonable, I will go with the > fbuf_fgetc approach which should be fairly efficient. As I recall, the problem with using fbuf_getc() in read_sf() is that the read_sf() API change would propagate such that one would need to modify all the read_x() functions in read.c to pass a buffer as a parameter rather than getting a pointer into the fbuf buffer to read from. I suspect this particular bug could be fixed by some smallish changes to read_sf() to handle short reads better, but perhaps we need to more fundamentally think about what kind of API we want to have for formatted IO?
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #3 from Janne Blomqvist 2011-02-19 16:57:18 UTC --- (In reply to comment #2) > > Is there no way to get a posix compliant ctime? Alternatively, we'll need > > autoconf magic to detect the extra arg. I know at one time it was > > relatively > > common, so autoconf magic might be around somewhere. Assuming it is you > > just > > have to do something like > > > > > > #if defined (oddballctime) > > *date = ctime_r (&now, cbuf, CSZ); > > #else > > *date = ctime_r (&now, cbuf); > > #endif > > Using ctime_r is a bit of a can of worms. The GNU autoconf manual recommends > not using ctime_r unless the inputs are known to be within certain limits. Well, since the usage here is for the Fortran intrinsics CTIME and FDATE which are defined as interfaces to ctime(), unless you're volunteering to fix all the Fortran code out there using these intrinsics, there's not much we can do. gfortran at least makes sure to call ctime_r() with a buffer of >= 26 bytes which is what POSIX requires. If some platform overflows this buffer, a bug report to the platform libc maintainers seems to be the correct approach. > It seems HP-UX and Solaris have both forms. For Solaris we had some similar problems with _r() functions, yes. This was solved by AC_USE_SYSTEM_EXTENSIONS (from ../config/extensions.m4) which sets _POSIX_PTHREAD_SEMANTICS on Solaris, which makes it expose the POSIX standard interfaces rather than some pre-standard version. > In the HP-UX 11 case, > which form is used at compilation time depends on _PTHREADS_DRAFT4: > > # ifndef _PTHREADS_DRAFT4 > extern char *ctime_r(const __time_t *, char *); > # else /* _PTHREADS_DRAFT4 */ > extern int ctime_r(const __time_t *, char *, int); > # endif /* _PTHREADS_DRAFT4 */ Yes, so HP-UX 11 seems to do the right thing by default. So the problem is HP-UX 10, which only provides the 3-arg form and not the standard one, right? > Potential autoconf test: > > # ctime_r -- > # > # There are two versions of ctime_r, one of which takes a buffer length as a > # third argument, and one which only takes two arguments. (There is also a > # difference in return values, but we handle that in the code itself.) > AC_CHECK_FUNCS(ctime_r) > if test "$ac_cv_func_ctime_r" = "yes"; then > AC_CACHE_CHECK([for 2 or 3 argument version of ctime_r], db_cv_ctime_r_3arg, [ > AC_TRY_LINK([ > #include ], [ > ctime_r(NULL, NULL, 100); > ], [db_cv_ctime_r_3arg="3-argument"], [db_cv_ctime_r_3arg="2-argument"])]) > fi > if test "$db_cv_ctime_r_3arg" = "3-argument"; then > AC_DEFINE(HAVE_CTIME_R_3ARG) > AH_TEMPLATE(HAVE_CTIME_R_3ARG, > [Define to 1 if ctime_r takes a buffer length as a third argument.]) > fi Thanks, that looks like a doable approach. Unless somebody else gets there first, I'll try to find some time to do this next week.
[Bug fortran/47494] .MOD files: Consider removing the time stamp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47494 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.20 09:34:06 CC||jb at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Janne Blomqvist 2011-02-20 09:34:06 UTC --- Confirmed. While AFAICS this is not a problem wrt removing the timestamp, one should make sure to not break the avoid-recompilation-cascade feature, see e.g. discussion in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #13 from Janne Blomqvist 2011-02-22 08:37:13 UTC --- FWIW here's a glibc PR wrt overflowing the 26 byte limit: http://sourceware.org/bugzilla/show_bug.cgi?id=1460 This was fixed in 2005, which is a while ago, but not long enough so it's completely unimaginable that someone would want to run gfortran on such a platform. For this particular glibc issue, a workaround is to make sure the buffer is at least 33 bytes. In any case, I'm thinking that Dave's suggestion to use strftime could work. Also, in addition to the autoconf manual recommending to avoid ctime/ctime_r, POSIX 2008 also marks those as obsolescent and recommends strftime instead. strftime appears to have well defined behavior for all kinds of time input and string lengths. And, using it would obviously also solve the problem of non-standard ctime_r implementations. strftime needs localtime_r, but we have already used that one without problems for quite a while (in the implementation of the DATE_AND_TIME intrinsic) so it shouldn't cause any further portability problems. The caveat is that if using a non-default locale the output is different. In practice, (lib)gfortran never calls setlocale so unless the application explicitly calls it a gfortran program runs in the "C" locale, in which case a suitable choice of format string guarantees identical output as ctime(). And, if the applications does call setlocale, outputting a localized string could be seen as a feature. (In reply to comment #6) > I guess the question we need to ask is how important are these routines > and should we be issuing warnings when they are used, much like is done > with gets. If we don't need them, I'd much prefer to see them go away > as they're a rats nest of security issues. Standard Fortran, as of Fortran 2008, supports 3 time related intrinsics; DATE_AND_TIME, SYSTEM_CLOCK, and CPU_TIME. Every other time intrinsic in gfortran is due to legacy g77 support, or some other widely used extension. If one compiles with one of the standards conformance options (-std=f) these other intrinsics are not available. Personally, I'd be happy to get rid of all the nonstandard time intrinsics, but some of our users might disagree..
[Bug fortran/47552] CTIME: Valgrind warning "depends on uninitialised value"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47552 --- Comment #2 from Janne Blomqvist 2011-02-22 15:34:57 UTC --- This seems to be because the libgfortran implementation uses gfc_charlen_type for the length of the string, but the frontend passes the address of an integer(8) variable. As a quick and dirty test, changing the libgfortran implementation to use "long" removes the valgrind errors on x86_64. Though the correct fix is to change the frontend to create a variable of the correct type. If not before, perhaps something to fix when/if we change to use size_t for string lengths, see http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 Janne Blomqvist changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-02/msg01453.htm ||l Last reconfirmed||2011.02.22 16:21:09 AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #15 from Janne Blomqvist 2011-02-22 16:21:09 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01453.html
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #16 from Janne Blomqvist 2011-02-22 19:43:10 UTC --- Patch using the fbuf_getc approach: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01475.html
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #16 from Janne Blomqvist 2011-02-22 20:24:13 UTC --- Patch which should hopefully fix the getpwuid_r issue on HP-UX 10.2: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01478.html
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #17 from Janne Blomqvist 2011-02-23 06:59:54 UTC --- Author: jb Date: Wed Feb 23 06:59:51 2011 New Revision: 170432 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170432 Log: PR 47694 Read from named pipe fails Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/fbuf.h trunk/libgfortran/io/transfer.c
[Bug libgomp/47854] New: omp_get_wtime documentation incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47854 Summary: omp_get_wtime documentation incorrect Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org The implementation of omp_get_wtime() uses clock_gettime(CLOCK_MONOTONIC, ...) if available (which IMHO is the correct choice). However, the documentation (e.g. http://gcc.gnu.org/onlinedocs/libgomp/omp_005fget_005fwtime.html ) states that "On POSIX compliant systems the seconds since the Epoch (00:00:00 UTC, January 1, 1970) are returned.". For CLOCK_MONOTONIC, this is incorrect, as POSIX 2008 only states http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html "If the Monotonic Clock option is supported, all implementations shall support a clock_id of CLOCK_MONOTONIC defined in . This clock represents the monotonic clock for the system. For this clock, the value returned by clock_gettime() represents the amount of time (in seconds and nanoseconds) since an unspecified point in the past (for example, system start-up time, or the Epoch). This point does not change after system start-up time. " And indeed, at least on Linux 2.6.32, that starting point is not the epoch.
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694 --- Comment #18 from Janne Blomqvist 2011-02-23 07:11:55 UTC --- Fixed on trunk. Keeping this PR open in order to remind us to 1) Backport to older releases once we have some experience on trunk. 2) Fix io/read.c(read_x) in the same way to use fbuf_getc instead of fbuf_read.
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #21 from Janne Blomqvist 2011-02-24 11:34:18 UTC --- (In reply to comment #20) > libgfortran.sl is built twice on HP-UX 10, once for the single thread > model and once for the dce thread model. It's the single thread build > that's the problem. Why is this necessary? Isn't it possible to use the dce thread library from a single threaded application? I suppose one way to fix this would be to somehow make the autoconf checks for the _r functions fail if the prototypes are not found?
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #22 from Janne Blomqvist 2011-02-24 14:51:21 UTC --- Author: jb Date: Thu Feb 24 14:51:17 2011 New Revision: 170471 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170471 Log: PR 47802 Test for POSIX getpwuid_r Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/intrinsics/getlog.c
[Bug libfortran/47883] New: libgfortran configuration should use AC_LINK_IFELSE instead of AC_TRY_LINK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47883 Summary: libgfortran configuration should use AC_LINK_IFELSE instead of AC_TRY_LINK Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org AC_TRY_LINK is deprecated in favor of AC_LINK_IFELSE.
[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47694
--- Comment #21 from Janne Blomqvist 2011-02-24
15:04:42 UTC ---
(In reply to comment #20)
> Some random thoughts looking at the patch
> (http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170432) - probably not
> helping at all with the regressions:
>
> I find the following a bit dubious - thought it was also odd before:
>
> + base = fbuf_getptr (dtp->u.p.current_unit);
>if (base == NULL)
> return NULL;
>
> The first line is effectively:
> base = (char*) (u->fbuf->buf + u->fbuf->pos);
>
> Thus, base is only NULL if "u->fbuf->buf" == NULL *and* u->fbuf->pos == 0. I
> am
> not sure about the second part, though I think in practice, fbuf_init has
> (hopefully!) always been called and thus it will never be NULL.
I agree, that NULL check can be removed.
>
>
> + if (q == EOF)
>
> Does this always work? We have in "static inline int fbuf_getc (gfc_unit *
> u)":
> return (unsigned char) u->fbuf->buf[u->fbuf->pos++];
> and "q" is "int".
>
> The issue I see is the following (quote from POSIX's fgetc(3p)):
> "If the integer value returned by fgetc() is stored into a variable of type
> char and then compared against the integer constant EOF, the comparison may
> never succeed, because sign-extension of a variable of type char on widening
> to
> integer is implementation-defined."
You're missing the whole picture. The definition of fbuf_getc in fbuf.h is
static inline int
fbuf_getc (gfc_unit * u)
{
if (u->fbuf->pos < u->fbuf->act)
return (unsigned char) u->fbuf->buf[u->fbuf->pos++];
return fbuf_getc_refill (u);
}
That is, the inlined fast path is for the case when there is data available in
the buffer. If there isn't data, it falls back to fbuf_getc_refill, where if
filling the buffer with more data fails EOF is returned, otherwise the next
character cast to unsigned char.
FWIW, if you dig into the glibc sources, the getc() macro is implemented in a
very similar way.
