Hi Andre,
attached patch fixes a missing substring ref on a saved allocatable string.
The issue seems to be, that the variable is declared to be a character pointer
and not a character array. When using the latter (why not), it works as
expected and does not produce any regressions.
Regtests o
Hi Jerry,
The attached patch fixes a latent issue where we were saving a parsed
and checked format string that had a missing comma. This resulted in the
correct error on the first use of the string, but a missed error on
subsequent uses of the string.
New test case provided.
Regression test
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
Hi Harald,
Hi Thomas,
On 5/11/25 10:34, Thomas Koenig via Gcc wrote:
As PR120139 has shown (again), it is too easy to create regressions
for dumping C prototypes from Fortran. The main problem
is that there is currently no test in the testsuite.
for something along this variant you can
As PR120139 has shown (again), it is too easy to create regressions
for dumping C prototypes from Fortran. The main problem
is that there is currently no test in the testsuite.
So, what to do? I see several possibilities:
1a) Change the relevant options so that they optionally
create a file (s
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 Harald,
% gfc-16 gcc/testsuite/gfortran.dg/proc_ptr_52.f90 -Wexternal-argument-
mismatch && ./a.out
STOP 1
It appears that something is not right and generates wrong code with
the check enabled. Can you have another look?
I see that too, good catch!
Seems like generating formal argu
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
@@
Hi Jerry,
The attached patch fixes this bug by adding checks for negative unit
numbers in CLOSE and OPEN statements.
Regression tested on x86_64_linux_gnu.
OK for trunk
OK. Thanks for the patch!
Best regards
Thomas
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
Am 21.03.25 um 15:34 schrieb Paul Richard Thomas:
I am reasonably familiar with the mess that is gfc_conv_procedure_call :-)
It's only 2141 lines in a single function and eight levels of
conditions / loops!
I do not see what could possibly go wrong :-)
Best regards
Thomas
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,
By the way, the standard just specifies integer for 'dim' in reduce,
which I take to mean it should be default_integer_kind.
Hmm... I'm not sure that this is actually the case; I believe it
can actually be any integer kind, although anything larger than
default integer would be kind o
Hi Paul,
It looks good to me. Thanks for the patch.
Thanks!
I just added one word, "modular", and committed it.
Best regards
Thomas
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
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 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
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
Hi Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Looks good to me.
Thanks for the patch!
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
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
Dear Chenlu,
Thank you for your interest!
I have forwarded your e-mail to the gfortran mailing list, where
discussion of gfortran takes place.
Best regards
Thomas
Weitergeleitete Nachricht
Betreff: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran
DO
homas
commit 9f5b508bc5c16ae11ea385f6031487a518f62c8f (HEAD -> master)
Author: Thomas Koenig
Date: Sun Mar 9 19:35:06 2025 +0100
Use gfc_commit_symbol() to remove UNDO status instead of new function.
This is a cleaner version, removing an unneeded function and
making sure that n
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 10.02.25 um 23:44 schrieb Thomas Schwinge:
Indeed 'need-language-lawyering' (or similar) would've been my suggestion
for the new keyword, but I resisted the color-of-bike-shed opportunity.
My fear would be that people would misspell laywer :-)
I've added needs-stdcheck and will go through a
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
Am 10.02.25 um 21:05 schrieb David Malcolm:
FWIW my first thought for "interp" was that we gaining an interpreter
(there are some in the libgccjit test suite).
It was motivated by Fortran interps, which are interpretation requrests.
But I think that Richard's suggestion, neeeds-stdcheck, makes
Am 10.02.25 um 08:43 schrieb Richard Biener:
We have need-bisection and other need-, so iff then maybe a need-stdchk for
cases compliance is unclear?
That sounds very good to me; if there are no objections, I will create
this in a day or so.
The fact that a testcase is (non-)compliant is
also
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
Hello world,
looking at a few Fortran bug reports, I found some cases where
it was not clear if the program in question was standard-conforming
or not. I would propose to add a keyword for that, tentatively
called "interp".
Comments? Suggestions for a different name? Should I just go ahead
and
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
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 Manfred,
@@ -868,6 +870,8 @@ show_attr (symbol_attribute *attr, const char * module)
fputs (" IN-NAMELIST", dumpfile);
if (attr->in_common)
fputs (" IN-COMMON", dumpfile);
+ if (attr->in_equivalence)
+fputs (" IN_EQUIVALENDE", dumpfile);
s/IN_/IN-/
s/ENDE/ENCE/
Two typ
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
Am 11.01.25 um 18:32 schrieb Jerry D:
The attached patch is the latest clean build and test run I can come up
with. I completely cannot understand why moving the forall_iterator from
the sub-structure 'concur' back to where it was at the 'ext' sub-
structure of typedef struct gfc_code. 'ext' is
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_
Hi Jerry,
Is anyone else seeing this?
Running /home/jerry/dev/gcc14/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/bind-c-contiguous-1.f90 -O3 -fomit-frame-pointer -
funroll-loops -fpeel-loops -ftracer -finline-functions (internal
compiler error: Segmentation fault)
FAIL: gfortran.d
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
Am 07.01.25 um 17:52 schrieb Jakub Jelinek via Gcc:
But the compiler does in every ICE message in which -freport-bug isn't
enabled.
It seems that -freport-bug does nothing for Fortran, or at least the
Fortran front end (which why it was unfamiliar to me). Grabbing a
random ICE off bugzilla, sli
Hi Steve,
On Tue, Jan 07, 2025 at 03:28:31PM +0100, Thomas Koenig wrote:
Hello world,
the attached patch does what it says in the ChangeLog entry.
Tested with "make dvi" and "make pdf".
OK for trunk?
OK.
Committed. Thanks!
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
Am 03.01.25 um 14:32 schrieb Sam James:
Thomas Koenig writes:
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?
Be
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
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
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,
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 13.11.24 um 15:55 schrieb Toon Moene:
Since the Fortran 95 Standard it does (in the current Standard: 7.4.3.2
Real type):
The real type includes a zero value. Processors that distinguish between
positive and negative zeros shall treat them as mathematically equivalent
• in all intrinsic
Hello world,
J3, the US Fortran standards committee, has passed
https://j3-fortran.org/doc/year/24/24-179.txt
which states (with a bit of an overabundance of
clarity) that, in Fortran, it is possible special-case
complex multiplication when one of the numbers is known
to have a zero component, fo
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
1 - 100 of 389 matches
Mail list logo
