. can use the intrinsics
from IEEE_ARITHMETIC?
This thread also has some interesting discussion on the topic:
https://github.com/JuliaLang/julia/issues/7866
--
Janne Blomqvist
On Tue, Jul 17, 2018 at 11:06 PM, Janne Blomqvist wrote:
> On Tue, Jul 17, 2018 at 6:36 PM, Thomas Koenig
> wrote:
>
>> Hi Kyrill,
>>
>> The current implementation expands to:
>>> mvar = a1;
>>> if (a2 .op. mvar || isnan (mvar))
>>>
nline sequence is emitted where it is available.
> * No calls to library fmin*/fmax* are emitted where there were none.
> * MIN/MAX_EXPR sequence are emitted where possible.
>
> Is this acceptable?
>
So if I understand it correctly, the "internal fn" thing is a mechanism
that allows to check whether the target supports expanding a builtin inline
or whether it requires a call to an external library function?
If so, then yes, Ok, thanks for the patch!
--
Janne Blomqvist
ensible wrt NaN's, which it wouldn't be if we just use a plain
MIN/MAX_EXPR. Is it worth taking a performance hit for, though? In
particular, if other compilers are inconsistent, we might as well do
whatever is fastest.
--
Janne Blomqvist
on the optimization level. Also, with a
separate option it would be easy to check how it affects performance at
different optimization levels.
What about making it a -fcheck=short-circuit-logicals (or however you want
to spell it?) option, that also would be enabled with -fcheck=all?
--
Janne Blomqvist
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
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
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
te in https://gcc.gnu.org/gcc-10/changes.html ?
Sure, will do, when the patch is accepted.
--
Janne Blomqvist
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
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
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
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
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
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
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
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
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
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
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
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
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
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
;)' 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
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
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
ran/30162
> * gfortran.texi: Document unformatted sequential file format
> and I/O with special files.
--
Janne Blomqvist
ifier with INQUIRE, even it it "works" (as in, does
not generate an error), there is no sensible concept of file position
for a stream file anyway, so perhaps we shouldn't explicitly say it's
supported either.
- Wrt. block devices, perhaps remove that section and cover it just
with the "...implementation defined" sentence above.
--
Janne Blomqvist
Hello,
a format string in the example for DATE_AND_TIME contained a syntax
error. Committed as obvious.
2013-09-27 Janne Blomqvist
* intrinsic.texi (DATE_AND_TIME): Fix example.
Index: intrinsic.texi
===
--- intrinsic.texi
gh (see e.g. the above
paragraph).
Some related mangling PR's:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51802
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 (not the PR itself,
but the discussion in the comments)
--
Janne Blomqvist
Gfortran name mangling ABI
==
I
obvious.
2012-10-06 Janne Blomqvist
* configure.ac: Check for presence of secure_getenv.
* libgfortran.h: Use HAVE_SECURE_GETENV.
* Makefile.in: Regenerated.
* aclocal.m4: Regenerated.
* config.h.in: Regenerated.
* configure: Regenerated
> the Linux man page for mkstemp).
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
Ok, thanks for the patch.
> Is this something one should back port to the branches?
By all means, if you have the energy.
--
Janne Blomqvist
is mostly an idea for further work, and is not meant
as a requirement for accepting the patch)
Ok for trunk, although wait for a few days in case there is a storm of
protest on the C vs. C++ issue from other gfortran maintainers.
--
Janne Blomqvist
trunk?
2013-10-30 Janne Blomqvist
* configure.ac: Check presence of mkostemp.
* io/unix.c (set_close_on_exec): New function.
(tempfile_open): Use mkostemp and O_CLOEXEC if available, fallback
to calling set_close_on_exec.
(regular_file): Add O_CLOEXEC to flags if defined
.dg/nanelist_38.f90: Update test.
> * gfortran.dg/nanelist_84.f90: Update test.
--
Janne Blomqvist
fall back to heap allocation. E.g. something
like
void foo(..., size_t n) {
char tmp[BUFSIZE];
char *buf;
if (n <= BUFSIZE)
buf = tmp;
else
buf = xmalloc(n);
// Use buf
if (n > BUFSIZE)
free(buf);
}
This is roughly what std::string does with the new C++11 compatible
l
rtain platforms, too. Therefore why not going with the fixed size
> stack array and adding a check for possible overflow to it and be done?
Yes, I agree. That sounds like the best approach in this case.
--
Janne Blomqvist
On Sat, Feb 13, 2016 at 1:56 PM, Thomas Koenig wrote:
> Am 12.02.2016 um 11:42 schrieb Janne Blomqvist:
>>
>> On Fri, Feb 12, 2016 at 12:16 PM, Andre Vehreschild wrote:
>
>
>>> The proposed alloca() call
>>> has according to the documentation of libc
tested on x86_64-Linux. OK for trunk? any thoughts on back porting
> to 5 since it fixes a potentially bad pointer problem in push_char4?
Ok for both trunk and 5.
--
Janne Blomqvist
x86-64-gnu-linux.
> OK ?
Ok, thanks. (resending in plain text mode so that it doesn't bounce
from gcc-patches, gaah. Sorry.)
--
Janne Blomqvist
See also
http://austingroupbugs.net/view.php?id=411
I sent a request to the linux man pages project to improve the documentation.
--
Janne Blomqvist
Hi,
the attached patch fixes a null pointer crash on the mingw target (or
to be precise, targets where HAVE_WORKING_STAT is not defined).
Committed as obvious to trunk as r225788.
Richi, is this Ok for 5.2?
2015-07-14 Janne Blomqvist
PR libfortran/66861
* io/unix.c
Steven G. Kargl
>
> gfortran.dg/pr66864.f90: New test.
>
>
> --
> Steve
Ok, thanks.
--
Janne Blomqvist
ols. Your patch doesn't
make the situation worse per se, but if you're going to fix it, lets
do it properly.
Ok for GCC 7 stage1 with these changes. I don't think it's worth
putting it into GCC 6 at this point anymore, unless this is actually
fixing some bugs that are visible to users?
--
Janne Blomqvist
tions are
so minor that my opinion shouldn't carry that much weight on this
matter.
--
Janne Blomqvist
On Tue, Dec 1, 2015 at 6:51 PM, Bernhard Reutner-Fischer
wrote:
> On 1 December 2015 at 15:52, Janne Blomqvist
> wrote:
>> On Tue, Dec 1, 2015 at 2:54 PM, Bernhard Reutner-Fischer
>> wrote:
>>> These three function used a hardcoded buffer of 100 but would be
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
attached test cases? The only difference is in "module
> target_procs".
As previously mentioned, please use "stop N" instead of "call abort()".
--
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
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
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
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
?
> >
> > 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
:
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
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
*
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
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
//gcc.gnu.org/ml/gcc-patches/2019-11/msg00957.html .
--
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
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
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
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 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
ge-check is specified.
>
>
> 2019-11-24 Harald Anlauf
>
> PR fortran/92629
> * gfortran.dg/pr92629.f90: New testcase.
Ok, thanks.
--
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
Ok, though not being a global reviewer I can't
approve it.
--
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
nning out of file descriptors, or failure when running
in a container where /dev/urandom is not available.
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
2018-08-03 Janne Blomqvist
* configure.ac: Check for getentropy.
* intrinsics/random.c (getosrandom): Use getentropy if avai
On Fri, Aug 3, 2018 at 4:28 PM, Jakub Jelinek wrote:
> On Fri, Aug 03, 2018 at 04:19:03PM +0300, Janne Blomqvist wrote:
> > --- a/libgfortran/intrinsics/random.c
> > +++ b/libgfortran/intrinsics/random.c
> > @@ -309,12 +309,9 @@ getosrandom (void *buf, size_t buflen)
> &
On Wed, Jul 18, 2018 at 6:10 PM, Janne Blomqvist
wrote:
> On Wed, Jul 18, 2018 at 4:26 PM, Thomas König wrote:
>
>> Hi Kyrlll,
>>
>> > Am 18.07.2018 um 13:17 schrieb Kyrill Tkachov <
>> kyrylo.tkac...@foss.arm.com>:
>> >
>> > Thomas, J
ested compilers. In short, it's a mess. So lets just do
whatever is fastest, which is using MAX_EXPR/MIN_EXPR which are not
defined to do anything in particular if one of the operands is a NaN.
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
gcc/fortran/ChangeLog:
2018-08
PING
On Fri, Aug 3, 2018 at 5:05 PM, Janne Blomqvist
wrote:
> On Fri, Aug 3, 2018 at 4:28 PM, Jakub Jelinek wrote:
>
>> On Fri, Aug 03, 2018 at 04:19:03PM +0300, Janne Blomqvist wrote:
>> > --- a/libgfortran/intrinsics/random.c
>> > +++ b/libgfortran/intrinsics/r
On Mon, Aug 13, 2018 at 5:36 PM, Fritz Reese wrote:
> On Fri, Aug 3, 2018 at 9:19 AM Janne Blomqvist
> wrote:
> >
> > The getentropy function, found on Linux, OpenBSD, and recently also
> > FreeBSD, can be used to get random bytes to initialize the PRNG. It
> >
On Tue, Aug 14, 2018 at 11:18 PM, Rainer Orth
wrote:
> Hi Janne,
>
> > PING
> >
> > On Fri, Aug 3, 2018 at 5:05 PM, Janne Blomqvist <
> blomqvist.ja...@gmail.com>
> > wrote:
> >
> >> On Fri, Aug 3, 2018 at 4:28 PM, Jakub Jelinek wrote:
>
PING
On Fri, Aug 10, 2018 at 11:47 PM, Janne Blomqvist wrote:
> For floating point types, the question is what MAX(a, NaN) or MIN(a,
> NaN) should return (where "a" is a normal number). There are valid
> usecases for returning either one, but the Fortran standard doesn&#x
On Sun, Aug 19, 2018 at 10:47 PM Thomas Koenig
wrote:
> Hi Janne,
>
> > On Fri, Aug 10, 2018 at 11:47 PM, Janne Blomqvist <
> blomqvist.ja...@gmail.com
> >> wrote:
> >
> >> For floating point types, the question is what MAX(a, NaN) or MIN(a,
> >&g
h64.f90: Rename to...
> * gfortran.dg/max_expr.f90: ...this.
> * gfortran.dg/min_fmin_aarch64.f90: Rename to...
> * gfortran.dg/min_expr.f90: ...this.
>
Ok, thanks!
--
Janne Blomqvist
-pc-linux-gnu, Ok for trunk?
2018-08-22 Janne Blomqvist
* trans-intrinsic.c (gfc_conv_intrinsic_minmaxval): Delete
HONOR_SIGNED_ZEROS checks.
---
gcc/fortran/trans-intrinsic.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/gcc
= calloc (sizeof (transfer_queue), 1);
> + tq->arg = *arg;
>
> boom on OOM. XCNEW (transfer_queue), please.
>
xcalloc, rather.
--
Janne Blomqvist
On Fri, Aug 24, 2018 at 11:06 PM Bernd Edlinger
wrote:
> Hi!
>
>
> This is an alternative approach to handle overlength strings in the
> Fortran FE.
>
Hi,
can you explain a little more what the problem that this patch tries to
solve is? What is an "overlength" string?
--
Janne Blomqvist
On Tue, Nov 7, 2017 at 10:06 PM, Steve Kargl
wrote:
> On Tue, Nov 07, 2017 at 08:26:15PM +0200, Janne Blomqvist wrote:
>> Earlier GFortran used to redefine boolean_type_node, which in the rest
>> of the compiler means the C/C++ _Bool/bool type, to the Fortran
>> default log
On Wed, Nov 8, 2017 at 12:27 AM, Steve Kargl
wrote:
> On Tue, Nov 07, 2017 at 10:38:43PM +0200, Janne Blomqvist wrote:
>> On Tue, Nov 7, 2017 at 10:06 PM, Steve Kargl
>> wrote:
>> > On Tue, Nov 07, 2017 at 08:26:15PM +0200, Janne Blomqvist wrote:
>> &
On Wed, Nov 8, 2017 at 1:57 PM, Janne Blomqvist
wrote:
> On Wed, Nov 8, 2017 at 12:27 AM, Steve Kargl
> wrote:
>> On Tue, Nov 07, 2017 at 10:38:43PM +0200, Janne Blomqvist wrote:
>>> On Tue, Nov 7, 2017 at 10:06 PM, Steve Kargl
>>> wrote:
>>> > On Tu
if the second, how does it interact
with openmp parallelization?
--
Janne Blomqvist
On Fri, Nov 17, 2017 at 3:03 PM, Richard Biener wrote:
> On Fri, 17 Nov 2017, Janne Blomqvist wrote:
>
>> On Fri, Nov 17, 2017 at 11:13 AM, Richard Biener wrote:
>> > This patch changes the Fortran frontend to annotate DO CONCURRENT
>> > with parallel instead of ivd
This is a straightforward change that we can do now that the ABI has
been bumped (again!).
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
gcc/fortran/ChangeLog:
2017-11-17 Janne Blomqvist
PR fortran/44292
* ioparm.def (IOPARM): Make recl_in intio, and recl_out pintio
close(10, status="delete")
end program nextrec
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
gcc/fortran/ChangeLog:
2017-11-18 Janne Blomqvist
PR fortran/83036
* ioparm.def (IOPARM): Make nextrec a pintio.
libgfortran/ChangeLog:
2017-11-18 Janne Blomqvist
On Sat, Nov 18, 2017 at 12:34 PM, Janne Blomqvist
wrote:
> This is accomplished by making the NEXTREC specifier be a 8 byte
> integer where supported.
>
> I wasn't able to come up with a testcase that does not create a large
> file that could be added to the testsuite,
ards
>
> Thomas
Thanks, committed as r254915. Though I did notice some places in the
I/O library where we're incorrectly using the int type, so while this
patch takes care of the ABI issue large RECL's don't actually work in
all cases yet. I'm preparing a patch to fix the issues I discovered.
--
Janne Blomqvist
16. Since this changes the libgfortran ABI,
I wanted to get this in at the same time as the PR 44292 patch, so
people have to rebuild everything only once (yes, this is trunk, but
still). If somebody comes up with a way to test this without a huge
file, we can add such a testcase later.
--
Janne Blomqvist
ibgfortran/ChangeLog:
2017-11-18 Janne Blomqvist
* io/transfer.c (skip_record): Use gfc_offset to handle large
records.
(next_record_r): Likewise.
(sset): Likewise.
(next_record_w): Use gfc_offset/ptrdiff_t appropriately.
---
libgfortran/io/trans
3 was closing so I ran out of time.
There's apparently some other process for getting compile farm
accounts nowadays, and we have broken the ABI again for gcc 8, so
maybe I should dust off the patch and try again. Or what do you think?
--
Janne Blomqvist
xtern int newunit_alloc (void);
internal_proto(newunit_alloc);
+extern void newunit_free (int);
+internal_proto (newunit_free);
+
Since you're fixing the whitespace for finish_last_advance_record and
unit_truncate, you might as well do it right for newunit_free from the
start.. :)
Otherwise Ok, thanks for the patch!
--
Janne Blomqvist
describe
above.
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
gcc/fortran/ChangeLog:
2017-11-20 Janne Blomqvist
PR fortran/53796
* gfortran.texi: Remove mentions of GFORTRAN_DEFAULT_RECL.
libgfortran/ChangeLog:
2017-11-20 Janne Blomqvist
PR fortran/53796
* io
On Mon, Nov 20, 2017 at 8:29 PM, Thomas Koenig wrote:
> Am 20.11.2017 um 09:30 schrieb Janne Blomqvist:
>>
>> On Sun, Nov 19, 2017 at 11:11 PM, Thomas Koenig
>> wrote:
>>>
>>> There is one question regarding the ABI. Apparently, the string length
>>
ndian system, this prints
>
> memcmp : larger
> Direct comparison: smaller
Ooh, indeed.
> However, I just learned about the __BYTE_ORDER__ macro.
> We could use that (and in places where we currently have
> a runtime check, for example in replacing the big_endian
> global variable in libgfortran). But that is for another day.
Yup.
> So, attached is a new version of the patch. No update
> on the ChangeLog. OK for trunk?
Yup, just really fix the copyright and string length stuff first. Thanks!
--
Janne Blomqvist
Hi,
committed the following patch as r255045, pre-approved in the PR:
2017-11-22 Janne Blomqvist
PR libfortran/83070
* intrinsics/eoshift0.c (eoshift0): Fix -Wsign-compare warning by
making a_ex and r_ex index_type instead of size_t.
--- trunk/libgfortran/intrinsics
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
libgfortran/ChangeLog:
2017-11-22 Janne Blomqvist
* intrinsics/eoshift0.c (eoshift0): Make shift an index_type.
---
libgfortran/intrinsics/eoshift0.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libgfortran
By using the __BYTE_ORDER__ predefined macro we don't need the
determine_endianness function anymore.
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
libgfortran/ChangeLog:
2017-11-22 Janne Blomqvist
* io/inquire.c (inquire_via_unit): Use __BYTE_ORDER__ predefined
27;re testing.
Also thanks for opening a PR, I mentioned this in the ChangeLog and commit msg.
--
Janne Blomqvist
1 - 100 of 782 matches
Mail list logo
