e target libm includes
those 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
on. We could generate 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
pet added then which is still there.
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
8 mentions changing int to bool, where
appropriate, which I think is uncontroversial, but this?
--
Janne Blomqvist
ow one would run 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
> reading
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
;)' before '=' token
> 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
o the 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 rename t
Ok, 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
known intent) 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
//gcc.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.
>
> OK – th
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, and we
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
dding 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 Blom
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 contrib/d
dule procedures. 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
tructive.
>
> 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
R fortran/81651
> * 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
linux-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 c
te in 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 o
here 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 inv
?
> >
> > 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
waits 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
uppress possible
> 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
cript): 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
tch with 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 hel
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
use gfc_mpz_get_hwi() instead of mpz_get_si(). And
for the *printf() format string you should use
HOST_WIDE_INT_PRINT_DEC.
Thanks,
--
Janne Blomqvist
or other malformed
> type-specs. Sett pr91660_2.f90.
>
> OK to commit?
Ok.
--
Janne Blomqvist
86_64-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):
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
me file. This 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/
> >
* expr.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
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
ED): Likewise.
One of these should be _UNFORMATTED?
--
Janne Blomqvist
will 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
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
ith trailing 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
xtra 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/test
ffs = 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_i
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
while the issue has been 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
the authors of this paper. One of 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,
> >>
> >&
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
l (well, 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.
* Makefi
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
As of Fortran 2018 it's allowed to open the same file on multiple
units.
fortran/ChangeLog:
2019-05-15 Janne Blomqvist
PR fortran/90461
* io/open.c (new_unit): Don't check if the file is already open
for F2018.
testsuite/ChangeLog:
2019-05-15 Janne
On Sun, May 12, 2019 at 11:29 AM Janne Blomqvist
wrote:
>
> On Sun, May 12, 2019 at 11:06 AM Thomas Koenig wrote:
> > (I thought for a second about guarding about double inclusion, but
> > including prototypes twice is harmless, and this should be the
> > user's r
don't know which name the end user wants to save the output as.
--
Janne Blomqvist
When generating C prototypes for Fortran procedures with the
-fc-prototypes and -fc-prototypes-external options, print a snippet
defining macros for complex types, and add C++ support by suppressing
mangling.
fortran/ChangeLog:
2019-05-12 Janne Blomqvist
* dump-parse-tree.c
fortran/90329
- * gfortran.dg/dump-parse-tree.c: Include version.h.
+ * dump-parse-tree.c: Include version.h.
(gfc_dump_external_c_prototypes): New function.
(get_c_type_name): Select "char" as a name for a simple char.
Adjust to handling external functions. Also handle complex.
--
Janne Blomqvist
On Thu, May 2, 2019 at 9:02 AM Steve Kargl
wrote:
>
> The attach patch adds an additional check for the
> STOP code when -std=f2008 is used. The patch has
> been bootstrapped and regression tested on
> x86_64-*-freebsd for trunk. OK to commit?
Ok.
--
Janne Blomqvist
PR fortran/68009
> * iresolve.c: Include trans.h.
> (gfc_resolve_fe_runtine_error): Set backend_decl on
> resolved_sym.
Ok for trunk/7/8. Thanks!
--
Janne Blomqvist
On Tue, Feb 26, 2019 at 9:19 AM Thomas Koenig wrote:
>
> Hi Dominique,
>
>
> > AFAICT there is no patch attached.
>
> I guess that would have helped :-)
>
> Here it is.
Ok, thanks.
--
Janne Blomqvist
ngeLog entries are wrong.
Thanks for the patch!
--
Janne Blomqvist
1 - 100 of 781 matches
Mail list logo