type and export the symbol
void matmul_r4(gfc_array_r4* a, gfc_array_r4* b, gfc_array_r4* c, ...)
{
matmul(a, b, c, ...);
}
// And so on for other types
}
--
Janne Blomqvist
ose or not they are then included in the exported symbol list.
It's possible to override this to look for specific symbol versions
etc., but that probably goes deep into the weeds of target-specific
stuff (e.g. are we looking for cospi@FBSD_1.7, cospi@GLIBC_X.Y.Z, or
something else?). I'm sure you don't wanna go there.
--
Janne Blomqvist
enerate that code directly in the front-end, couldn’t
> we?
The frontend generally doesn't know what the target libm implements,
hence it's better to just generate the call, and if necessary have a
barebones implementation in libgfortran if libm doesn't implement it
properly.
--
Janne Blomqvist
.
Per analysis done then, it seems SunOS 4 was the last system where
free() of a NULL pointer didn't behave per the spec.
Also in Jim's patch intl/ and zlib/ directories were not touched as
those are imported from other upstreams.
--
Janne Blomqvist
tions changing int to bool, where
appropriate, which I think is uncontroversial, but this?
--
Janne Blomqvist
t this time so somebody else would have to pick it up.
--
Janne Blomqvist
of discussed this issue back when the Linux kernel dropped
support for i386. See thread starting at
https://gcc.gnu.org/legacy-ml/gcc/2012-12/msg00079.html (a thread
where you participated as well)
--
Janne Blomqvist
n such a test
as part of the testsuite.
But if anyone has tests that reliably deadlock within a relatively
short time, then yeah, such testcases would be awesome.
--
Janne Blomqvist
On Fri, Jan 31, 2020 at 3:38 PM Janne Blomqvist
wrote:
>
> Simplify IO locking in libgfortran. The new IO implementation avoids
> accessing units without locks, as seen in PR 92836. It also avoids
> lock inversion (except for a corner case wrt namelist query when
> rea
Simplify IO locking in libgfortran. The new IO implementation avoids
accessing units without locks, as seen in PR 92836. It also avoids
lock inversion (except for a corner case wrt namelist query when
reading from stdin and outputting to stdout), making it easier to
verify correctness with tools
add your changes to your
previous commit.
Another option is the interactive rebase (git rebase -i). That allows
you to e.g. "squash" commits, that is, combine two or more commits
into one.
--
Janne Blomqvist
1 | float foo(int, float, bool tmp = false);
> |^
> a.c: In function 'bar':
> a.c:8:7: warning: implicit declaration of function 'foo'
> [-Wimplicit-function-declaration]
> 8 | x = foo(n, x);
> | ^~~
Well, frontends are nowadays C++, so
a) No need to include stdbool.h, bool is a builtin type.
b) optional arguments are a thing (they are also used elsewhere in the
Fortran frontend).
--
Janne Blomqvist
middle end.
> > Hence, the diagnostic there wasn't optimal.
> >
> > Fixed by introducing a new function; now one only needs to make sure
> > that no new code will re-introduce "lb->location" :-)
> >
> > Build and regtested on x86-64-gnu-linux.
> > OK for the trunk?
> >
> > Tobias
> >
--
Janne Blomqvist
uild and regtested on x86-64-gnu-linux.
> OK for the trunk?
Yeah, this seems a bit convoluted. But at least we now have yet
another testcase to catch similar issues. So, Ok.
--
Janne Blomqvist
On Wed, Nov 27, 2019 at 10:29 AM Tobias Burnus wrote:
>
> On 11/27/19 8:58 AM, Janne Blomqvist wrote:
> > On Tue, Nov 26, 2019 at 1:12 PM Tobias Burnus
> > wrote:
> >> AUTOMATIC attribute
> > Speaking of which, to avoid confusion maybe we should renam
, though not being a global reviewer I can't
approve it.
--
Janne Blomqvist
he
Fortran standard description of an "automatic data object" doesn't
really have anything to do with the option, and neither does the
option have anything to do specifically with the DEC AUTOMATIC
specifier?
--
Janne Blomqvist
ge-check is specified.
>
>
> 2019-11-24 Harald Anlauf
>
> PR fortran/92629
> * gfortran.dg/pr92629.f90: New testcase.
Ok, thanks.
--
Janne Blomqvist
On Thu, Nov 21, 2019 at 12:31 AM Janne Blomqvist
wrote:
>
> On Thu, Nov 21, 2019 at 12:18 AM Janne Blomqvist
> wrote:
> >
> > On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote:
> > > (Why do we zero %eax
> > > before each call? It should not be a variad
On Thu, Nov 21, 2019 at 12:18 AM Janne Blomqvist
wrote:
>
> On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote:
> > (Why do we zero %eax
> > before each call? It should not be a variadic call right?)
>
> Not sure. Maybe some belt and suspenders thing? I guess someon
On Wed, Nov 20, 2019 at 11:35 PM Thomas König wrote:
>
> Am 20.11.19 um 21:45 schrieb Janne Blomqvist:
> > BTW, since this is done for the purpose of optimization, have you done
> > testing on some suitable benchmark suite such as polyhedron, whether
> > it a) generates an
done for the purpose of optimization, have you done
testing on some suitable benchmark suite such as polyhedron, whether
it a) generates any different code b) does it make it go faster?
Is there a risk of performance regressions due to higher register pressure?
--
Janne Blomqvist
is now also handled.
>
> So maybe __readonly_ , __rdonly_, __rd_or the like? dummy is really
> misleading a name in the dumps..
Well, dummy is a term with a precise definition in the Fortran
standard, so in a way it's good so one realizes it has something to do
with a dummy argument. But yes, it's a bit misleading because it's not
the dummy argument itself but rather a dereferenced copy of it. I
suggest __readonly_dereferenced_dummy_copy_yes_this_is_a_really_long_name_.
:)
--
Janne Blomqvist
.gnu.org/ml/gcc-patches/2019-11/msg00957.html .
--
Janne Blomqvist
On Wed, Nov 20, 2019 at 5:46 PM Tobias Burnus wrote:
>
> Hi Janne,
>
> On 11/18/19 9:34 PM, Janne Blomqvist wrote:
> > 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.
>
&g
PING
On Wed, Nov 13, 2019 at 11:05 PM Janne Blomqvist
wrote:
>
> On Wed, Nov 13, 2019 at 10:41 PM Andrew Pinski wrote:
> >
> > On Wed, Nov 13, 2019 at 12:37 PM Janne Blomqvist
> > wrote:
> > >
> > > The FTP protocol is getting long in the tooth
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
:
2019-11-18 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
On Wed, Nov 13, 2019 at 10:41 PM Andrew Pinski wrote:
>
> On Wed, Nov 13, 2019 at 12:37 PM Janne Blomqvist
> wrote:
> >
> > The FTP protocol is getting long in the tooth, and we should emphasize
> > HTTP where that is available. This patch changes various gcc.gnu.o
awkward kludges to
firewalls and load-balancing daemons
- FTP servers have no support for caching or accelerators, which has
significant performance impacts
- Most software implementations have stagnated and see infrequent
updates
ChangeLog:
2019-11-13 Janne Blomqvist
Convert the download_prerequisites script to use http instead of
ftp. This works better with firewalls, proxies, and so on. It's also
faster, a quick test on my system before patch:
time contrib/download_prerequisites --directory=/tmp/foo --force
...
real0m17,843s
After patch:
time
. Or even module
procedures without bind(C)?
That being said, I've seen examples where people have figured out the
symbol mangling and are calling module procedures directly from C, so
will breaking such code (even if not officially supported) be an
issue?
--
Janne Blomqvist
On Tue, Nov 12, 2019 at 6:59 AM Jeff Law wrote:
>
> On 11/10/19 4:05 AM, Janne Blomqvist wrote:
> > On Sun, Nov 10, 2019 at 11:43 AM Thomas Koenig
> > wrote:
> >>
> >> Hi Janne,
> >>
> >>> Bump the minimum MPFR version to 3.1.0, relea
instructive.
>
> Regression-tested. OK for trunk?
Wouldn't it be even better to pass scalar intent(in) variables by
value? The obvious objection of course is ABI, but for procedures with
an explicit interface we're not following any particular ABI anyways?
--
Janne Blomqvist
* module.c (gzopen_included_file, gzopen_included_file_1)
> (gzopen_intrinsic_module, bad_module, gfc_use_module): Use fully
> qualified module path for error reporting.
Ok.
--
Janne Blomqvist
On Mon, Nov 11, 2019 at 8:29 PM Joseph Myers wrote:
>
> On Sat, 9 Nov 2019, Janne Blomqvist wrote:
>
> > 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 bu
-gnu, committed r278027 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.
---
gcc/fortran/trans-decl.c | 19 ++-
1 file changed, 10
https://gcc.gnu.org/gcc-10/changes.html ?
Sure, will do, when the patch is accepted.
--
Janne Blomqvist
frontend, as well as
fixing PR 91828.
ChangeLog:
2019-11-09 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-09 Janne Blomqvist
PR fortran/91828
On Thu, Oct 31, 2019 at 10:04 PM Steve Kargl
wrote:
>
> On Thu, Oct 31, 2019 at 09:30:26PM +0200, Janne Blomqvist wrote:
> >
> > I'd personally prefer the current behavior. I.e. just let the
> > underlying OS/libc handle it as it sees fit. No need to invent our own
&g
is a SIGSTOP.
> Depending on whether a user installed a signal handler,
> SIGSTOP might lead to a zombie process so I did not
> mention it as a possibility.
I'd personally prefer the current behavior. I.e. just let the
underlying OS/libc handle it as it sees fit. No need to invent our ow
;
> > 2019-09-29 Damian Rouson
> >
> > PR fortran/91513
> > * resolve.c (resolve_ordinary_assign): Improved error message.
> >
> > 2019-09-29 Damian Rouson
> >
> > PR fortran/91513
> > * gfortran.dg/impure_assignment_2.f90: Update dg-error regex.
> >
> > --
> > Steve
Ok
--
Janne Blomqvist
ask awaits a brave soul as gfc_match_decl_type_spec
> is a minefield for bugs. This is dues to the fact the the functions
> has grown by adding kludge upon kludge upon kludge. The first
> thing to fix is the broken parsing that follows from the
> matching of 'type('.
>
> --
> Steve
Ok.
--
Janne Blomqvist
ction reference.
>
> 2019-09-30 Steven G. Kargl
>
> PR fortran/91943
> gfortran.dg/pr91943.f90
>
> --
> Steve
Ok, though I believe your other BOZ patch that I just reviewed applies
on top of this one?
--
Janne Blomqvist
ible
> run-on errors.
> * resolve.c (resolve_function): Actual arguments cannot be BOZ in
> a function reference.
>
> 2019-10-09 Steven G. Kargl
>
> PF fortran/92018
> * gfortran.dg/gnu_logical_2.f90: Update dg-error regex.
> * gfortran.dg/pr81509_2.f90: Ditto.
> * gfortran.dg/pr92018.f90: New test.
>
> --
> Steve
Ok.
--
Janne Blomqvist
h_subscript): BOZ cannot be an array subscript.
>
> 2019-10-09 Steven G. Kargl
>
> PR fortran/92019
> * gfortran.dg/pr92019.f90: New test.
>
> --
> Steve
Ok.
--
Janne Blomqvist
attached test cases? The only difference is in "module
> target_procs".
As previously mentioned, please use "stop N" instead of "call abort()".
--
Janne Blomqvist
h a new
> ChangeLog.
Just a minor nit, why bother with the #define, why not just use
__builtin_unreachable directly?
(I think for the frontend there's the argument that it might be
compiled with a non-GCC compiler which might not support
__builtin_unreachable. But libgfortran is always compiled with the
corresponding gcc frontend, so this doesn't apply there.)
--
Janne Blomqvist
t; a bit of kludge. As a results of comments from Janne Blomqvist I
> investigated whether the existing mechanism for character length in
> gfc_typespec could be used for character literals. This turn out to be
> impractical.
>
> The character length for literals is already
On Thu, Sep 19, 2019 at 5:43 PM Damian Rouson
wrote:
>
>
>
> On Thu, Sep 19, 2019 at 5:04 AM Janne Blomqvist
> wrote:
>>
>>
>> One thing that's unclear to me is how should I actually make my stuff
>> appear in the public repo? Say I w
and push?
4b) Or do I first rebase my branch on top of the latest master, to
produce a slightly less branchy history?
4c) Or do I (manually?) apply my patch on master, to create a linear history?
4d) Something else entirely?
Thanks,
--
Janne Blomqvist
just a gcc_checking_assert I think a back-port
> of this fix
> to the gcc-9 branch will not be necessary.
>
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
>
>
> Thanks
> Bernd.
Ok.
--
Janne Blomqvist
t_hwi() instead of mpz_get_si(). And
for the *printf() format string you should use
HOST_WIDE_INT_PRINT_DEC.
Thanks,
--
Janne Blomqvist
e specific: deprecate -traditional-cpp for GCC10, remove in GCC11.
The Fortran frontend uses traditional mode, for reasons I can't recall
at the moment.
--
Janne Blomqvist
or other malformed
> type-specs. Sett pr91660_2.f90.
>
> OK to commit?
Ok.
--
Janne Blomqvist
-pc-linux-gnu, Ok for trunk?
libgfortran/ChangeLog:
2019-09-04 Janne Blomqvist
* intrinsics/random.c (master_init): Replace with
master_state.init.
(njumps): Remove variable.
(master_state): Make instance of struct prng_state.
(init_rand_state): When
On Wed, Aug 28, 2019 at 3:43 AM Steve Kargl
wrote:
>
> The attach patch was built and tested on i586-*-freebsd.
> It includes a check for ALLOCATED with no arguments.
> OK to commit?
Ok.
--
Janne Blomqvist
On Wed, Aug 28, 2019 at 1:01 AM Steve Kargl
wrote:
>
> The attached ptch implements additional checks on the
> ORDER dummy argument for the RESHAPE intrinsic function.
> Built and regression tested on x86_64-*-freebsd. OK to
> commit?
Ok.
--
Janne Blomqvist
On Wed, Aug 28, 2019 at 3:37 AM Steve Kargl
wrote:
>
> The attached patch has been built and tested on x86_64-*-freebsd.
> It adds additional checks for the status dummy argument, and
> therby prevents an ICE. OK to commit?
Ok.
--
Janne Blomqvist
on-tested on powerpc64le-unknown-linux-gnu. Documentation
> tested by "make dvi" and "make pdf".
>
> OK for trunk?
Ok.
--
Janne Blomqvist
erface.
>
> 2019-08-16 Steven G. Kargl
>
> PR fortran/78719
> * gfortran.dg/pr78719_1.f90: New test.
> * gfortran.dg/pr78719_2.f90: Ditto.
> * gfortran.dg/pr78719_3.f90: Ditto.
Ok, thanks.
--
Janne Blomqvist
en G. Kargl
>
> PR fortran/91471
> * gfortran.dg/pr91471.f90: New test.
Ok.
--
Janne Blomqvist
PR fortran/78739
> * match.c (gfc_match_st_function): When matching a statement
> function,
> need to check if the statement function name shadows the function
> name.
>
> 2019-08-16 Steven G. Kargl
>
> PR fortran/78739
> * fortran.
-08-16 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
his can be done
> with the infrastructure of this patch.
>
> So, OK for trunk?
The patch itself looks Ok. One worry, are you introducing an
O(N**2)(?) algorithm (looping over all symbols for every symbol?), and
does this cause performance issues when compiling some gigantic F77
project?
If this worry is unfounded, Ok for trunk.
--
Janne Blomqvist
On Mon, Aug 12, 2019 at 11:23 PM Steve Kargl
wrote:
>
> On Sun, Aug 11, 2019 at 12:37:49PM +0300, Janne Blomqvist wrote:
> > Update the PRNG from xorshift1024* to xoshiro256** by the same
> > author. For details see
> >
> > http://prng.di.unimi.it/
> >
xpr.c (gfc_simplify_expr): Simplifcation of an array with a kind
> type inquiry suffix yields a constant expression.
>
> 2019-08-12 Steven G. Kargl
>
> PR fortran/87993
> * gfortran.dg/pr87993.f90: New test.
Ok.
--
Janne Blomqvist
e a binding target. While here, wrap long line.
>
> 2019-08-12 Steven G. Kargl
>
> PF fortran/89647
> * gfortran.dg/pr89647.f90: New test.
>
> OK to commit?
Ok, thanks.
--
Janne Blomqvist
On Sat, Aug 10, 2019 at 11:57 PM Steve Kargl
wrote:
>
> On Sat, Aug 10, 2019 at 11:34:15PM +0300, Janne Blomqvist wrote:
> > When moving a local variable from the stack to static storage, the
> > procedure is no longer safe to be called recursively or concurrently
> > from
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-11 Janne Blomqvist
PR fortran/91414
* check.c (gfc_check_random_seed): Reduce
-gnu, Ok for trunk?
gcc/fortran/ChangeLog:
2019-08-10 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
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
): Likewise.
One of these should be _UNFORMATTED?
--
Janne Blomqvist
coalesce IO's by itself, so the granularity of IO
syscalls is not necessarily the same as the actual IO to devices.
Network filesystems like NFS/Lustre/GPFS may have less latitude here
due to coherency requirements etc.)
--
Janne Blomqvist
Hi,
another leftover from the py3 conversion. Committed r272921 as obvious.
2019-07-02 Janne Blomqvist
PR other/91048
* mklog (read_user_info): Open ~/.mklog in string mode.
Index: mklog
===
--- mklog(revision
move erroneous error
> checking for BIND(C) and PRIVATE attributes.
>
> 2019-06-19 Steven G. Kargl
>
> PR fortran/86587
> * gfortran.dg/pr86587.f90: New test.
>
> --
> Steve
Ok.
--
Janne Blomqvist
On Sat, Jun 15, 2019 at 2:23 AM Steve Kargl
wrote:
>
> On Fri, Jun 14, 2019 at 08:07:36AM -0700, Steve Kargl wrote:
> > On Fri, Jun 14, 2019 at 01:08:48PM +0300, Janne Blomqvist wrote:
> > > As GCC now provides builtins for doing integer overflow checking, lets
>
n offloading (given the recent Frontier
supercomputer announcement, I hope we will receive more work in this
area in the future).
--
Janne Blomqvist
On Fri, Jun 14, 2019 at 1:16 AM Steve Kargl
wrote:
>
> The attached patch suppresses the spurious warnings that
> would otherwise occur for the testcase. Regression
> tested cleanly on x86_64-*-freebsd. OK to commit?
Ok, thanks for the patch.
--
Janne Blomqvist
As GCC now provides builtins for doing integer overflow checking, lets
use it when checking for overflow in xmallocarray.
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
libgfortran/ChangeLog:
2019-06-14 Janne Blomqvist
* runtime/memory.c (SIZE_MAX):Remove macro definition
first (PDF) search (Blelloch 1999) as an alternative to work
stealing. Here's a presentation about some recent work in this area,
although for Julia and not OpenMP (no idea if PDF would fit with OpenMP at
all): https://www.youtube.com/watch?v=YdiZa0Y3F3c
--
Janne Blomqvist
the function that spawns new threads or awakes the ones waiting for
> work, or gomp_thread_start in the same file for the function actually run by
> the libgomp library created threads.
>
> > I can't find the entry point of the worker threads from the event tracing
> > and the
railing sign is ignored without error
> implicit none
> integer :: ios
Do you know which commit caused this? Was it something recent? Based
on a quick look, at least for fmt_en this shouldn't happen..
Since this seems to happen semi-regularly, would it be possible to do
something at the dejagnu level, e.g. to fail a test that uses
ftruncate/chsize even though it's not marked with target fd_truncate.
Hard to see how that could be verified without running testcases under
strace or something like that.
--
Janne Blomqvist
On Wed, May 22, 2019 at 3:20 PM Andrew Stubbs wrote:
>
> On 22/05/2019 12:35, Janne Blomqvist wrote:
> > Thanks for the catch. Though for size_t you should use build_zero_cst
> > (size_type_node). size_zero_node is a zero constant of type sizetype,
> > which is not th
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.
> >
> >
> ping?
Committed as r271511.
--
Janne Blomqvist
numbers too far.
>
> This patch adds a "\\d+" match to allow variable-width matches.
>
> OK to commit?
Ok.
--
Janne Blomqvist
the catch. Though for size_t you should use build_zero_cst
(size_type_node). size_zero_node is a zero constant of type sizetype,
which is not the same as size_type_node (size_t in C). Ok with that
change.
--
Janne Blomqvist
On Tue, May 21, 2019 at 10:47 AM Janne Blomqvist
wrote:
>
> On Tue, May 21, 2019 at 10:32 AM Martin Liška wrote:
> >
> > Hi.
> >
> > There's a regression I see after the transition to python3:
> >
> > $ cat /tmp/patch
> > diff --git a/gcc/testsuite
parse_patch(contents)
> File "/home/marxin/Programming/gcc/contrib/mklog", line 273, in parse_patch
> lines = contents.split('\n')
> TypeError: a bytes-like object is required, not 'str'
>
> Thanks,
> Martin
Oof, thanks for the report, looking into it!
--
Janne Blomqvist
.
- Remove the "from __future__ import print_function".
- Change the shebang line to search for python3 in the environment.
- Modify the run() function to return a str instead of bytes.
- Update the copyright year.
contrib/ChangeLog:
2019-05-20 Janne Blomqvist
* mklog: Convert t
On Sun, May 19, 2019 at 9:26 PM Steve Kargl
wrote:
>
> On Sun, May 19, 2019 at 09:10:57PM +0300, Janne Blomqvist wrote:
> > On Sun, May 19, 2019 at 7:15 PM Steve Kargl
> > wrote:
> > >
> > > On Sun, May 19, 2019 at 01:40:59PM +0300, Janne Blomqvist
On Sun, May 19, 2019 at 7:15 PM Steve Kargl
wrote:
>
> On Sun, May 19, 2019 at 01:40:59PM +0300, Janne Blomqvist wrote:
> >
> > +#if defined(HAVE_SIGACTION) && defined(HAVE_WAITPID)
> > + static bool sig_init_saved;
> > + bool sig_init = __atomic
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
known, it seems to have been
happily ignored for the past 30 years.
And yes, while I think one year might be a quite optimistic timeframe
to get this fixed, I agree we shouldn't keep the workaround
indefinitely either. I think the best way would be if CBLAS & LAPACKE
would be fixed, and then we could tell people to use those rather than
their own in-house broken interfaces.
--
Janne Blomqvist
f my first
contributions to GFortran back in the day was ripping out that.
>
>
> On 16/05/2019 22:10, Janne Blomqvist wrote:
> > On Thu, May 16, 2019 at 10:59 PM Thomas Koenig
> > wrote:
> >>
> >> Hi Janne,
> >>
> >>> fork() semantics can be pro
t has fork but not posix_spawn?
> The patch is OK from my side if you add fork() as a fallback option.
Sure. I'm quite sure it's dead code that will never be executed, but
hey, it's ifdeffed away so whatever.
--
Janne Blomqvist
ll, at least
Linux, macOS, *BSD, cygwin, Solarix, AIX) remotely modern unix type
systems, a further fallback to fork() is IMHO not warranted.
--
Janne Blomqvist
with posix_spawn.
2019-05-16 Janne Blomqvist
PR libfortran/90038
* configure.ac (AC_CHECK_FUNCS_ONCE): Check for posix_spawn
instead of fork.
* intrinsics/execute_command_line (execute_command_line): Use
posix_spawn instead of fork.
* Makefile.in
On Wed, May 15, 2019 at 4:41 PM Jakub Jelinek wrote:
>
> On Sun, May 12, 2019 at 12:47:04AM +0300, Janne Blomqvist wrote:
> > --- a/gcc/fortran/parse.c
> > +++ b/gcc/fortran/parse.c
> > @@ -6331,6 +6331,24 @@ done:
> >}
> >
> >/* Dump C pr
On Wed, May 15, 2019 at 9:30 PM Damian Rouson
wrote:
>
> Could someone please update the Fortran 2018 status page on the wiki
> to reflect this patch?
Thanks for the reminder, done.
--
Janne Blomqvist
1 - 100 of 800 matches
Mail list logo
