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
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
Hi Steve,
I'll note that match.cc(gfc_match_type_spec) has to deal with
REAL as a possible intrinsic function. See the comment
/* REAL is a real pain because it can be a type, intrinsic subprogram,
or list item in a type-list of an OpenMP reduction clause. Need to
differentiate
Hello world,
Peter Klausler noted in the discussion on github that Sun Fortran,
from which the UNSIGNED proposal was drawn, used UNSIGNED instead
of UINT for conversion of other types to UNSIGNED
(see https://docs.oracle.com/cd/E19205-01/819-5263/aevnb/index.html ).
Peter suggested that it would
Am 19.10.24 um 12:12 schrieb FX Coudert:
Hi Thomas,
Thanks for the clarification. I really hope that it makes it into the standard, > I do not disagree that it is useful, I just really wish we don’t have
to maintain> long-term a lot of nonstandard (or worse,
standard-incompatible) extensions.
Am 19.10.24 um 10:40 schrieb FX Coudert:
Hi,
As UNSIGNED has been booted off the F202Y list, I think calling it
an extension at this time is fair.
Looks good to me. And yes, calling it an extension is fair.
I apologise, I had missed this piece of information. If UNSIGNED is > not on
track
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
Am 18.10.24 um 19:11 schrieb Thomas Koenig:
Hello world,
I am thinking how to add UNSIGNED to the documentation of the
intrinsics. Taking BGT, the alphabetically first one, one
could
... send the e-mail too early.
What I had in mind was something like
@node BGT
@section @code{BGT
Hello world,
I am thinking how to add UNSIGNED to the documentation of the
intrinsics. Taking BGT, the alphabetically first one, one
could write
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
Hi John,
I would like to report a problem I have identified with using “call
omp_set_num_threads (n)”, which has appeared when on Windows 10 using
Gfortran version 11.3.0, (12.3.0 and 14.1.0).
Prior versions ( 9.2.0, 10.2.0 and 11.1.0 run to completion.
The reproducer program below does not
Am 05.10.24 um 22:52 schrieb Thomas Koenig:
Hi Jerry,
I see all the generated files in the patch, but I do not see the M4
macro or other mechanism which generated these. Was this in a
previous submission that I missed?
The "magic" in this case is mentioning them in Makef
Hi Jerry,
I see all the generated files in the patch, but I do not see the M4
macro or other mechanism which generated these. Was this in a previous
submission that I missed?
The "magic" in this case is mentioning them in Makefile.am and
(regenerated) in Makefile.in.
The rest is done by the
1 - 100 of 369 matches
Mail list logo
