Hi Lipeng,
Sure, as your comments, in the patch V6, I added 3 test cases with
OpenMP to test different cases in concurrency respectively:
1. find and create unit very frequently to stress read lock and write lock.
2. only access the unit which exist in cache to stress read lock.
3. access the sa
Hi Rimvydas,
Documentation part.
The makeinfo gcc/fortran/gfortran.texi does not seem to have any new warnings.
Thanks for your work on this!
I think this also desevers a mention in changes.html. Here is something
that I came up with. OK? Or does anybody have suggestions for a better
wordin
Replying to myself...
I think this also desevers a mention in changes.html. Here is something
that I came up with. OK? Or does anybody have suggestions for a better
wording?
Or maybe this is better:
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 4b83037a..d232f
Hi Paul and Harald,
'from' is slightly better but either will be understood.
Committed with "from" (which I managed to spell correctly on
the second try).
Best regards
Thomas
Am 18.04.24 um 01:27 schrieb Mark Wielaard:
We also should make sure that all generated files (either in git or in
the release/snapshot tar balls) can be reliably and reproducibly
regenerated. This also helps the (pre-commit) CI buildbots. We already
have the autoregen bots for gcc and binutils-g
Hi everybody,
now that a proposal for unsigned number inclusion in Fortran has
passed the J3 hurdle, https://j3-fortran.org/doc/year/24/24-116.txt ,
I thought I would put my working hours where my mouth is and try
my hand at a testbed implementation for gfortran. I am still
grateful to Reinhold
Am 23.07.24 um 08:09 schrieb Paul Richard Thomas:
Hi Thomas,
Welcome back!
I was going to propose that we introduce -std=f2028 and to allow
proposed features to be run only if that option is selected; ie. not by
default or -std=gnu. gfortran.dg should have an f2028 directory as well.
That m
Hi Jerry,
I also developed the attached test case. This does reproduce the error.
I will update the log entry to reflect this test case.
OK for mainline?
OK, and thanks for the patch!
Best regards
Thomas
Hi,
for the fortran-unsigned branch, I would like to be able to run all
existing Fortran tests also with -funsigned, to make sure the option
does not break anything on existing code.
Question is: How?
I came as far as
$ make check-fortran RUNTESTFLAGS="--target_board=unix/-funsigned"
but that
Hi Andrew,
Any other possibilites?
Yes you could add it into the list of Torture options that
gfortran-dg-runtest uses.
Something like:
```
diff --git a/gcc/testsuite/lib/gfortran-dg.exp
b/gcc/testsuite/lib/gfortran-dg.exp
index fcba95dc396..0589d507382 100644
--- a/gcc/testsuite/lib/gfortran-d
Am 29.07.24 um 22:14 schrieb Thomas Schwinge:
By the way: I did see your recent announcement; wow -- Fortran finally
getting an UNSIGNED type! 🙂
Yep, at lest J3 accepted a propoasl.
I would like to be able to run all
existing Fortran tests also with -funsigned, to make sure the option
does
Hi Mikael,
+ gcc_assert (backexpr->expr_type == EXPR_VARIABLE);
drop it, downgrade to checking, or is it worth?
Whether it is worth it, I don't know; it's protecting the access to
backexpr->symtree a few lines down, idependently of the implementation
of maybe_absent_optional_variable.
Hi Mikael and Harald,
- inline expansion is inhibited at -Os. But wouldn't it be good if
we make this expansion also dependent on -ffrontend-optimize?
(This was the case for rank-1 before your patch).
The original idea was to have -ffrontend-optimize as a check if anything
went wrong wi
Am 08.08.24 um 11:09 schrieb Mikael Morin:
As we are not planning to remove the library implementation (-Os!),
this is also the best way to compare library to inline code.
This makes perfect sense, but why reuse the -ffrontend-optimize option?
The manual describes it as:
This option performs f
Hi,
I have managed to bring the fortran-unsigned branch into a state where
it can no longer be rebased. When I do a
$ git rebase master
I get
...
warning: skipped previously applied commit a6399bb27b3
hint: use --reapply-cherry-picks to include skipped commits
hint: Disable this message with "
Hi Dimitar,
On Fri, Aug 09, 2024 at 08:00:42PM +0200, Thomas Koenig via Gcc wrote:
Hi,
I have managed to bring the fortran-unsigned branch into a state where
it can no longer be rebased. When I do a
$ git rebase master
It's unknown what is the state of your local master branch. So I
Am 09.08.24 um 21:17 schrieb Dimitar Dimitrov:
I assume you reset your local branch? The branch on the server does not
seem to be affected. I suggest to rebase the remote branch using
another local branch. Example:
# Just in case, see which is your old local branch.
$ git branch
#
Am 09.08.24 um 21:57 schrieb Dimitar Dimitrov:
You are redoing the rebase again. So it is expected to get the same
warnings.
I need to get the changes from master into my branch, or else
things will not compile due to changes in master. But it seems
that this is no longer possible, thanks to
Hi Toon,
So why do "we" want to use rebase ? Wouldn't it be more "natural" to
merge master into your branch, and work from that ?
If you can tell me how to do this, sure :-)
Best regards
Thomas
Am 10.08.24 um 10:17 schrieb Thomas Schwinge:
Hi!
I'm not sure I understand what actually the issue is, but:
On 2024-08-09T20:00:42+0200, Thomas Koenig wrote:
I have managed to bring the fortran-unsigned branch into a state where
First, I see that the upstream devel/fortran_unsigned b
Hi Andre,
attached patch fixes a regression introduced by my previous patch on handling
_vptr's more consistently. The patch gets the _vptr only of a derived or
class type now and not of every type.
Regression tested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
OK (and looks obviou
Hi,
when working on the first unsigned array intrinsics, I noticed
something strange. With maintainer mode enabled, and the usual-style
patch to include the generated functions (see below), I found that the
files were regenerated in the build dir, under
x86_64-pc-linux-gnu/libgfortran/generated
Am 17.08.24 um 13:20 schrieb Thomas Koenig:
when working on the first unsigned array intrinsics, I noticed
something strange. With maintainer mode enabled, and the usual-style
patch to include the generated functions (see below), I found that the
files were regenerated in the build dir, under
Am 17.08.24 um 13:20 schrieb Thomas Koenig:
--- a/libgfortran/m4/types.m4
+++ b/libgfortran/m4/types.m4
Yes, I now know that this is the wrong place (we could remove this, I
think :-)
Hi John,
Thank you Damian. Tried the first suggestion. It said I already had
gfortran; it turned out to be version 13. Tried the second suggestion.
My system has not heard of git. Managed to find gcc-14.2.0.tar so I am
now struggling to do something with that.
Assuming you have the top level
Steve,
On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote:
this version of the patch includes DOT_PRODUCT, MATMUL and quite
a few improvements for simplification.
Thomas,
Your updated patch applied cleanly on top-of-tree gcc.
Bootstrap and regression testing on amd64-*-freebsd
Hi John,
/usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No
such file or directory
27 | #include
I'm not sure what system you are running. On my Ubuntu system,
which is Debian-based, you can search for the package that provides a
file with
$ dpkg -S libc-header-start.
Hi Harald,
the attached patch downgrades this feature from a GNU extension (silent
per default) to a legacy extension (warning by default).
The feature is tested in at least 4 gfortran testcases. I adjusted
the pattern of one of these tests to check for the downgrade.
Regtested on x86_64-pc-l
Ping (a little bit)?
With another weekend coming up, I would have some time to
work on incorporating any feedback, or on putting in
more intrinsics.
Best regards
Thomas
Am 06.09.24 um 20:15 schrieb Steve Kargl:
+Generally, unsigned integers are only permitted as data in intrinsics.
Does the word 'intrinsics' apply to 'intrinsic operators'
or 'intrinsic subprograms' or both? This might benefit from
a big of wordiness.
You're right, that wasn't clear at all.
Am 06.09.24 um 20:58 schrieb Steve Kargl:
Your testcases are all free source form. In fixed
form, gfortran would need to deal with 'u = 1 2 3 4 u _8'
I don't have the patch in my tree at the moment,
it isn't clear to me if the matcher for an unsigned
constant is prepared to deal with space betwe
Steve, Paul,
Thanks for doing the review. If it's good enough for you, it is
certainly good enough.
The first version is committed, thanks!
Next on the menu: Matmul (plus whatever bugs turn up when
implementing it :)
Best regards
Thomas
Hello world,
like the subject says. The patch is gzipped because it is large;
it contains multiple MATMUL library implementations.
OK for trunk?
Implement MATMUL and DOT_PRODUCT for unsgigned.
gcc/fortran/ChangeLog:
* arith.cc (gfc_arith_uminus): Fix warning.
(gfc_arith_minus)
Am 09.09.24 um 09:19 schrieb Richard Biener:
Is the library implementation in any way different from the signed
one? Iff only
multiplication and addition/subtraction are involved the unsigned implementation
could implement both variants (the signed one would eventually cause
undefinedness
with r
Am 09.09.24 um 20:01 schrieb Richard Biener:
But it will require some ugly m4 hackery... I'll take a look if
I can make it work.
> I meant you shouldn’t need new library entry points for unsigned
> but simply call the signed ones (and switch the signed implementation
> to use unsigned arithmet
Hi Paul,
This correspondence touches on something that I was going to raise - how
do we incorporate experimental F202Y features?
I think your suggestion of -std=f202y is good, we can then make
-funsigned depend on that.
Hmm... one thing. I just read
https://wg5-fortran.org/N2201-N2250/N223
Hello world,
I just pushed Steve's patch for module support to trunk as obvious, as
https://gcc.gnu.org/g:2847a541c1f19b67ae84be8d0f6dc8e1f9371d16 .
Best regards
Thomas
gcc/fortran/ChangeLog:
* module.cc (bt_types): Add BT_UNSIGNED.
gcc/testsuite/ChangeLog:
* gfortra
Author: Thomas Koenig
Date: Fri Sep 13 07:47:24 2024 +0200
Fix endianness issue on unsigned_21.f90.
gcc/testsuite/ChangeLog:
PR fortran/116653
* gfortran.dg/unsigned_21.f90:
* gfortran.dg/unsigned_21_be.f90: New test.
diff --git a/gcc/testsuite
Hello world,
this implements SUM and PRODUCT for UNSIGNED. This is actually
missing from 24-116.txt, but that is due to an oversight.
This patch is on top of
https://gcc.gnu.org/pipermail/fortran/2024-September/060975.html
and uses the same method suggested by Richard: Use unsigned for the
dat
As Jerry wrote (thanks!), this was missing the attached patch.
Best regards
Thomasdiff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 829ab00c665..e5ffe67 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -2788,7 +2788,7 @@ As of now, the
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.
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
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
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 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
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
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
Hello world,
I am thinking how to add UNSIGNED to the documentation of the
intrinsics. Taking BGT, the alphabetically first one, one
could write
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
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.
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
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
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
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
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 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.
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
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,
OK for trunk?
OK, but see below.
Pushed (4727bfb37701f3fef98a5f8b60dcd2daa82e8143). Thanks for
the proof-reading!
Best regards
Thomas
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
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
OK for trunk?
This is based on the previous submissions. Again, this does not
generate a new library version; rather it re-uses the signed
integer version already present in the library.
OK for trunk?
Previous submissions (without which this will not work):
https://gcc.gnu.org/pipermail/fortra
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
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
[For the fortran people: Discussion on gcc@]
Just a general remark.
There are people, such as myself, who regularly mess up
their git repositories because they have no mental model
of what git is doing (case in point: The Fortran unsigned
branch, which I managed to put into an unrepairable state
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
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
.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
Am 28.09.24 um 21:14 schrieb Steve Kargl:
On Sat, Sep 28, 2024 at 08:32:00PM +0200, Thomas Koenig wrote:
Hello world,
here's another small patch for FINDLOC for unsigned.
OK for trunk?
OK. Other than UNSIGNED being a new experimental feature,
this patch almost qualifies as &qu
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
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
Am 18.09.24 um 12:31 schrieb Andre Vehreschild:
Regtested ok on x86_64-pc-linux-gnu / F39. Ok for mainline?
OK.
Thanks for the patch!
Best regards
Thomas
Hi Andre,
Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Extremely minor nit: In the commit message and ChangeLog entry,
Build a derived type component's type only, when it is not already being
build and the component uses pointer semantics.
I believe that should be "being
Hi Andre,
+ if (gfc_option.allow_std & GFC_STD_F2003)
+ gfc_error ("%qs argument of %qs intrinsic at %L must be INTEGER "
+ "or REAL or CHARACTER",
I had expected UNSIGNED in this enumeration, too.
+ gfc_current_intrinsic_arg[n]->name
Hi Andre,
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index 66a3635404a..a214b8bc1b3 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -711,17 +711,9 @@ gfc_arith_uminus (gfc_expr *op1, gfc_expr **resultp)
case BT_UNSIGNED:
{
if (pedantic)
-
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
---
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
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,
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
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
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 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,
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
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
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
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
Hi Jerry,
committed as r15-7345 .
Thanks for the review!
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 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
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
Regression-tested on x86_64.
Seems I didn't look closely enough, I will check and resubmit.
Best regards
Thomas
1 - 100 of 369 matches
Mail list logo
