73ecbc2672a5352a08260f7a9d0de6d2c29ea2b6 Mon Sep 17 00:00:00 2001
From: Paul-Antoine Arras
Date: Wed, 21 Sep 2022 15:52:56 +
Subject: [PATCH] OpenMP: Fix ICE with OMP metadirectives
Problem: ending an OpenMP metadirective block with an OMP end statement
results in an internal compiler error.
Solution: reject invalid end
Sep 17 00:00:00 2001
From: Paul-Antoine Arras
Date: Wed, 21 Sep 2022 15:52:56 +
Subject: [PATCH] OpenMP: Fix ICE with OMP metadirectives
Problem: ending an OpenMP metadirective block with an OMP end statement
results in an internal compiler error.
Solution: reject invalid end statements and
ep 17 00:00:00 2001
From: Paul-Antoine Arras
Date: Fri, 20 Oct 2023 12:42:49 +0200
Subject: [PATCH] Fortran: Fix incompatible types between INTEGER(8) and
TYPE(c_ptr)
In the context of an OpenMP declare variant directive, arguments of type C_PTR
are sometimes recognised as C_PTR in the base f
Hi Tobias,
Please see the updated patch attached incorporating your input and
details below.
On 24/10/2023 18:12, you wrote:
On 20.10.23 16:02, Paul-Antoine Arras wrote:
gcc/fortran/ChangeLog:
* interface.cc (gfc_compare_types): Return true in this situation.
That's
Hi Thomas,
On 26/10/2023 18:16, you wrote:
Hi!
On 2023-10-26T13:24:04+0200, Paul-Antoine Arras wrote:
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/c_ptr_tests_20.f90
@@ -0,0 +1,57 @@
+! { dg-do compile }
+! { dg-additional-options "-fopenmp" }
+[...]
--- /dev/null
+++ b/gcc
On 27/12/2024 19:52, Paul-Antoine Arras wrote:
On 23/12/2024 21:04, Tobias Burnus wrote:
For adjust-args-10.f90, I wonder whether it is sufficient as compile-
time only or whether it makes more sense to have a "dg-do run" to
check that type(C_ptr) value vs. not-value works. I think
Hi Tobias,
On 23/12/2024 21:04, Tobias Burnus wrote:
Paul-Antoine Arras wrote:
Replying to your last two messages here and attaching revised patches.
Regarding the C++ and ME patches:
==> 0003-C-fix.patch <==
Subject: [PATCH 3/4] C++ fix
==> 0004-ME-fixes.patch <==
Subject: [P
When the ST_NONE case is taken, the function returns immediately. Not calling
pop_state causes a dangling pointer.
gcc/fortran/ChangeLog:
* parse.cc (parse_omp_dispatch): Add missing pop_state.
---
gcc/fortran/parse.cc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Pushed to master as obvious. This should fix PR118714.
On 31/01/2025 11:46, Paul-Antoine Arras wrote:
When the ST_NONE case is taken, the function returns immediately. Not calling
pop_state causes a dangling pointer.
gcc/fortran/ChangeLog:
* parse.cc (parse_omp_dispatch): Add missing
On 13/01/2025 16:51, Tobias Burnus wrote:
Hi PA,
Paul-Antoine Arras wrote:
I am not sure I am getting that part. Is this what you are suggesting?
Yes, something like that, but not quite, as you found out.
I think we need something like the following (untested):
diff --git gcc/fortran
g an -fdump-tree-gimple + scan test probably won't
harm, as not everyone has a GPU and we might implement map as
selfmap on APUs).
This is actually not specific to the Fortran FE. So I had to modify the
middle end and the C++ parser as well. See attached pactches.
Otherwise LGTM.
Tobias
11 matches
Mail list logo
