Hello world,
I have just committed the attached patch as obvious and simple
after regression-testing. Will backport to gcc 15 soonish.
This fixes a 15/16 regression where the code was looking at
the typespec of the symbol which we don't set if there is
a RESULT clause.
Thanks to Harald for poin
Hi Paul,
Same remark as for PR120107! LGTM for both branches.
Committed both patches. Thanks for the reviews!
Best regards
Thomas
Hello world,
this fixes the other regression which crept in with gfortran.
Again, regression-tested, plus the local testing script is
attached.
Ok for trunk and gcc-15?
Best regards
Thomas
Fix explicit arrays with non-constant size for -fc-prototypes.
gcc/fortran/ChangeLog:
Hello world,
the attached patch fixes a 15/16 regression and should be fairly
self-explanatory.
Regarding testing: I'm not sure I am up to the task of hacking
dejagnu to do this. I am now running local tests, which is
better than nothing (I guess).
Regression-testing: Passed, though this does n
Am 10.05.25 um 20:32 schrieb Harald Anlauf:
Hi Thomas!
Am 10.05.25 um 11:42 schrieb Thomas Koenig:
This bug was another case of generating a formal arglist from
an actual one where we should not have done so. The fix is
straightforward: If we have resolved the formal arglist, we should
not
This bug was another case of generating a formal arglist from
an actual one where we should not have done so. The fix is
straightforward: If we have resolved the formal arglist, we should
not generare a new one.
OK for trunk and backport to gcc 15?
Best regards
Thomas
Do not genera
Hi Yuao,
first, good to have you on board!
As I am relatively new to submitting patches via mailing lists, I would
like to
send a very simple patch primarily to familiarize myself with the correct
procedure. I have reviewed the contribution guidelines on the GCC
website and
have tried to fol
Hi Jakub,
The following patch uses a variant of the character(kind=4) type
for unsigned(kind=4) and a distinct type based on character(kind=1)
type for unsigned(kind=1). The reason for the latter is that
unsigned_char_type_node has TYPE_STRING_FLAG set on it, so it has
DW_AT_encoding DW_ATE_uns
Hi Jakub,
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
15.2?
OK. Thanks for catching and fixing this!
Best regards
Thomas König
Hi Jakub,
While looking at PR120152, I have noticed that libgfortran.so doesn't
export 5 *m16* symbols I would have expected that should be exported.
This is caused by 2 issues, one filename was forgotten to be added in r15-4124
to i_maxloc1_c (guess because generated/maxloc1_16_i16.c was kept i
Hi Jakub,
The r15-4124-gc0002a675a92e76d change seems to have accidentally
dropped 5 sourcefiles from i_maxloc1_c, which resulted in dropping
15 GFORTRAN_8 symbols on x86_64 and 6 on i686.
The following patch adds it back, so that we export those symbols
again, fixing the ABI problem.
Bootstra
Hi Harald,
It appears that something is not right and generates wrong code with
the check enabled. Can you have another look?
The problem was indeed that generating a formal from an actual
arglist is a bad idea when classes are involved. Fixed in the
attached patch. I think it still makes s
Hi Harald,
It appears that something is not right and generates wrong code with
the check enabled. Can you have another look?
The problem was indeed that generating a formal from an actual
arglist is a bad idea when classes are involved. Fixed in the
attached patch. I think it still makes s
Hello world,
This patch fixes a case where too much was being checked with
-Wexternal-arguments-mismatch with a procedure pointer with an
unlimited polymorphic and an INTEGER argument which was inferred from
an actual argument.I also found some checks which can trigger false
positives, which this
Hello world,
I just committed the following patch after noticing that an option name
was wrong in the gcc15/changes.html file.
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index d851a744..b442b8d9 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@
Am 11.04.25 um 19:15 schrieb Harald Anlauf:
There is a duplicate "and and" here:
+ gfc_error ("Mismatch between subroutine and and "
+ "function at %L", &actual->where);
OK with this fixed.
Ah, yes :-)
Thanks for the patch!
Commit
Hello world,
the attached patch fixes an ICE by setting the typespec of a dummy
argument from a global function if known. plus setting the correct flag.
This also removes the corresponding assert. I'm not quite sure that the
code with the subroutine attribute can be reached, but I thought better
Hello Harald,
OK with the above addressed.
Both addressed and pushed in
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=737a5760bb24a0a945cc2c916ba452e3f0060c58
Thanks for the review (and for catching the miscellaneous
problems on the way)!
Best regards
Thomas
Hi Harald,
the attached patch contains a chunk changing resolve.cc
that is neither described in the suggested commit message,
and it fails to compile here:
../../gcc-trunk/gcc/fortran/resolve.cc: In function 'void
check_c_funptr_assign_interface(gfc_expr*, gfc_expr*)':
../../gcc-trunk/gcc/fortr
Hello world,
the attached patch handles dumping prototypes for C functions returning
function pointers. For the test case
MODULE test
USE, INTRINSIC :: ISO_C_BINDING
CONTAINS
FUNCTION lookup(idx) BIND(C)
type(C_FUNPTR) :: lookup
integer(C_INT), VALUE :: idx
lookup = C_FUNLO
Hi Paul,
It looks good to me. Thanks for the patch.
Thanks!
I just added one word, "modular", and committed it.
Best regards
Thomas
Hello world,
the attached patch, tested with "tidy -e", puts the two parts
mentioning UNSSIGNED into a single paragraph, mentions
extensions to -fc-prototypes and mentions -Wexternal-interface-mismatch.
Comments, suggestions for better wording?
If not, I'll probably commit tomorrow.
Best regar
Hi Harald,
The solution is to use the auxiliary parameter of gfc_traverse_expr
to control whether to descend into character length or not.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
Thanks for the patch!
Best regards
Thomas
Hi Tobias,
Attached is a long overdue bug fix, given that OpenMP's declare variant
is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021). (and
in C/C++ since r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp declare
simd' was already handled in the .mod file, 'declare variant' was no
Am 12.03.25 um 18:33 schrieb Thomas Koenig:
The test case should stay, but I will remove the dg-error directives.
Fix committed as obvious and simple as r15-8006 .
Thanks for the heads-up!
Best regards
Thomas
Hi Andre,
FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test for errors, line 8)
FAIL: gfortran.dg/binding_label_tests_26b.f90 -O (test for errors, line 9)
When I revert your patch and test again, above fails do not occur. Could you
please investigate, if I am right?
Jep, I missed
Hello world,
the attached patch makes sure that procedures from abstract
interfaces and dummy arguments are not put into the global
symbol table, and are not checked against global symbols.
Regression-tested. OK for trunk?
Best regards
Thomas
Abstract interfaces and dummy arguments ar
Am 11.03.25 um 10:22 schrieb Andre Vehreschild:
Hi Thomas,
looks good to me as well. Thanks for the patch.
Committed as r15-7964.
Thanks Harald and Andre!
Best regards
Thomas
Am 10.03.25 um 22:34 schrieb Harald Anlauf:
the patch looks basically fine but I cannot find the testcase.
You're right, here it is.
Best regards
Thomas
diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 20bf6e127ff..ef9c80147cc 100644
--- a/gcc/fortra
Hi Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
Thanks for the patch!
Best regards
Thomas
Hi Mikael,
_symbol *asym = a->expr->symtree->n.sym;
You may consider calling gfc_commit_symbol(s) instead at the end of the
function body. It might avoid leaking the old_symbol field in case the
function is called more than once or the symbol is already existing (not
completely clear wheth
Am 08.03.25 um 20:29 schrieb Steve Kargl:
On Sat, Mar 08, 2025 at 01:52:06PM +0100, Thomas Koenig wrote:
While looking at the code, I also saw that a member of gfc_symbol
introduced with my patch should be a bitfield of width 1.
OK for trunk?
OK (assuming a successful regression test run
Hello world,
the attached patch fixes an ICE regresseion where undo state was not
handled properly when generating formal from actual arguments, which
occurred under certain conditions with the newly introduced
-Wexternal-argument-mismatch option.
The fix is simple: When we are generating these
Hi Andre,
while the patch looks ok to me, why did you not choose to generate a "22.7.2
Variable-Length Parameter Lists"
https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Variable-Number-of-Arguments.html
when the arguments differ? Then its the callee responsibility to figure
stuff
Hello world,
this patch is a bit more complicated than originally envisioned.
The problem was that we were not handling external dummy arguments
with -fc-prototypes-external. In looking at this, I found that we
were not warning about external procedures with different argument
lists. This can a
Hi Andre,
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Looks good to me.
Thanks for the patch!
Best regards
Thomas
Am 18.02.25 um 16:00 schrieb Andre Vehreschild:
Hi Thomas,
This patch series (of necessity) introduces ABI changes. What will
happen with user code compiled against the old interface?
That depends on the library you are linking against. When using caf_single from
gfortran, then you will get
Am 17.02.25 um 05:53 schrieb Steve Kargl:
On Sun, Feb 16, 2025 at 09:36:20AM +0100, Thomas Koenig wrote:
this patch is a variation of Jakub's patch in the PR, which
avoids overflow on the mask used for exponentiation and
fixes unsigned HOST_WIDE_INT. I tried testing this on
a POWER ma
Hello world,
I just committed the attached patch as obvious, simple and having
no user impact), as r15-7575.
Previously, a dump looked like
attributes: (VARIABLE IMPLICIT-SAVE BIND(C) SAVE-IMPLICIT)
and now it is
attributes: (VARIABLE IMPLICIT-SAVE BIND(C))
Best regards
Thom
Hello world,
this patch is a variation of Jakub's patch in the PR, which
avoids overflow on the mask used for exponentiation and
fixes unsigned HOST_WIDE_INT. I tried testing this on
a POWER machine, but --with-build-config=bootstrap-ubsan
fails bootstrap there.
Regression-tested. OK for trunk?
Am 14.02.25 um 19:19 schrieb Jerry D:
I think this is good to commit. (all 7 parts)
I think so too, with one caveat...
Does anyone else have any comments?
This patch series (of necessity) introduces ABI changes. What will
happen with user code compiled against the old interface?
I guess
Hello Harald,
the attached patch fixes inconsistent handling of passing derived type
actual arguments to scalar dummies with VALUE,OPTIONAL attribute.
As suggested by Tobias, we should consistently pass a hidden boolean
flag that indicates the presence or absence of the actual, similar to
the ca
Hello world,
I just committed Andrew's patch from the PR as obvious as
r15-7557-gbf84e5e64662f8f0fdebfc0212e32bfca678f9eb .
Best regards
Thomas
Remove defunct web site for site of Fortran preprocessor.
gcc/fortran/ChangeLog:
PR fortran/118159
* invoke.
Hello world,
I just committed the fix for PR 11845 as obvious and simple, as
r15-7552-gfd00010ba21c04bddb20aef52f62de5636075067 .
Fix PR 118884, Lapack build failure.
The fix for PR 118845 introduced new checks, which in turn exposed
a case where the typespec information on a symbol generated s
Hi Jerry,
This is OK.
Pushed as r15-7509. Thanks for the review!
It would be good to get confirmation that the lapack builds
now. I use to be set up here to do that, but dont have it at the moment.
It checked the original test case, that passed. But yes, a Lapack
tester would be nice.
Hello world,
this was an interesting regression. It came from my recent
patch, where an assert was triggered because a procedure artificial
dummy argument generated for a global symbol did not have the
information if if was a function or a subroutine. Fixed by
adding the information in gfc_get_
Am 09.02.25 um 20:24 schrieb Jerry D:
"Type mismatch at %L when passing global function %qs "
"declared at %L (%s/%s)"
Committed as r15-7460-gd2ff1b78d70731db1b7adc1cbac7e44688828370 .
Thanks for the help with the wording!
Best regards
Thomas
Hello Harld,
the attached patch enhances the checking of pointer targets in structure
constructors to catch the following invalid cases (before we ICE :)
- different rank
- vector subscript of target
Regtested on x86_64-pc-linux-gnu. OK for mainline?
OK (and bordering on obvious).
Thanks fo
Am 08.02.25 um 22:46 schrieb Harald Anlauf:
looks good, just two minor comments:
+ actual_name = act_sym->name ? act_sym->name : act_sym->name;
Why not just
+ actual_name = act_sym->name;
?
That was a leftover from a previous commit.
+ gfc_error ("Type mismatch pa
Hello world,
this fixes a rather old PR from 2005, where a subroutine
could be passed and called as a function. This patch checks
for that, also for the reverse, and for wrong types of functions.
I expect that this will find a few bugs in dusty deck code...
Regression-tested. OK for trunk?
Be
Hi Jerry,
committed as r15-7345 .
Thanks for the review!
Best regards
Thomas
Hello world,
with the following patch to the failing test case
diff --git a/gcc/testsuite/gfortran.dg/unsigned_15.f90
b/gcc/testsuite/gfortran.dg/unsigned_15.f90
index da4ccd2dc17..80a7a54e380 100644
--- a/gcc/testsuite/gfortran.dg/unsigned_15.f90
+++ b/gcc/testsuite/gfortran.dg/unsigned_15.f9
Regression-tested on x86_64.
Seems I didn't look closely enough, I will check and resubmit.
Best regards
Thomas
Hi,
I sent https://gcc.gnu.org/pipermail/fortran/2025-February/061670.html
to gcc-patches also, as normal, but got back an e-mail that it
was too large. and that a moderator would look at it.
Maybe the limits can be increased a bit, sometimes patches can
be quite large, especially if they contai
Hello Harald,
the conversion of (unsigned) integers to decimal in output was designed
to be efficient up to INTEGER(kind=16) and did not handle values larger
than roughly (10^19 * 2^64).
The attached obvious patch fixes this.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
OK.
Thanks a
Am 16.01.25 um 01:50 schrieb Jerry D:
Yes I think this is OK, a definite improvement.
Committed as r15-6967.
Thanks for the review!
Best regards
Thomas
Am 09.01.25 um 14:36 schrieb Thomas Koenig:
Am 09.01.25 um 14:34 schrieb Thomas Koenig:
This patch fixes and reorganizes dumping C prototypes.
And here is the "five seconds later, I realized I had forgotten
to attach the patch" e-mail...
... with the original text:
Hello world,
Hi Harald,
there is one irregularity here (partial lower case instead of
consistently upper case:
+ if (attr->oacc_declare_copyin)
+ fputs (" OACC-DECLARE-copyin", dumpfile);
Otherwise this is OK.
Thanks for catching this!
Committed with the fix as
r15-6840-gf4fa0b7d493a4ba217d989d3df75
Hell world,
after finding that an attribute I was looking for was not
in the -fdump-fortran-original dump, I started putting in
attributes and didn't stop until I had them all (or so
I hope :-) It should be easier to read than looking at
the symbol attributes in a debugging session, and could
ho
-g40754a3b9bef83bf4da0675fcb378e8cd1675602 .
Best regards
Thomas
Author: Thomas Koenig
Date: Sun Jan 12 13:05:25 2025 +0100
Fix union member access for EXEC_INQUIRE.
gcc/fortran/ChangeLog:
PR fortran/118432
* frontend-passes.cc (doloop_code): Select correct member
Hi Harald,
Thanks for pointing this out! I've also added a few gcc_unreachable()
to prevent other potential false positives, see attached.
Just a couple of documentation nits: The documentation says INTEGER
or REAL only, but it also works (as an extension) for UNSIGNED. Also,
OUT_OF_RANGE is
Hello Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
I just started to run a bootstrap on cfarm120 (because it is
the only machine I can lay my hands on where I can run
"make -j128" without disturbing anybody :-) and I got
../../trunk/gcc/fortran/trans-intrinsic.cc: In function ‘
Hi Tobias,
Comments, remarks, suggestions?
I assume you regression-tested (you didn't say).
Otherwise, I regard the common Fortran code as obvious - and
the OpenMP part covered by my (co)maintainership.
Regarding the Fortran part:
- fndecl = build_decl (input_location,
+ fndecl = build_
Am 09.01.25 um 14:45 schrieb Andre Vehreschild:
You forgot to add the patch!
Sent two minutes later :-)
https://gcc.gnu.org/pipermail/fortran/2025-January/061540.html
Am 09.01.25 um 14:34 schrieb Thomas Koenig:
This patch fixes and reorganizes dumping C prototypes.
And here is the "five seconds later, I realized I had forgotten
to attach the patch" e-mail...
diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 8
Hello world,
This patch fixes and reorganizes dumping C prototypes. It makes the
following changes:
- BIND(C) types are now always output before any global symbols
- CFI_cdesc_t is issued for assumed shape and assumed rank arguments.
- BIND(C,NAME="...") entities were no
Am 08.01.25 um 19:18 schrieb Steve Kargl:
While working on f_c_string(), it never occurred to me
that the version number should have been bumped. Thanks
for the sleuthing you've done so far.
Same for me!
Best regards
Thomas
Hello world,
the attached patch does what it says in the ChangeLog entry.
Tested with "make dvi" and "make pdf".
OK for trunk?
Best regards
Thomas
Document unsigned constants in intrinsic modules.
gcc/fortran/ChangeLog:
* intrinsic.texi (ISO_FORTRAN_ENV): Also
Hello world,
I noticed that there is no mention of automatically generating
C prototypes and declarations in the relevant section of
the docs, "Interoperability with C". This patch remedies that.
OK for trunk?
Best regards
Thomas
gcc/fortran/ChangeLog:
* gfortran.texi: New su
Hello world,
a change in the section heading of the documentation broke a link
in gcc-15/changes.html, fixed with this patch.
Best regards
Thomas
Author: Thomas Koenig
Date: Fri Nov 29 07:19:36 2024 +0100
Correct link to unsigned integers for Fortran.
* htdocs/gcc
Hi Jerry,
I had originally created this patch in 2018 and we did not get back to
it. This results in more restrictive runtime behavior. I will go through
the front-end code with another patch to catch this at compile time.
Changelog and new test case. See attached patch.
OK for trunk
Yes, O
Hi Paul,
This is a particularly straightforward, going on 'obvious', patch. The
bug goes back to at least gcc-6.4.1.
OK for mainline and, after a week or two, to 13- and 14-branches?
As you say, this one is straightforward.
OK for trunk and as far back as you care to backport.
Thanks for
Hello world,
I just committed the attached documentatin patch as obvious,
in r15-5344-gbf00f117eb4b5527592029e39a3d79f2048745d8 .
Best regards
Thomas
Document that SELECT CASE works for unsigned.
gcc/fortran/ChangeLog:
* gfortran.texi: Document that SELECT CASE works for UNSI
Hello world,
Steve found a test case where unsigned constants were not handled
in a module. Single-line patch committed as obvious and simple,
r15-5341-g66096151afc6631f8f2a3458b154c5daa822b963 .
Best regards
Thomas
Handle unsigned constants for module I/O.
gcc/fortran/ChangeLog:
Am 10.11.24 um 21:54 schrieb Harald Anlauf:
Hi Thomas,
the patch is basically fine.
I am wondering if we should create a new helper function that is
the opposite of type_check ("type_cannot_be"), so that we avoid
redundant code at the source level. It may not be worth it yet,
so your choice.
Hello world,
the attached patch rejects UNSIGNED arguments for the COMPLEX
function, which is an extension. It also documents CMPLX,
INT and REAL as taking UNSIGNED arguments.
Regression-tested. OK for trunk?
Best regards
Thomas
gcc/fortran/ChangeLog:
* check.cc (gfc_check_c
Ping **(5./7.) ?
MASKR and MASKL are obvious candidates for unsigned, too; in the
previous version of the doc patch, I had promised that these would
take unsigned arguments in the future. What I had in mind was
they could take an unsigned argument and return an unsigned result.
Thinking about t
Hello world,
during testing, I noticed that parameters of the form
- mod(u1,u2) were rejected with an unknown type. The fix
is straightforward, but required an adjustment to another
test case.
Regression-tested. OK for trunk?
gcc/fortran/ChangeLog:
* resolve.cc (resolve_operator): Als
Hello world,
MASKR and MASKL are obvious candidates for unsigned, too; in the
previous version of the doc patch, I had promised that these would
take unsigned arguments in the future. What I had in mind was
they could take an unsigned argument and return an unsigned result.
Thinking about this a
Am 27.10.24 um 00:15 schrieb Iain Sandoe:
Tested on x86_64-darwin21 and linux, with makeinfo 6.7 pushed to trunk,
thanks
Thanks!
For the record, makeinfo 6.8 did not show this as an error.
Best regards
Thomas
Am 26.10.24 um 22:10 schrieb Iain Sandoe:
Pushed (4727bfb37701f3fef98a5f8b60dcd2daa82e8143).
This seems to have broken —enable-languages=all bootstrap with
/src-local/gcc-master/gcc/fortran/intrinsic.texi:39: node `Intrinsic
Procedures' lacks menu item for `UINT' despite being its Up target
Hi Steve,
OK for trunk?
OK, but see below.
Pushed (4727bfb37701f3fef98a5f8b60dcd2daa82e8143). Thanks for
the proof-reading!
Best regards
Thomas
Hello world,
the attached patch adds documentation for the long list of intrinsics
which take UNSIGNED arguments. Checked with "make html", "make pdf" and
"make info".
gcc/fortran/ChangeLog:
* gfortran.texi: Correct reference to make clear that UNSIGNED
will not be part of F202Y
Hello world,
I have just committed the attached patch as obvious - just recognize
that an UNSIGNED is an error in a complex part.
Fix an ICE with UNSIGNED in match_sym_complex_part.
gcc/fortran/ChangeLog:
PR fortran/117225
* primary.cc (match_sym_complex_part): An UNSIGNED in
Hello world,
The attached patch fixes an ICE when an UNSIGNED-specific constant
is used from ISO_FORTRAN_ENV. The error message is not particularly
great, it is
Error: Unsigned: The symbol 'uint32', referenced at (1), is not in the
selected standard
but it is better than an ICE.
OK for trun
Hi Jerry,
the attached patch implements the constants for UNSIGNED for
ISO_FORTRAN_ENV and ISO_C_BINDING. With this, the implementation
of UNSIGNED for gfortran should be complete, modulo bugs, of course.
OK for trunk?
Looks good to go Thomas.
Committed, thanks for the review!
Actually, t
Hello world,
the attached patch implements the constants for UNSIGNED for
ISO_FORTRAN_ENV and ISO_C_BINDING. With this, the implementation
of UNSIGNED for gfortran should be complete, modulo bugs, of course.
OK for trunk?
Best regards
Thomas
gcc/fortran/ChangeLog:
* dump-par
Hi Tobias,
This unifies the two locus to location_t conversion functions, preparing
for some changes I want to do later.
In principle, I had the patch this morning; however, the assert is now
exercised more often than before - and it triggered rather unexpected
when running the testsuite.
Am 11.10.24 um 18:00 schrieb Thomas Koenig:
Hello world,
the attached patch creates an unsigned "standard" for the
gfc_option.allow_std field.
One of the main reason why people want UNSIGNED for Fortran is
interfacing for C.
This is a preparation for further work on the ISO
Hello world,
the attached patch creates an unsigned "standard" for the
gfc_option.allow_std field.
One of the main reason why people want UNSIGNED for Fortran is
interfacing for C.
This is a preparation for further work on the ISO_C_BINDING constants.
That, we do via iso-c-binding.def , whose l
] Implement maxloc and minloc for unsigned
Datum: Fri, 4 Oct 2024 09:54:37 +0200
Von: Thomas Koenig
An: fort...@gcc.gnu.org , gcc-patches
Hello world,
please find attached the patch for implementing MAXLOC and MINLOC
for unsigned.
The patch is rather lengthy, but mostly due to combinatorial
.texi: Include FINDLOC in unsigned documentation.
* iresolve.cc (gfc_resolve_findloc): Use INTEGER version
for UNSIGNED.
gcc/testsuite/ChangeLog:
* gfortran.dg/unsigned_33.f90: New test.From 864071a00f886ae2115d6dfa5d286c84e67360f6 Mon Sep 17 00:00:00 2001
From: Thomas Koenig
00:00:00 2001
From: Thomas Koenig
Date: Thu, 26 Sep 2024 21:46:55 +0200
Subject: [PATCH] Implement CSHIFT and EOSHIFT for unsigned.
gcc/fortran/ChangeLog:
* check.cc (gfc_check_eoshift): Handle BT_UNSIGNED.
* simplify.cc (gfc_simplify_eoshift): Likewise.
* gfortran.texi: Document CSHIFT and
Hi Mikael,
Now for the remaining intrinsics (FINDLOC, MAXLOC,
MINLOC, MAXVAL, MINVAL, CSHIFT and EOSHIFT still missing).
I have one patch series touching (inline) MINLOC and MAXLOC to post in
the coming days. Could you please keep away from them for one more week
or two?
Looking at the pre
after that, C interop, one of the main reasons this
was requested.
I have also committed, right now, a fix for the failure of
unsigned_25.f90 on 32-bit systems as obvious.
Best regards
Thomas
Author: Thomas Koenig
Date: Wed Sep 25 18:51:48 2024 +0200
Fix testsuite failure on 32
Am 23.09.24 um 11:02 schrieb Paul Richard Thomas:
Hi All,
The moment I saw the DIN4 proposal for "Generic processing of assumed
rank objects", I thought that this was a highly intuitive and
implementable proposal. I implemented a test version in June and had
some correspondence with Reinhold
Hello Andre and everybody else?
Any more comments on the matmul patch? The other ones depend on
it, so I would like to commit (unless there are further
questions, of course).
Best regards
Thomas
22:15 +0200
Thomas Koenig wrote:
This patch adds random number support for UNSIGNED, plus fixes
two bugs, with array I/O where the type used to be set to BT_INTEGER,
and for division with the divisor being a constant.
Again, depends on prevous submissions.
OK for trunk?
gcc/fortran/Chan
Am 19.09.24 um 11:55 schrieb Andre Vehreschild:
Hi Thomas,
thanks for the patch. I have one proposal/question and one missing verb (IMO).
Else the patch looks fine to me. Ok for trunk.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 829ab00c665..e5ffe67 100644
---
This patch adds random number support for UNSIGNED, plus fixes
two bugs, with array I/O where the type used to be set to BT_INTEGER,
and for division with the divisor being a constant.
Again, depends on prevous submissions.
OK for trunk?
gcc/fortran/ChangeLog:
* check.cc (gfc_check_ran
1 - 100 of 1104 matches
Mail list logo
