between "benign" extensions and dangerous ones, though there might be
improvements to be made of how the bitflags are handled and passed to
the runtime.
I can sympathize with the desire to make the standard behavior the
default, but the reality is probably that you'll drown in bug rep
e template for every 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
e template for every 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
Public bug reported:
On a system with python 3.12 installing the python ipaclient package
(this is on Ubuntu 24.04 using the distro packages) produces the
warnings:
Setting up python3-ipaclient (4.10.2-2) ...
/usr/lib/python3/dist-packages/ipaclient/remote_plugins/2_164/automember.py:19:
SyntaxW
Public bug reported:
On a system with python 3.12 installing the python ipaclient package
(this is on Ubuntu 24.04 using the distro packages) produces the
warnings:
Setting up python3-ipaclient (4.10.2-2) ...
/usr/lib/python3/dist-packages/ipaclient/remote_plugins/2_164/automember.py:19:
SyntaxW
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
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
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
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
king on the compiler outright, could be a
way of growing the open source Fortran programmer base, which could
eventually grow into contributors to the compiler itself? In
particular if they want to use some newfangled Fortran feature that
doesn't work in GFortran; scratching your own itch is always a good
motivator!
--
Janne Blomqvist
The second of the patches mentioned in #27 (with git SHA 1e2677...) has,
I believe, been backported to Ubuntu kernels 5.15.0-48 and 5.4.0-126.
We've still hit this with Ubuntu Jammy on 5.15.0-53, so I guess the
first commit needs to be backported as well.
--
You received this bug notification be
8 mentions changing int to bool, where
appropriate, which I think is uncontroversial, but this?
--
Janne Blomqvist
8 mentions changing int to bool, where
appropriate, which I think is uncontroversial, but this?
--
Janne Blomqvist
I'm not personally working on
GFortran at this time so somebody else would have to pick it up.
--
Janne Blomqvist
I'm not personally working on
GFortran at this time so somebody else would have to pick it up.
--
Janne Blomqvist
for pointing out that -g does not make the code slower.
> > Is there an option that prevents the sourcecode to be included when -g is
> > used?
You might try -frecord-gcc-switches. There's also
-grecord-gcc-switches (which puts the info somewhere in the debug
data), which is enabled b
On Thu, Jun 2, 2022 at 10:33 PM Kay Diederichs
wrote:
> Am 02.06.22 um 21:06 schrieb Janne Blomqvist:
> > As an alternative approach, make a command-line option (say, "-v")
> > that prints the version number of the program, name of the author and
> > other pertin
e program, name of the author and
other pertinent information, as well as the output of
compiler_version() and compiler_options(), and then exits. That would
ensure that those calls won't be optimized away.
--
Janne Blomqvist
It seems the default was fixed in upstream at
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/misc/mke2fs.conf.in?id=a23b50cdb55cb826b8745cbc37429c93f7b60c66
Also, it seems Ubuntu 22.04 has a version of e2fsprogs (1.46.5-2ubuntu1)
which includes this change. Thus I think this bug can b
It seems the default was fixed in upstream at
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/misc/mke2fs.conf.in?id=a23b50cdb55cb826b8745cbc37429c93f7b60c66
Also, it seems Ubuntu 22.04 has a version of e2fsprogs (1.46.5-2ubuntu1)
which includes this change. Thus I think this bug can b
Public bug reported:
Lesstif was abandoned after Motif was open sourced in 2012, and indeed
the Lesstif library is no longer packaged in either Debian or Ubuntu as
Lesstif-using packages have been updated to link to motif (libxm4).
Including DDD. However, the package description still says
"This
Public bug reported:
The package description for the libxt-* packages says:
libXt provides the X Toolkit Intrinsics, an abstract widget library upon
which other toolkits are based. Xt is the basis for many toolkits, including
the Athena widgets (Xaw), and LessTif (a Motif implementation).
Le
Public bug reported:
The package description for the libxt-* packages says:
libXt provides the X Toolkit Intrinsics, an abstract widget library upon
which other toolkits are based. Xt is the basis for many toolkits, including
the Athena widgets (Xaw), and LessTif (a Motif implementation).
Le
Public bug reported:
The package description for the libxt-* packages says:
libXt provides the X Toolkit Intrinsics, an abstract widget library upon
which other toolkits are based. Xt is the basis for many toolkits, including
the Athena widgets (Xaw), and LessTif (a Motif implementation).
Le
Public bug reported:
The package description for the libxt-* packages says:
libXt provides the X Toolkit Intrinsics, an abstract widget library upon
which other toolkits are based. Xt is the basis for many toolkits, including
the Athena widgets (Xaw), and LessTif (a Motif implementation).
Le
1 MPI task per node
SEGMENTCOUNT=100
#Offset must be equal to ntasks-per-node
OFFSET=1
srun IOR -a POSIX -t 1000 -b 1000 -s $SEGMENTCOUNT -C -Q $OFFSET -e -i
5 -d 10 -v -w -r -W -R -g -u -q -o testfile
This should fail due to corruption within minutes if the testfile is
on NFS. Not saying a
AFAIU the libm in musl hasn't received anywhere close to the same
level of attention to correctness and performance as the glibc one.
Further, depending on how you provision accounts in your cluster, the
lack of NSS in musl might be a problem.
--
J
-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
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
ch contain
the autoconf macros mentioned in your error message).
--
Janne Blomqvist
ur 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
;)' 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
n away, so can't double-check) consumed about 170W
when idle.
--
Janne Blomqvist
___
Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
https://beowulf.org/cgi-bin/mailman/listinfo/beowulf
wer or be thrown in the trash. Of course, if they pay for
compute performance (for some suitable definition of performance) rather
than just cpu-hours old phones will be less power efficient.
--
Janne Blomqvist
___
Beowulf mailing list, Beowulf@beowulf.o
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
//cgroup is problematic on array jobs.
Thanks for trying it out! Indeed, we only recently upgraded to 18.08 and
it seems the upgrade broke it. Fixed now (or broke it if you're still on
17.11... :-) ).
I also fixed the array jobs issue while at it.
--
Janne Blomqvist
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
e comment field at the end of
the job.
The above is an ansible role, but if you're not using ansible you can
just pull the scripts from the "files" subdirectory.
--
Janne Blomqvist, D.Sc. (Tech.), Scientific Computing Specialist
Aalto University School of Science, PHYS & NBE
+
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
intended? Is it a consequence of something in my environment?
I vaguely recall reading somewhere that accounting_storage_mysql is
deprecated and that one should use slurmdbd instead. So maybe it's
possible to sidestep the problem by not trying to build that module at all?
--
Janne Blomqvist,
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
On 23/09/2019 11.16, Janne Blomqvist wrote:
> Hello,
>
> scouring the release notes for the latest MLNX_OFED (version
> 4.6-1.0.1.1, and no, still no RHEL 7.7 support), I read a note about an
> upcoming API change at
> https://docs.mellanox.com/display/MLNXOFEDv461000/Change
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
MLNX_OFED 5.0?
And thus MLNX_OFED will become a much "thinner" add-on than currently?
Has anyone tested these different configurations, if there's any
difference in performance and/or functionality?
1. Distro RDMA stack (rdma-core)
2. MLNX_OFED full
3. MLNX_OFED RPMS_UPSTREAM
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 want to wor
runk?), then commit 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
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
To be 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
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
1 - 100 of 1021 matches
Mail list logo
