On 4/12/25 01:10, Paul Richard Thomas wrote:
Hi All,
Now that the reduce intrinsic seems to be OK on all platforms, I thought
that it was time to catch up with the documentation.
The attached produces good .html without any additional warnings or
errors using texi2any and ~/share/info/gfortr
up and
formatting problems in there as well. :-(
-Sandra
From 3cfe5832d049c55cacc5f73431a4a14e97b2659f Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Sun, 2 Mar 2025 01:43:26 +
Subject: [PATCH] Fortran: Small fixes in intrinsic.texi.
gcc/fortran/ChangeLog
* intrinsic.texi: Fix
nopsis
in the library function documentation with line breaks in random
places, places where using a table for formatting would greatly
improve readability (e.g. _gfortran_set_options), etc. But those are
separate from the issue addressed by this patch series and would need
to be addressed individually by hand.
CTIVE (but the latter
only if the error was not already diagnosed in BEGIN/END METADIRECTIVE).
-SandraFrom 5753f459444fa61a93d23325cd59467dc1838eef Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Sat, 8 Feb 2025 17:44:55 +
Subject: [PATCH] [PATCH] OpenMP: Improve Fortran metadire
The Fortran front end was giving an ICE instead of a user-friendly
diagnostic when variants of a metadirective variant had different
statement associations. The particular test case reported in the issue
also involved invalid placement of the "omp end metadirective" which
was not being diagnosed e
On 1/2/25 20:22, Maciej W. Rozycki wrote:
On Tue, 31 Dec 2024, Sandra Loosemore wrote:
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index d11d37761d9..b47180126ca 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -1577,7 +1577,7 @@ if @var{Y
gcc/fortran/ChangeLog
* gfortran.texi (Function ABI Documentation): Make menu ordering
consistent with subsection ordering.
---
gcc/fortran/gfortran.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index
In English usage, "that" introduces a restrictive clause while "which"
introduces a non-restrictive or descriptive clause. "That" is almost
never preceded by a comma while "which" often is. The Fortran manual
had many instances where these uses were reversed, or where a comma
was used with "that"
Continuing a series of patches to tidy the Fortran manual, this
installment fixes problems with inappropriate use of future tense and
adds some missing markup I noticed in passing.
gcc/fortran/ChangeLog
* intrinsic.texi: Grammar and markup fixes throughout
the file.
---
gcc/fortra
Tobias pointed out that I forgot to CC the fortran mailing list about
these patches to the gfortran manual that I pushed just before the
holidays, while wearing my documentation maintainer hat:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672151.html
https://gcc.gnu.org/pipermail/gcc
On 6/6/24 06:06, Tobias Burnus wrote:
Hi Thomas,
regarding the commit r15-1070-g3a4775d4403f2e /
https://gcc.gnu.org/r15-1070
First, thanks for adding I/O support to nvptx offloading.
I have a wording nit, to be confirmed by a native speaker:
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgom
On 5/19/24 02:01, Tobias Burnus wrote:
I noticed that gfortran's coarray support did not link to the
http://www.opencoarrays.org/ >
[snip]
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 40e8e4a7cdd..78a2910b8d8 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.
On 3/20/23 14:05, Harald Anlauf via Gcc-patches wrote:
Dear all,
as reported, the implicit documentation of -funderscoring, which
is found under -fno-underscoring, has gone sideways long time ago.
The attached patch should fix it.
OK for mainline, or did I miss something?
This is OK.
-Sandra
On 3/25/22 20:03, Sandra Loosemore wrote:
I've got another patch forthcoming (stage 1 material) that adds some new
diagnostics for non-rectangular loops during gimplification of OMP
nodes. When I was working on that, I discovered that the Fortran front
end wasn't attachin
On 3/25/22 20:02, Sandra Loosemore wrote:
I ran into this bug in the handling of clauses on the combined "masked
taskloop" OMP directive when I was working on something else. The fix
turned out to be a 1-liner. OK for trunk?
Ping! This one's borderline obvious and would be
pect to the
not-yet-implemented TILE construct.
Is this OK for stage 1 when the time comes?
-Sandracommit c46a79a9841b90fb0cde564e4147932290d91832
Author: Sandra Loosemore
Date: Fri Mar 25 14:14:37 2022 -0700
Fortran: Add support for OMP non-rectangular loops.
This patch adds support fo
t cases
for the new diagnostics in the non-rectangular loops patch do exercise
it. Is this OK for trunk now, or for stage 1 when we get there?
-Sandracommit 4c745003d0b39d0e92032b62421df4920753783a
Author: Sandra Loosemore
Date: Thu Mar 24 21:02:34 2022 -0700
Fortran: Add location info
I ran into this bug in the handling of clauses on the combined "masked
taskloop" OMP directive when I was working on something else. The fix
turned out to be a 1-liner. OK for trunk?
-Sandracommit 17c4fa0bd97c070945004095a06fb7d9e91869e3
Author: Sandra Loosemore
Date: Wed Mar 2
uthor: Sandra Loosemore
Date: Thu Jan 20 13:29:48 2022 -0800
Fortran: Fix scope for OMP AFFINITY clause iterator variables [PR103695]
gfc_finish_var_decl was confused by the undocumented overloading of
the proc_name field in struct gfc_namespace to contain iterator
variables fo
This patch is for PR103695, marked as a P1 regression. OK to check in?
-Sandra
commit 21f8ac540b73e3838b63924e3c7e6c2ad25568ee
Author: Sandra Loosemore
Date: Wed Jan 19 12:50:49 2022 -0800
Fortran: Fix scope for OMP AFFINITY clause iterator variables [PR103695
the logic.
OK to check in?
-Sandra
commit 0e5b74440572f988dd96a6e9c33c11b59323d6cf
Author: Sandra Loosemore
Date: Thu Jan 6 11:23:18 2022 -0800
Fortran: Fix handling of optional argument to SIZE intrinsic [PR103898]
This patch fixes a think-o in the code that triggered an ICE
Loosemore
Date: Wed Jan 5 13:18:10 2022 -0800
Fortran: Fix ICE in argument_rank_mismatch [PR103287]
This patch removes an incorrect assertion. A user-friendly error for this
case is already given elsewhere.
2022-01-05 Steve Kargl
Sandra Loosemore
PR
435374884713a187ae8faa4eb
Author: Sandra Loosemore
Date: Tue Jan 4 18:18:13 2022 -0800
Fortran: Fix ICE caused by missing error for untyped symbol [PR103258]
The bit on a symbol to mark that it had already been diagnosed as
lacking a type was getting set even when th
ry to fix all the test cases.
Tobias pointed me in this direction when I discussed it with him a few
weeks ago so I hope I got it right.
OK to check in? It regression-tests fine on x86_64.
-Sandra
commit 3a5e4f3a14b4265ee6f92dd724cbae9103d38d4b
Author: Sandra Loosemore
Date: Wed Dec 29 16:
I was recently pinged about PR35276. It's an old issue, but a couple of
the concerns raised there haven't been fixed yet, so I've checked in
this patch to fill in the gaps.
-Sandra
commit b8bf685ed44dba9bd4bbd600bc8bc2be0a2abb1b
Author: Sandra Loosemore
Date: Fri Nov 5 14:0
?
-Sandra
commit bf03dfe2431b15b44a6bbf5605bbf5af32199f87
Author: Sandra Loosemore
Date: Thu Nov 4 15:43:29 2021 -0700
Fortran: Diagnose all operands/arguments with constraint violations [PR101337]
04-Nov-2021 Sandra Loosemore
Bernhard Reutner-Fischer
PR fortran
On 11/2/21 8:11 PM, Jerry D wrote:
Paul, great for getting this posted! I would approve but maybe Sandra
should.
Ummm, I only have approval superpowers for documentation patches, and as
a relative newbie to the Fortran front end I would probably struggle to
come up with anything useful to say
On 11/2/21 9:20 AM, Martin Liška wrote:
On 11/2/21 15:48, Sandra Loosemore wrote:
On 11/2/21 2:51 AM, Martin Liška wrote:
On 11/2/21 00:56, Sandra Loosemore wrote:
I'll wait a couple days before committing these patches, in case
anybody wants to give some feedback, especially on tech
On 11/2/21 2:51 AM, Martin Liška wrote:
On 11/2/21 00:56, Sandra Loosemore wrote:
I'll wait a couple days before committing these patches, in case
anybody wants to give some feedback, especially on technical issues.
Hello.
Appreciate the work you did, but the patchset will cause quite
2021-11-01 Sandra Loosemore
gcc/fortran/
* gfortran.texi (Projects): Add bullet for helping with
incomplete standards compliance.
(Proposed Extensions): Delete section.
---
gcc/fortran/gfortran.texi | 92 ---
1 file
2021-11-01 Sandra Loosemore
gcc/fortran/
* intrinsic.texi (Introduction to Intrinsics): Genericize
references to standard versions.
* invoke.texi (-fall-intrinsics): Likewise.
(-fmax-identifier-length=): Likewise.
---
gcc/fortran/intrinsic.texi | 15
2021-11-01 Sandra Loosemore
gcc/fortran/
* intrinsic.texi (Introduction to Intrinsics): Genericize
references to standard versions.
* invoke.texi (-fall-intrinsics): Likewise.
(-fmax-identifier-length=): Likewise.
---
gcc/fortran/intrinsic.texi | 15
2021-11-01 Sandra Loosemore
gcc/fortran/
* gfortran.texi (Interoperability with C): Copy-editing. Add
more index entries.
(Intrinsic Types): Likewise.
(Derived Types and struct): Likewise.
(Interoperable Global Variables): Likewise
Fix various bit-rot in the discussion of standards conformance, remove
material that is only of historical interest, copy-editing. Also move
discussion of preprocessing out of the introductory chapter.
2021-11-01 Sandra Loosemore
gcc/fortran/
* gfortran.texi (About GNU
Discussion of conformance with various revisions of the
Fortran standard was split between two separate parts of the
manual. This patch moves it all to the introductory chapter.
2021-11-01 Sandra Loosemore
gcc/fortran/
* gfortran.texi (Standards): Move discussion of specific
, especially on technical issues.
-Sandra
Sandra Loosemore (5):
Fortran manual: Combine standard conformance docs in one place.
Fortran manual: Revise introductory chapter.
Fortran manual: Update section on Interoperability with C
Fortran manual: Update miscellaneous references to old standar
With my documentation maintainer hat on, I've been working on updating
the standards compliance and TS29113-related material in the GNU Fortran
manual (patches will be posted soon). I also spent some time going
through the related wiki pages a few days ago to get them updated as well.
For F20
On 10/31/21 1:50 PM, Bernhard Reutner-Fischer wrote:
From: Bernhard Reutner-Fischer
PR fortran/101337
gcc/fortran/ChangeLog:
* resolve.c (resolve_operator): Continue resolving on op2 error.
---
The PR rightfully notes that we only diagnose the right operator
and do not check
meanwhile.
-Sandra
commit 75b603334401d079391ca950dd2e22663cdb3080
Author: Sandra Loosemore
Date: Mon Oct 25 11:08:28 2021 -0700
[Fortran] Fix broken use of alloca in C interoperability testcase
2021-10-25 Sandra Loosemore
gcc/testsuite/
PR testsu
I've committed another testcase from a bugzilla issue that now appears
to be fixed.
-Sandra
commit 9a0e34eb45e36d4f90cedb61191fd31da0bab256
Author: Sandra Loosemore
Date: Fri Oct 22 17:22:00 2021 -0700
Add testcase for PR fortran/95196
2021-10-22 José Rui Faustino de
I've committed this slightly cleaned-up version of the testcase
originally submitted with the now-fixed issue PR 94289.
-Sandra
commit c31d2d14f798dc7ca9cc078200d37113749ec3bd
Author: Sandra Loosemore
Date: Fri Oct 22 11:08:19 2021 -0700
Add testcase for PR fortran/94289
PR100906 ("Bind(c): failure handling character with len/=1") has been
fixed by Tobias's rewrite of the GFC <-> C descriptor conversions. I'd
like to add José's testcase for that issue before closing it. OK?
-Sandra
commit 4c2fa9cf74162015710ccfd913c8277791
ce from the gfortran maintainers to get the details right. :-S
-Sandra
commit f5971f451ae8834e928738bbfe465670aa481cea
Author: Sandra Loosemore
Date: Thu Oct 21 09:00:16 2021 -0700
GCC 12: Add release note for Fortran TS29113 improvements.
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-1
On 10/20/21 3:41 PM, Tobias Burnus wrote:
Hi Sandra,
On 20.10.21 22:03, Sandra Loosemore wrote:
The one that was most concerning was an ICE when calling the SHAPE
intrinsic with an assumed-rank class type argument ... In this case,
SHAPE was calling a library function and trying to copy the
into
gfc_trans_intrinsic_bound as well.)
While I was at it I also added 3 more testcases for these functions to
test for correct behavior with bind(c). All 6 new tests PASS now, and
there are no other regressions.
OK to commit?
-Sandra
commit c74d3f5ae059b74a552428d6f1602885ca239094
Author: S
On 10/7/21 9:25 AM, Tobias Burnus wrote:
Hi Sandra,
On 06.10.21 23:37, Sandra Loosemore wrote:
This patch is for PR fortran/54753, to add a diagnostic for violations
of this constraint in the 2018 standard:
C839 If an assumed-size or nonallocatable nonpointer assumed-rank
array is an
unblock my work
on this one.) That bug is independent of enforcing this constraint so
I'm planning to open a new issue for it with its own test case, if there
isn't already one in Bugzilla.
OK to commit?
-Sandra
commit d11d942503c884c06155f2743f8ed6c981a65533
Author: Sandra Loosemo
On 10/2/21 2:28 PM, Harald Anlauf wrote:
Hi Tobias,
the corrected attached patch fixes the regression for testcase
default_initialization_3.f90 for me now, and as a bonus matches
the description.
Me too! I'm also seeing clean test results now.
-Sandra
On 9/29/21 2:53 AM, Tobias Burnus wrote:
Found when looking at F2018:C839 / PR54753.
For INTENT(OUT) the dummy variable (might) also be default initialized
or deallocated. However, with assumed rank, that causes issues, which
C839 prevents. In the current GCC implementation, missing C839 constra
Here's another missing-diagnostic patch for the Fortran front end, this
time for PR Fortran/101333. OK to commit?
-Sandra
commit 53171e748e28901693ca4362ff658883dab97e13
Author: Sandra Loosemore
Date: Thu Sep 23 15:00:43 2021 -0700
Fortran: Add missing diagnostic for F2018
On 9/23/21 10:10 AM, Tobias Burnus wrote:
On 23.09.21 17:50, Sandra Loosemore wrote:
This patch is for PR101320, another issue related to missing bind(c)
diagnostics. OK to commit?
LGTM - I am only ...
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index f2e8896..b3c65b7 100644
--- a
This patch is for PR101320, another issue related to missing bind(c)
diagnostics. OK to commit?
-Sandra
commit d3507154fd34e65e2887262218fec09d5fb082a2
Author: Sandra Loosemore
Date: Thu Sep 23 08:03:52 2021 -0700
Fortran: Diagnose default-initialized pointer/allocatable dummies
This patch is adds the missing diagnostic noted in PR fortran/101319.
OK to commit?
-Sandra
commit 9d5b9062d728d1b1bf5acfb914e06d776bdcdb60
Author: Sandra Loosemore
Date: Wed Sep 22 07:49:17 2021 -0700
Fortran: diagnostic for argument w/type parameters for assumed-type dummy
erent from what
they were originally trying to test, but they never should have worked
as originally written anyway. We were just not previously diagnosing
the C838 violations without the other patch I just posted to do that.
-Sandra
commit dd48922d40542eb1b9d17a78fcb3a7cfb857d555
Author: Sandra
a bogus error when passing one as the first argument
to the ASSOCIATED intrinsic. Both fixes turned out to be 1-liners. OK
to commit?
-Sandra
commit b967fe5f88a5245163f235cfa6a5808aa41e88f4
Author: Sandra Loosemore
Date: Sun Sep 19 17:32:03 2021 -0700
Fortran: Fixes for F2018 C838 (PR
On 9/5/21 11:20 PM, Sandra Loosemore wrote:
Unless the aarch64 maintainers think it is a bug that __float128 is not
supported, I think the right solution here is the one I was thinking of
previously, to fix the Fortran front end to tie the C_FLOAT128 kind to
_Float128 rather than __float128
On 9/13/21 11:07 AM, Tobias Burnus wrote:
On 13.09.21 18:59, Sandra Loosemore wrote:
On 9/13/21 10:51 AM, Jakub Jelinek wrote: >>> Wouldn't it be better to use the
__LDBL_* macros anyway and not rely on
float.h? The header doesn't want to test what float.h tells about t
On 9/13/21 10:51 AM, Jakub Jelinek wrote:
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
In file included from
.../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
.../GCC-HE
On 9/5/21 7:29 PM, H.J. Lu wrote:
On Sun, Sep 5, 2021 at 11:02 AM Sandra Loosemore
wrote:
On 9/5/21 7:31 AM, H.J. Lu wrote:
On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore wrote:
The testcase gfortran.dg/PR100914.f90 that I recently checked in
(originally written by José Rui Faustino de
On 9/5/21 7:31 AM, H.J. Lu wrote:
On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore wrote:
The testcase gfortran.dg/PR100914.f90 that I recently checked in
(originally written by José Rui Faustino de Sousa) depends on the
header file to obtain a typedef for __complex128. It
appears not to be
-Sandra
commit 41fe3b50b3d92931fc99ef15f86cc9299e0c617e
Author: Sandra Loosemore
Date: Sat Sep 4 18:36:39 2021 -0700
Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h.
This test uses the __complex128 type, which is provided by the
header which may not be available on all targets.
On 9/2/21 11:37 PM, Sandra Loosemore wrote:
On 9/2/21 10:18 PM, sunil.k.pandey wrote:
On Linux/x86_64,
93b6b2f614eb692d1d8126ec6cb946984a9d01d7 is the first bad commit
commit 93b6b2f614eb692d1d8126ec6cb946984a9d01d7
Author: Sandra Loosemore
Date: Wed Aug 18 07:22:03 2021 -0700
On 9/3/21 3:14 AM, Tobias Burnus wrote:
If I read https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
correctly, we should use _Float128 for the following errors
"The _Float128 type is supported on all systems where __float128 is
supported or where long double has the IEEE binary128 format
On 9/2/21 10:18 PM, sunil.k.pandey wrote:
On Linux/x86_64,
93b6b2f614eb692d1d8126ec6cb946984a9d01d7 is the first bad commit
commit 93b6b2f614eb692d1d8126ec6cb946984a9d01d7
Author: Sandra Loosemore
Date: Wed Aug 18 07:22:03 2021 -0700
libgfortran: Further fixes for GFC/CFI descriptor
On 8/18/21 8:57 PM, Sandra Loosemore wrote:
This is a follow-up to commit fef67987cf502fe322e92ddce22eea7ac46b4d75:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fef67987cf502fe322e92ddce22eea7ac46b4d75
I realized last week that having multilib-specific versions of
ISO_Fortran_binding.h
I've backported several patches having to do with Fortran/C
interoperability from mainline to the OG11 branch. See attached log for
details.
-Sandra
commit d554155c07771935778f557e9ef649cc3624d1ce
Author: Sandra Loosemore
Date: Wed Aug 11 19:24:17 2021 -0700
Fortran: Fix c_flo
On 7/27/21 5:07 AM, Tobias Burnus wrote:
Hi Sandra, hi Thomas, hi all,
@Thomas K: Comments about the following - and of course to the
testsuite itself - are highly welcome.
In my opinion, the testsuite LGTM and can be committed.
@Sandra:
- Thoughts on the directory name? (cf. below)
- Give oth
cessary to
solve the problems for real.
In addition to José's test cases included with this patch, I've added
some additional test coverage to my TS29113 testsuite which I will be
reposting soon.
-Sandra
commit bce396d541d65029e2897e59c6e0baeed090e340
Author: Sandra Loosemore
Date:
Or OK to commit?
-Sandra
commit bf52fcb46ee62ff2f7c552397d58914b934b130f
Author: Sandra Loosemore
Date: Fri Aug 13 17:46:19 2021 -0700
Fortran: Revert to non-multilib-specific ISO_Fortran_binding.h
Commit fef67987cf502fe322e92ddce22eea7ac46b4d75 changed the
libgfortran build process to gene
On 8/11/21 2:05 AM, Tobias Burnus wrote:
On 11.08.21 00:46, Sandra Loosemore wrote:
On 8/10/21 2:29 AM, Tobias Burnus wrote:
[snip]
To conclude: I like the code changes (LGTM); the
'__float128' -> 'TFmode' comment change also matches the code.
However, I think both
the two comments only.
OK to commit this one?
-Sandra
commit e496723ec6ee0fcf5b0c58920c74b1c9afa831de
Author: Sandra Loosemore
Date: Tue Aug 3 16:21:16 2021 -0700
Fix c_float128 and c_float128_complex definitions.
gfc_float128_type_node is only non-NULL on targets that suppo
On 8/10/21 2:29 AM, Tobias Burnus wrote:
[snip]
OK. I now think it's correct that the Fortran front end doesn't
support c_float128 and c_float128_complex on this target, but that the
code that initializes those constants is still buggy. The reason why
it shouldn't support them is that all 3
ortran maintainers, is this one OK to check in?
-Sandra
commit 073dd403d11553c199610b038285b203c130cee5
Author: Sandra Loosemore
Date: Tue Aug 3 16:21:16 2021 -0700
Fix c_float128 and c_float128_complex definitions.
gfc_float128_type_node is only non-NULL on targets that support a
128-bi
On 8/5/21 11:33 AM, Michael Meissner wrote:
At the moment, we only fully support C and C++ when changing the long double
format (between IEEE 128-bit, IBM 128-bit, and 64-bit) when the compiler is
invoked (and assuming you are using GLIBC 2.32 or newer).
For Fortran and the other languages, the
ecifying a different type than TFmode, and if so is there a
target-independent way to identify that situation? Can the PowerPC
experts help straighten me out?
-Sandra
commit 158c2f6b1a4134bbdbe59034d38ce12faa8167a8
Author: Sandra Loosemore
Date: Tue Aug 3 16:21:16 2021 -070
On 7/26/21 2:13 PM, Sandra Loosemore wrote:
On 7/26/21 3:45 AM, Tobias Burnus wrote:
[snip]
PS: Still, it would be nice if the proper multi-lib ISO*.h could be
found;
while it usually does not matter, it could do so in some cases.
I think I ought to fix this now instead of just sweeping
On 7/26/21 3:45 AM, Tobias Burnus wrote:
[snip]
I did say that it mostly works because of:
$ find x86_64-pc-linux-gnu/ -name ISO_Fortran_binding.h
x86_64-pc-linux-gnu/libgfortran/ISO_Fortran_binding.h
x86_64-pc-linux-gnu/32/libgfortran/ISO_Fortran_binding.h
And when looking at the -B lines, I
Here is an updated version of my TS29113 testsuite. The last version I
posted became kind of bit-rotten after Tobias's commit "Fortran: Fix
bind(C) character length checks" for PR92842, which changed the wording
of the error message that I'd been catching with dg-bogus in many
places. I've al
On 7/22/21 1:54 AM, Tobias Burnus wrote:
Hi Sandra,
On 21.07.21 20:01, Sandra Loosemore wrote:
Hmmm. CFI_establish explicitly says that the elem_len has to be
greater than zero. It seems somewhat confusing that it's inconsistent
with the other functions that take an elem_len arg
On 7/23/21 8:15 AM, Tobias Burnus wrote:
Hi Sandra,
On 21.07.21 12:17, Tobias Burnus wrote:
On 13.07.21 23:28, Sandra Loosemore wrote:
ISO_Fortran_binding.h is now generated in the libgfortran build
directory where it is on the default include path. Adjust includes in
the gfortran testsuite
On 7/21/21 11:26 AM, Tobias Burnus wrote:
On 17.07.21 02:49, Sandra Loosemore wrote:
This patch is for PR101317, one of the bugs uncovered by the TS29113
testsuite. Here I'd observed that CFI_establish, etc was not
diagnosing some invalid-argument situations documented in the
sta
ll in with the base testsuite patch depending on
the order that things get reviewed/committed.
-Sandra
commit a2e189aeb165781fe741f942e00bf073a496af92
Author: Sandra Loosemore
Date: Sat Jul 17 16:12:18 2021 -0700
[PR libfortran/101310] Bind(c): Fix bugs in CFI_section
CFI_sectio
small mistakes in the test cases and fixed those too.
The testsuite fixes can either be committed with this patch or rolled
into the TS29113 testsuite, depending on the order in which things are
approved/committed.
OK?
-Sandra
commit 6cecb3e3625072c7846434df9dcd8db5e6f66432
Author: Sandra Loos
On 7/16/21 9:32 AM, Thomas Schwinge wrote:
[much snipped]
Of course, we shall assume a certain level of quality in the XFAILed test
cases: I'm certainly not suggesting we put any random junk into the
testsuite, coarsely XFAILed. (I have not reviewed Sandra's test cases to
that effect, but know
42c
Author: Sandra Loosemore
Date: Thu Jul 15 16:51:55 2021 -0700
Bind(c): signed char is not a Fortran character type
CFI_allocate and CFI_select_part were incorrectly treating
CFI_type_signed_char as a Fortran character type for the purpose of
deciding whether or not
ISO_Fortran_binding.h is now generated in the libgfortran build
directory where it is on the default include path. Adjust includes in
the gfortran testsuite not to include an explicit path pointing at the
source directory.
2021-07-13 Sandra Loosemore
gcc/testsuite/
PR libfortran
to use sizeof instead of
hard-coded sizes, and assembles it from fragments that reflect the
set of types supported by the target.
2021-07-13 Sandra Loosemore
Tobias Burnus
libgfortran/
PR libfortran/101305
* ISO_Fortran_binding.h: Fix hard-coded sizes and split into
CFI_establish was failing to set the default elem_len correctly for
CFI_type_cptr, CFI_type_cfunptr, CFI_type_long_double, and
CFI_type_long_double_Complex.
2021-07-13 Sandra Loosemore
libgfortran/
PR libfortran/101305
* runtime/ISO_Fortran_binding.c (CFI_establish): Special
ue 128-bit floating-point format, the GFC descriptor
representation can't tell them apart.
I tested these patches on i686-pc-linux-gnu with both -m32 and -m64
multilibs.
Sandra Loosemore (3):
[PR libfortran/101305] Bind(C): Fix type encodings in
ISO_Fortran_binding.h
[PR libfortran/101305] B
On 6/13/21 12:36 PM, José Rui Faustino de Sousa via Gcc-patches wrote:
Hi All!
Proposed patch to:
Bug 100906 - Bind(c): failure handling character with len/=1
Bug 100907 - Bind(c): failure handling wide character
Bug 100911 - Bind(c): failure handling C_PTR
Bug 100914 - Bind(c): errors handling
On 6/30/21 11:53 PM, Sandra Loosemore wrote:
For the past several months I've been working on developing a set of
tests for the Fortran/C interoperability features added to Fortran via
TS 29113, "Further Interoperability of Fortran with C":
https://wg5-fortran.org/N1901-N1950
On 7/1/21 11:08 AM, Tobias Burnus wrote:
Hi all,
this patch came up when discussing Sandra's TS29113 patch internally.
There is presumably also some overlap with José's patches.
This patch tries to rectify the BIND(C) CHARACTER handling on the
diagnostic side, only. That is: what to accept and
On 7/1/21 11:08 AM, Tobias Burnus wrote:
Hi all,
this patch came up when discussing Sandra's TS29113 patch internally.
There is presumably also some overlap with José's patches.
This patch tries to rectify the BIND(C) CHARACTER handling on the
diagnostic side, only. That is: what to accept and
8ef11
Author: Sandra Loosemore
Date: Wed Jun 30 19:28:22 2021 -0700
Fortran: set version field in CFI_cdesc_t to CFI_VERSION
When converting a GFC descriptor to a CFI descriptor, it was
incorrectly copying the version number from the former to the latter.
It should be usin
For the past several months I've been working on developing a set of
tests for the Fortran/C interoperability features added to Fortran via
TS 29113, "Further Interoperability of Fortran with C":
https://wg5-fortran.org/N1901-N1950/N1942.pdf
The goal here is to exercise gfortran's implementati
On 6/21/21 5:42 AM, Tobias Burnus wrote:
On 21.06.21 08:05, Sandra Loosemore wrote:
I ran into this bug in CFI_allocate while testing something else and
then realized there was already a PR open for it. It seems like an
easy fix, and I've used Tobias's test case from the issue mo
they have
all been fixed already except for this one.
OK to check in?
-Sandra
commit de9920753469e36c968b273a0e8b4d66a1d57946
Author: Sandra Loosemore
Date: Sun Jun 20 22:37:55 2021 -0700
Fortran: fix sm computation in CFI_allocate [PR93524]
This patch fixes a bug in settin
97 matches
Mail list logo
