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
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
ad been touched for years.
-Sandra
commit 559b1911c825c8df273d6cc7c403a3d0c79d0295
Author: Sandra Loosemore
Date: Sun Dec 5 17:59:19 2021 -0800
lto: Don't run ipa-comdats pass during LTO
When the ipa-visibility pass is invoked during LTO, it attempts to
localize comdat symbols
in my new patch I
arranged things so that the implicit clones are only created if there is
also a call to the function found in an OMP loop (not just one caller
anywhere). So this should be fixed now.
New patch attached. Is this one OK for mainline?
-Sandracommit eb1fe25b125cd153b2c661f1c54e61
On 10/17/22 07:28, Martin Liška wrote:
Hello.
Based on the very positive feedback I was given at the Cauldron Sphinx
Documentation BoF,
I'm planning migrating the documentation on 9th November. There are still some
minor comments
from Sandra when it comes to the PDF output, but we can address
On 10/19/22 05:09, Martin Liška wrote:
On 10/18/22 00:26, Sandra Loosemore wrote:
On 10/17/22 07:28, Martin Liška wrote:
Hello.
Based on the very positive feedback I was given at the Cauldron Sphinx
Documentation BoF,
I'm planning migrating the documentation on 9th November. There are
On 10/20/22 08:07, Jakub Jelinek wrote:
Thus, IMHO it is exactly the pass_omp_simd_clone pass where you want to
implement this auto-simdization discovery, guarded with
#ifdef ACCEL_COMPILER and the new option (which means it will be done
only for gcn and not on the host right now).
I'm running
On 10/27/22 04:09, Thomas Schwinge wrote:
Hi!
On 2022-10-26T20:27:19-0600, Sandra Loosemore wrote:
One of my test cases examines the .s output to make sure that the clones
are emitted as local symbols and not global. I have not been able to
find the symbol linkage information in any of the
I've checked in this one-liner to note that OpenMP support for
non-rectangular loops is now complete in the feature checklist. Thanks
to Tobias for pointing me at this.
-Sandracommit 2d8752c5923e2ed4dc33b95038fed82b46526feb
Author: Sandra Loosemore
Date: Thu May 5 14:45:29 2022
On 11/13/19 6:45 AM, Martin Liška wrote:
Hi.
The patch is about a documentation entry for a newly added
option in GCC 10.
Ready for trunk?
I thought this would be OK, until I saw:
+Enabled by default.
At the beginning of invoke.texi where it is talking about options having
both -foo and
the same goto form that the C front end formerly emitted instead
of the C++-style output, but that might just be papering over bugs
elsewhere. Any advice on how to proceed here is welcome. If the
patches are OK otherwise, maybe just file bugzilla issues for these
regressions?
-Sandra
Sandra Loos
2019-11-12 Sandra Loosemore
gcc/c
* c-decl.c (c_break_label, c_cont_label): Delete, and replace
with...
(in_statement): New.
(start_function): Adjust for above change.
(c_push_function_context, c_pop_function_context): Likewise.
* c
similar OMP constructs is also moved.
2019-11-12 Sandra Loosemore
gcc/c-family/
* c-common.c (c_block_may_fallthrough): New, split from
cxx_block_may_fallthrough in the cp front end.
(c_common_init_ts): Move handling of loop and switch-related
statements
On 1/13/20 7:02 AM, Eric S. Raymond wrote:
Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.
This is OK, although the set of changes for the libstdc++ manual like
this gave me pause:
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
b
On 1/13/20 9:12 AM, Joseph Myers wrote:
On Mon, 13 Jan 2020, Sandra Loosemore wrote:
On 1/13/20 7:02 AM, Eric S. Raymond wrote:
Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.
This is OK, although the set of changes for the libstdc++ manual
On 1/8/20 9:07 AM, Tobias Burnus wrote:
When looking at libgomp.texi the other day, I saw that the acc_*_async
variants and the acc_*_finalize functions of OpenACC 2.5 were not
documented.
Hence, this patch adds them. Those are part of OpenACC 2.5, hence, I
updated the @ref (but referenced to
On 1/10/20 9:34 AM, Tobias Burnus wrote:
I believe except for bugs and known omissions (e.g. PR93225+93226), the
GCC 10 trunk implementation is complete – and the version number can be
bumped from 2.0 (alias 201306) to OpenACC 2.6 (alias 201711).
That's what this patch does (i.e. applying the
On 1/20/20 8:08 AM, Alexander Monakov wrote:
Hi,
we have this paragraph in the documentation that attempts to prohibit something
that is allowed by the language. Instead, I think we should say that this
generally should work and explain that a problem in GCC implementation
breaks this.
OK to a
On 1/20/20 3:08 AM, Tobias Burnus wrote:
Hi Sandra,
On 1/20/20 5:39 AM, Sandra Loosemore wrote:
I happen to have noticed a couple weeks ago that this language about
OpenACC support being experimental appears in multiple places in the
gfortran manual, […] The same disclaimer for that option
I observed this testcase was failing on nios2-elf. The more general
regexp was copied from other tests using dg-output.
2020-01-21 Sandra Loosemore
gcc/testsuite/
* g++.dg/coroutines/torture/mid-suspend-destruction-0.C: Generalize
line terminators in patterns
andra
2020-01-21 Sandra Loosemore
gcc/testsuite/
* g++.dg/cpp0x/constexpr-odr1.C: Add -fdelete-null-pointer-checks.
* g++.dg/cpp0x/constexpr-odr2.C: Likewise.
* g++.dg/cpp0x/nontype4.C: Likewise.
* g++.dg/cpp1y/constexpr-new.C: Likewise.
* g++.dg/cpp1y/new1.C: Likewise.
* g++.dg/cp
On 1/23/20 1:17 PM, Jeff Law wrote:
On Tue, 2020-01-21 at 15:00 -0700, Sandra Loosemore wrote:
In doing some nios2-elf testing, I ran into a bunch of failures in
constexpr-related tests in the C++ testsuite. This target defaults to
-fno-delete-null-pointer-checks at the request of Altera/Intel
h and without the binutils support
present, before committing this.
2020-01-31 Sandra Loosemore
gcc/
* configure.ac [nios2-*-*]: Check HAVE_AS_NIOS2_GOTOFF_RELOCATION.
* config.in: Regenerated.
* configure: Regenerated.
* config/nios2/ni
On 2/1/20 8:43 AM, Bernd Edlinger wrote:
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 6ffafac..1d3fec5 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2097,9 +2097,18 @@ option (if not used explicitly on the command line).
@var{choice}
can be one of @samp{ne
f in every subdirectory that contains a
configure.ac, but it appears only libstc++-v3 actually uses this test;
all the other regenerated configure scripts were unchanged.
-Sandra
>From 44b769a9b5e01a58c9b89b24ca5a00fc1ff53012 Mon Sep 17 00:00:00 2001
From: Sandra Loosemore
Date: Wed, 5 Feb 2020 1
On 2/6/20 3:18 PM, Gerald Pfeifer wrote:
On Thu, 6 Feb 2020, Jakub Jelinek wrote:
+ If tentative definitions of particular variable or variables need to be
I believe that would be "a particular variable", but best to simplify
to "of particular variables".
+ placed in a common block, __attr
On 2/7/20 3:24 PM, Joseph Myers wrote:
On Wed, 5 Feb 2020, Sandra Loosemore wrote:
This patch is for PR 79193 and 88999, problems where libstdc++ is
mis-configuring itself when building for a bare-metal target because it thinks
it can link programs without pulling in the BSP that provides low
On 2/10/20 3:58 PM, Joseph Myers wrote:
On Sat, 8 Feb 2020, Sandra Loosemore wrote:
BTW, I did run autoconf in every subdirectory that contains a
configure.ac,
but it appears only libstc++-v3 actually uses this test; all the other
regenerated configure scripts were unchanged.
There's
. I've committed the attached patch as an
obvious followup to the last one.
-Sandra
commit bb97ad35ead015075ee4747136c9fc75faa27411
Author: Sandra Loosemore
Date: Thu Feb 13 10:47:55 2020 -0800
Add -fdelete-null-pointer-checks to more new C++ testcases.
2020-02-13 Sandra Loos
On 2/4/20 6:05 PM, Martin Sebor wrote:
GCC diagnoses declarations of function aliases whose type doesn't
match that of the target (ditto for attribute weakref). It doesn't
yet diagnose such incompatbilities for variable aliases but that's
just an oversight that I will try to remember to correct
On 2/5/20 1:13 PM, Martin Sebor wrote:
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index ec99c38a607..3634ce1c423 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2557,8 +2557,11 @@ __attribute__ ((access (write_only, 1, 2), access
(read_write, 3))) int fgets (c
@ite
On 2/14/20 11:30 AM, Martin Sebor wrote:
[snip]
Attached
is the updated revision that I plan to commit unless you (or anyone
else) have further suggestions.
This version is OK to commit.
-Sandra
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
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 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 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
-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/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
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/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/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/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
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
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
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
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
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
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
/ml/binutils/2019-12/msg00013.html
-Sandra
2019-12-05 Sandra Loosemore
Disable --eh-frame-hdr with -pie or -shared on nios2-linux-gnu.
The nios2 ABI doesn't have appropriate relocations to support
--eh-frame-hdr with -pie or -shared, so we need to override the
default specs
On 12/5/19 2:47 PM, Sandra Loosemore wrote:
I've checked in this patch to fix a long-standing bug on nios2-linux-gnu
that resulted in linker errors like
../nios2-linux-gnu/bin/ld: FDE encoding in /tmp/cccfpQ2l.o(.eh_frame)
prevents .eh_frame_hdr table being created
when linking with -p
On 11/15/19 6:22 PM, David Malcolm wrote:
gcc/ChangeLog:
* doc/invoke.texi ("Static Analyzer Options"): New list and new section.
("Warning Options"): Add static analysis warnings to the list.
(-Wno-analyzer-double-fclose): New option.
(-Wno-analyzer-double-free):
On 12/6/19 3:41 PM, Jeff Law wrote:
On Wed, 2019-11-13 at 09:27 -0700, Sandra Loosemore wrote:
I bootstrapped and regression-tested this on x86_64-linux-gnu. There
are a few regressions involving these tests:
gcc.dg/tree-ssa/pr77445-2.c
I believe tihs is another instance of the FSA
On 12/11/19 11:27 AM, Jason Merrill wrote:
On 12/11/19 2:03 AM, Sandra Loosemore wrote:
[snip]
Anyway, I'm no longer expecting to get this front end patch into GCC
10, but it would be helpful to get some guidance on how to proceed for
resubmission when stage 1 re-opens. E.g. from wher
On 1/6/20 7:10 AM, Jonathan Wakely wrote:
How about:
GCC now defaults to -fno-common. As a result, global
variable accesses are more efficient on various targets. In C, global
variables with multiple tentative definitions will result in linker
errors.
This is better. I'd also s/will/now/,
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
, 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
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
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
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
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 (Projects): Add bullet for helping with
incomplete standards compliance.
(Proposed Extensions): Delete section.
---
gcc/fortran/gfortran.texi | 92 ---
1 file
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
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
?
-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
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
the extra state being stored in the options structure. I've made it
properly check that the custom instructions enabled in the callee must
be a subset of those in the caller, with the same encoding in both cases.
-Sandra
commit df69d7ae8f9903df8a553e236c54df61633d8af2
Author: Sandra Loose
On 11/10/21 4:54 AM, Tamar Christina via Gcc-patches wrote:
Hi All,
These test don't work on vector ISAs where the truth
type don't match the vector mode of the operation.
However I still want the tests to run on these
architectures but just turn off the ISA modes that
enable masks.
This thus
On 11/10/21 11:53 AM, Tamar Christina wrote:
FAIL: gcc.dg/signbit-2.c scan-tree-dump-times optimized
"[file://\\s+]\\s+>\\s+{ 0,
0, 0, 0 }" 1
That's the old test which this patch has changed. Does it still fail
with the new patch?
My test results are indeed from a couple days ago. But, I lo
ntil we're into stage 3 and the churn settles down
some before I make another pass to triage remaining nios2-specific
problems, but I might as well check in what I have now instead of
sitting on it.
-Sandra
commit eb43f1a95d1d7a0f88a8107d860e5343507554dd
Author: Sandra Loosemore
Date: T
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
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
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/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
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/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
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
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
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
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
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
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 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 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
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
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
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
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
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
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
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
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
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
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/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
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/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
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 3/1/24 08:23, Tobias Burnus wrote:
Not very often, but do I keep running into issues (fails, segfaults)
related to testing programs compiled with a GCC without offload
configured and then using the system libraries. - That's equivalent
to having the system compiler (or any offload compiler) an
On 3/1/24 17:29, Sandra Loosemore wrote:
On 3/1/24 08:23, Tobias Burnus wrote:
Aside: Shouldn't all the HTML documents start with a and
before
the table of content? Currently, it has:
Top (GNU libgomp)
and the body starts with
Short Table of Contents
I think this is a bug i
101 - 200 of 1322 matches
Mail list logo
