FYI: I have now committed it as 6c1d5b0f7d219dc11f32885b9931205e2fd6a015
Tobias Burnus wrote:
attached is a patch to update the Fortran section of the GCC 16
release notes. […] https://gcc.gnu.org/gcc-16/changes.html
Tobias
Kwok Cheung Yeung wrote on July 9, 2025:
Subject: [PATCH 05/11] openmp, fortran: Add support for iterators in OpenMP
'target update' constructs (Fortran)
This adds Fortran support for iterators in 'to' and 'from' clauses in the
'target update' OpenMP directive.
...
@@ -1418,16 +1419,67 @@ gf
Hi all,
attached is a patch to update the Fortran section of the GCC 16
release notes. I am sure that I missed some fine print and the
most important changes are also some bug fixes, which are difficult
to list. → https://gcc.gnu.org/gcc-16/changes.html
Comments?
Tobias
PS: I am aware of addit
Kwok Cheung Yeung wrote on July 9, 2025:
This patch adds macros to refer to the fields of OpenMP iterators by
name rather than by index, as the number of items has increased to 10
and referring to them by index has become error-prone.
Subject: [PATCH 07/11] openmp: Add macros for iterator ele
Hi Kwok,
sorry for the belated review.
[Some minor but trivial changes are required due to bitrotting -
both in gimplify.cc and in libgomp/target.c]
Kwok Cheung Yeung wrote:
Subject: [PATCH 04/11] openmp, fortran: Add support for map iterators in
OpenMP target construct (Fortran)
This add
Yuao Ma wrote:
And the latter does not handle EXPR_CONDITIONAL.
Thanks for the tip! It turns out that not only does gfc_traverse_expr
fail to handle conditional expressions, but check_restricted and
gfc_check_init_expr don't either. I've added all the necessary fixes,
and the test case is now in
Hi Yuao,
Yuao Ma wrote:
This time I use git format-patch. Hopefully fix the issue.
Seem so :-)
Do I read you patch correctly that you still want to improve it
before committing the first version? I assume so because the
changelog part of the patch is largely lacking (except for
the summary li
Hi Andre, hi all,
Andre Vehreschild wrote:
I am experiencing a strange issue with gfortran. Compiling a simple program:
$ cat end.f90
end
$ gfortran end.f90 -o end
f951: Fatal Error: Cannot open pre-included file '\xe0\xd4\xf2,'
compilation terminated.
From your description, it sounds as if y
Hi Yuao,
Tobias Burnus wrote:
Based on our previous discussion, we
don't need to necessarily handle this in the current patch; I just
wanted to highlight it. I will investigate how the argument-passing
logic works.
Yes, as long as there is a 'sorry' instead of producing wrong c
Hi Yuao,
Yuao Ma wrote:
Hi Tobias,
I have some updates about this patch.
First, some good news:
1. The patch has been bootstrapped and tested with no regressions.
This was achieved by limiting the type with only one 'sorry' case.
2. The frontend parsing now considers outer parentheses.
:-)
Hi all, hi Yuao,
Yuao Ma wrote:
I mostly agree it looks okay. While I'm not that meticulous about
diagnostics, I believe it should point to the '=' sign or the first
character of the expression. Pointing to the middle, however, seems a
bit odd.
Looking at your patch, I understand what you mean
Yuao Ma wrote:
BTW, The current trunk seems to have some problems with diagnostic
location: https://godbolt.org/z/bcrvn9xo4
In the last days, there were some diagnostic changes; possibly
those caused an intermittent issue?
Otherwise, it looks ok. Namely:
The '1' points to the space after '='i
Minor update (as attached): Fixed two bugs in plugin-gcn.c.
The patch has now also been tested with AMD GPUs (MI300) offloading
and on a PowerPC (powerpc64le) system with offloading
to a Volta GPU.
Tobias Burnus wrote:
The main motivation for this patch is that on MI300,
libgomp.c-c++-common
The main motivation for this patch is that on MI300,
libgomp.c-c++-common/declare-target-indirect-2.c always fails
because of the known fragile/racy code - as noticed before
(PR114445 and PR119857), albeit triggering the fail has become
more reliably.
'indirect' means that such-tagged functions a
, but libgomp needs to be fixed in
either case.)
Tobias
commit 5a7e3d44bab04017f82fb8b883e564bf7198c35c
Author: Tobias Burnus
Date: Fri Aug 29 09:51:06 2025 +0200
invoke.texi: AMD GCN - remove '(experimental)' from some gfx*-generic
GCC added generic support in r15-7406-gb5a29a93ee29a8 (Feb 2025) with a
This kind of came up because now objdump is required during the GCC
build (for ./configure) to set the required HAVE_..., solving PR119367.
While LLVM's assembler and linker are required to handle AMD GPUs,
all others just need to be found and can be the LLVM or Binutils'
variant alike.
Addition
IMD issues.
Tobias Burnus wrote:
Changes in GCC 16 enables more vectorization, triggering bugs in
the GCN's Newlib vector implementation.
This patch adds a second Newlib commit to the documentation;
and a third – the two new ones both related to 'fmod' and lane handling,
see commit lo
Changes in GCC 16 enables more vectorization, triggering bugs in
the GCN's Newlib vector implementation.
This patch adds a second Newlib commit to the documentation;
for GCN user - esp. for mainline - it is recommended to update
Newlib to at least that commit or to cherry pick the two commits
on
Ok, admittedly, the following patch [v2] is cleaner and the assumption
that the llvm-mc assembler is used is also inside the backend assembler
spec.
OK for mainline?
* * *
Note: I tried to see whether this patch plus the comment 14 patch makes
a difference. While the testcase itself (and in our
PR119367 is about an overflow related to debug views, if those are not
supported directly by the assembler. The problem is that
dw2_asm_output_delta yields a 2-byte variable, which isn't sufficient.
However, as the draft patch of comment 14 shows, dw2_asm_output_delta_uleb128
can be used to avoid
Jakub Jelinek wrote:
It of course makes a lot of sense. declare simd is used mostly on the host
in the wild, outside of target regions.
On "normal" Linux for instance in /usr/include/bits/math-vector.h,
albeit most of the time -fopenmp is not active such that the "simd"
attribute is used inste
Hi Sandra,
Sandra Loosemore wrote:
On 8/26/25 05:26, Jakub Jelinek wrote:
I wouldn't emit sorry for targets where we already implement it
"correctly",
i.e. at least all targets which have NULL
targetm.simd_clone.compute_vecsize_and_simdlen
There the argument transformation is identity.
That
Dear Jakub, dear Sandra, hello world,
Jakub Jelinek wrote:
Starting with OpenMP 5.2, the spec explicitly says differently for C++:
"The function variant is determined by base language standard name lookup
rules ([basic.lookup]) of variant-name using the argument types at the call
site..."
I th
Hi Yuao,
Yuao Ma wrote:
I addressed some review comments and included additional feedback.
Thanks for the update. I know that the patch is incomplete, but as I
started with bootstrapping, I start with the following. I bet the issues
are known to you:
First, your patch does not bootstrap* h
Hi Yua,
Yuao Ma wrote:
I noticed that this patch was already committed as
r16-3154-g587b8a62f50179!
Sorry for the delay in committing. I committed it + wrote an email about
it during my vacation, but seemingly, I forgot to hit "send". (I found
it in my draft emails.)
Tobias
Sandra Loosemore wrote:
This patch fixes a number of problems with parser error checking of
"declare variant", especially in the C front end.
...
gcc/c/ChangeLog
* c-parser.cc (c_finish_omp_declare_variant): Rework diagnostic
code. Do not record variant if there are errors. Ma
Am 25.08.25 um 08:13 schrieb Jakub Jelinek:
On Sun, Aug 24, 2025 at 08:16:32PM -0600, Sandra Loosemore wrote:
As noted in PR middle-end/121630, GCC seems to think that the "simd"
construct selector on "declare variant" implies that the variant
function accepts vectorized arguments, although this
Sandra Loosemore wrote:
As noted in the issue, the C++ front end has deeper problems: […]
Some real solution ought to be included as part of fixing PR118791.
okay.
gcc/c/ […]
gcc/cp/ […]
gcc/fortran/
PR middle-end/118839
* trans-openmp.cc (gfc_trans_omp_declare_variant): Error i
Hi Yuao,
Yuao Ma wrote:
Hi Paul,
On 7/31/2025 6:02 AM, Paul Richard Thomas wrote:
That's exactly how I had a mind to do it. You beat me to it 🙁
Just get on, polish the patch and add more tests.
I've updated the patch with improvements to both the functionality and
test cases. It should now
Sandra Loosemore wrote:
This patch fixes a number of problems with parser error checking of
"declare variant", especially in the C front end.
The new C testcase unprototyped-variant.c added by this patch used to
ICE when gimplifying the call site, at least in part because the
variant was being r
Yuao Ma wrote:
On 8/6/2025 10:57 PM, Yuao Ma wrote:
On 8/6/2025 4:32 PM, Tobias Burnus wrote:
Hi Yuao,
thanks for your patch. I have two nits:
* There is no diagnostic for -std=f2018 (or lower);
can you add the 'gfc_notify_std (GFC_STD_F2023' ?
Done. Testcase added.
Given th
Committed as r16-3063-gb399a0084bc962 fix the file name in
download_prerequisites fixed.
And ...
Richard Biener wrote:
On Wed, 6 Aug 2025, Tobias Burnus wrote:
OK for mainline? (Requires a prior update of 'infrastructure').
-gmp='gmp-6.2.1.tar.bz2'
…
+gmp='gm
This patch updates contrib/download_prerequisites to download
newer versions (the latest) of GMP, MPFR and MPC.
Main reason is a newer MPFR that provides C23 functions,
additionally, the usual bug fixes or the new "away from zero"
rounding in MPC might turn out to be useful. GMP also claims
bette
Hi Yuao,
thanks for the patch. — I have one nit:
Yuao Ma wrote:
This patch cleans up a duplicate test driver.
Regression-tested. OK for trunk?
...
Subject: [PATCH] fortran: cleanup duplicate tests for
c_f_pointer_shape_driver; nfc
'; nfc'?
tests_2_driver and tests_4_driver are identical,
Hi Yuao,
thanks for your patch. I have two nits:
* There is no diagnostic for -std=f2018 (or lower);
can you add the 'gfc_notify_std (GFC_STD_F2023' ?
* I have a minor documentation nit; current wording is
at https://gcc.gnu.org/onlinedocs/gfortran/C_005fF_005fPOINTER.html
Namely, ...
Yu
Hello Kwok, hi all,
Kwok Cheung Yeung wrote:
Currently, GCC accepts an allocate clause (to use a specific memory
allocator and alignment) on the OpenMP target construct, but it has no
effect - memory is always allocated with the defaults.
This patch causes memory for privatized variables (i.e
Hi Kwok,
Kwok Cheung Yeung wrote:
I find the following warning odd:
#pragma omp target map(iterator(i3=0:10, j3=0:20, k3=0:30), to:
x[i3+j3], y[j3+k3], z[k3+i3])
;
/* { dg-warning "iterator variable .i3. not used in clause
expression" "" { target *-*-* } .-2 } */
/* { dg-warnin
Now reworded and committed - see attached +
https://gcc.gnu.org/gcc-16/changes.html
Thanks for the comments!
Tobias
commit b420d69be557f55635d869b770e80789977ffcf4
Author: Tobias Burnus
Date: Wed Jul 30 09:41:30 2025 +0200
gcc-16/changes.html: Update OpenACC support
diff --git a
Hi Gerald,
Gerald Pfeifer wrote:
+ OpenACC 3.4: In Fortran, named constants (PARAMETER) used as
+ var in clauses are now accepted (and ignored as not being
+ required). The support for named constants has been added to the
+ specification and GCC for better compatibility with exi
Thanks for proof reading and noting the missing patch …
Gerald Pfeifer:
On Tue, 29 Jul 2025, Tobias Burnus wrote:
Update https://gcc.gnu.org/gcc-16/changes.html for some OpenACC
features that went in; while small and some of them rather new
(OpenACC 3.4 was only released in June 2025), they
Update https://gcc.gnu.org/gcc-16/changes.html for some OpenACC
features that went in; while small and some of them rather new
(OpenACC 3.4 was only released in June 2025), they all show up
in real-world code and, hence, are important to users.
Any comments before (or after) I pushed the changes?
When initially adding MI300 support, the buffer invalidation
before atomics was messed up - it should have been buffer_wbl2
(wbl2 = write back L2). With this patch in place, most test
cases work on MI300A :-)
Without this change, there were several multi-teams issues.
MI300A testing shows: large
Hi Andrew,
thanks for all the suggestions and the review!
Andrew Stubbs wrote:
...
+ /* CDNA3: VALU writes VGPR/VCC: v_readlane, v_readfirstlane,
v_cmp,
+ v_add_*i/u, v_sub_*i/u, v_div_*scale - followed by:
+ - VALU reads SGPR as constant requires 1 waite state
+ -
Hi Andrew,
Andrew Stubbs wrote:
+static bool
+gcn_v_cmp_insn_p (attr_type type)
+{
+ return type == TYPE_VOPC || type == TYPE_VOP3A;
}
There are many vop3a encoded instructions. I don't understand how this
uniquely identifies v_cmp instructions?
It doesn't - how about an attribute variant?
Tiny cleanup patch - as fallout of trying to understand MI300 and
its fails better
(A) Replace 's_nop 0x0; s_nop 0x0; s_nop 0x0' by 's_nop 0x2'.
Advantage: fewer instructions - this helps on the hardware side by
permitting more follow-up instructions in the instruction cache and
it reduces the f
There are still issues with MI300, some which get resolved by adding s_nop.
One case where it is exactly known where the s_nop fixes a fail is for
libgomp.c-c++-common/task-detach-10.c, where libgomp/single.c's
GOMP_single_start() never returns 1, such that 'omp single' is
never executed. Adding
Andrew Stubbs wrote:
On 24/07/2025 16:49, Tobias Burnus wrote:
Andrew Stubbs wrote:
On 24/07/2025 14:25, Tobias Burnus wrote:
+/* Device requires CDNA1-style manually inserted wait states for
AVGPRs. */
+#define TARGET_AVGPR_CDNA3_NOPS TARGET_CDNA3
This is not for CDNA1, and not for AVGPRS
Andrew Stubbs wrote:
On 24/07/2025 14:25, Tobias Burnus wrote:
+/* Device requires CDNA1-style manually inserted wait states for
AVGPRs. */
+#define TARGET_AVGPR_CDNA3_NOPS TARGET_CDNA3
This is not for CDNA1, and not for AVGPRS.
I have deleted it and use now TARGET_CDNA3 directly
Hello Andrew, hello world,
some instructions take a bit longer but permit that the next
instruction is processed while finishing the work. That works
well - and speeds up the calculation - unless the next instruction
relies on those being available.
Which combinations instructions are affected ar
Kwok Cheung Yeung wrote:
Subject: [PATCH 03/11] openmp: Add support for iterators in 'target update'
clauses (C/C++)
This adds support for iterators in 'to' and 'from' clauses in the
'target update' OpenMP directive.
* * *
+ c_parser_error (parser, "% or % clause with modifier "
+
Hi Kwok,
thanks for the patch; looks quite good, but I have a couple of remarks:
Kwok Cheung Yeung wrote:
Date: Sat, 3 May 2025 20:24:26 +
Subject: [PATCH 02/11] openmp: Add support for iterators in map clauses
(C/C++)
This adds preliminary support for iterators in map clauses within Op
PING⁴
June 25, 2025, Tobias Burnus wrote:
PING³
June 2, 2025 Tobias Burnus wrote:
Tobias Burnus wrote:
PING²
On May 12, 2025, Tobias Burnus wrote:
PING.
There is actually a minor update as meanwhile CUDA 12.8 was
released that added the 'f' suffix and sm_103 and sm_121.
Still, t
Kwok Cheung Yeung wrote:
Date: Wed, 27 Nov 2024 21:49:12 +
Subject: [PATCH 01/11] openmp: Refactor handling of iterators
Move code to calculate the iteration size and to generate the iterator
expansion loop into separate functions.
Use OMP_ITERATOR_DECL_P to check for iterators in clause de
Kwok Cheung Yeung wrote:
This patch fixes an ICE due to a null-pointer dereference when finding
the symbol for the procedure name in a declare variant directive,
which occurs because the result of gfc_find_sym_tree is being
dereferenced unconditionally. The result is now checked, and the
symbo
Now, finally pushed as r16-2213-g451b6dbf475959.
Tobias
On June 27, 2025, Tobias Burnus wrote:
Background: In real-world code, one can find:
!$ACC DECLARE COPYIN(c1es, c2es, ...)
as here for the ICON weather model. This clearly implies that other
compilers accept and, potentially, require
On Sunday, July 6, 2025, Yuao Ma wrote:
>>> Since I don't have root/sudo permissions on my devbox, I manually
downloaded
>>> and compiled the autoconf 2.69 tarball. This means there might be some
minor
>>> discrepancies compared to the version shipped with OS distributions.
In principle, having a
Background: In real-world code, one can find:
!$ACC DECLARE COPYIN(c1es, c2es, ...)
as here for the ICON weather model. This clearly implies that other
compilers accept and, potentially, require those. For better
compatibility with real-world use, the just released OpenACC 3.4 now
permits PARAME
Hi Yuao,
Yuao Ma wrote:
>//but the testcases don't seem to be conditionalized on this. Would the
>//new tests fail if gcc is built against an insufficiently recent version
>//of mpfr,
…
The test case is indeed conditionalized, though in a different manner
than you
might expect. The condition
PING³
June 2, 2025 Tobias Burnus wrote:
Tobias Burnus wrote:
PING²
On May 12, 2025, Tobias Burnus wrote:
PING.
There is actually a minor update as meanwhile CUDA 12.8 was
released that added the 'f' suffix and sm_103 and sm_121.
Still, the pattern remains the same; hence, a normal
, but that's probably
overkill until we need it.
I think it would good to properly use the right sc0/sc1/nt for memory
access, but I concur that's something for a bit later.
Tobias
commit 750bc2899844d662aee93476f2da63fce68535d9
Author: Tobias Burnus
Date: Tue Jun 24 23:55:27
This patch adds the OpenACC routines acc_attach and acc_detach.
However, in order to avoid the generation of a temporary, which
breaks this feature, a special case had to be added to
gfc_trans_call.
Otherwise, I think it completes the Fortran additions of existing
C/C++ functions, by adding this
This is more based on documentation reading that on testing
as still only limited MI300 testing has been done and seemingly
this code does not usually get touched.
MI300's "9.1.10 Memory Scope and Temporal Control" distinguishes
between scalar memory (9.1.10.1) for which a single control bit exis
252cafa5045498a0e0c480ee6d48c136232
Author: Tobias Burnus
Date: Mon Jun 23 23:24:56 2025 +0200
OpenACC: Add 'if' clause to 'acc wait' directive
OpenACC 3.0 added the 'if' clause to four directives; this patch only adds
it to 'acc wait'.
ently look as follows:
https://gcc.gnu.org/onlinedocs/libgomp/Memory-allocation.html and
https://gcc.gnu.org/onlinedocs/libgomp/OMP_005fALLOCATOR.html
Tobias Burnus wrote:
Alex wrote:
Here is a follow up patch for documentation of the omp.h allocators,
[…]
I want the table in there somewhere bu
he attached patch, which
assumes a sufficiently new nvptx-tools (and has no xfails).
→ r16-1536-gea43b99537591b
Tobias
commit ea43b99537591b1103da3961c61f1cbfae968859
Author: Tobias Burnus
Date: Tue Jun 17 11:33:09 2025 +0200
OpenMP: Fix implicit 'declare target'
This fixes an issue with implicit declare target.
'' has:
template … endl() { ... }
...
extern template ostream& endl(ostream&);
which leads to a decl that is 'extern' but still
has the full function body available.
Result: On the offload side, 'endl' is present
but the functions it calls
Hi Yuao,
Yuao Ma wrote:
Fixed in this patch. Thinking about tex is always a pain...
> Additionally, I think all "half-revolutions" should be "half
revolutions"
Thanks! I have another nit:
* intrinsic.texi: Add new doc. Reorder doc for atand.
The first part is not really clear. I hav
Hi Yuao,
Yuao Ma wrote:
This patch is a follow-up to commit r16-938-ge8fdd55ec90749. In this
patch, we
add intrinsic documentation for the newly added trig functions with
half-revolutions. We also reorder the documentation for `atand` to
place it in
correct alphabetical order.
When I try to
This add experimental support for AMD Instinct MI300. It has been
tested to support hello world, but not yet much beyond (to come).
OK for mainline?
Tobias
gcn: Add experimental MI300 (gfx942) support
As gfx942 and gfx950 belong to gfx9-4-generic, the latter two are also added.
Note that there
libgomp.texi
[and hence onlinedocs/libgomp]. But that's for another day.)
Tobias
commit 152a09eae9d5852e2f628c3e8b3156bf744e63cf
Author: Tobias Burnus
Date: Tue Jun 10 06:21:12 2025 +0200
gcc-16/changes.html + projects/gomp/: OpenMP/OpenACC update
* gcc-16/changes.html: Add O
Most builtins in omp-builtins.def is marked as LEAF. At a glance,
that's surprising but looking at the functions, it turns out
that most of them just call 'gomp_thread ()' which is a simple
inline function such that no function call remains.
However, that's not true for all - and omp_get_mapped_p
I have now pushed those patches as:
r16-1262-g387209938d2c47
OpenMP: Add omp_get_initial_device/omp_get_num_devices builtins
r16-1261-g214b5d66c54613
builtins.def: Enable OpenMP/OpenACC builtins also with -fno-nonansi-builtins
Tobias
Currently, using the ISO version of C and C++ will disable the
OpenMP and OpenACC intrinsics, which is rather surprising. The
reason is that those imply -fno-nonansi-builtins and the
OpenMP/OpenACC are marked as non-ansi builtins.
While the latter is true, -fopenmp/-fopenacc seems to be rather
or
As a user reported, --with=arch= did not support the newer devices,
as we forgot to update the list.
While we still have lists to update, this one can be replaced by
checking directly against the .def file.
There was another list that we didn't update - in install.texi:
https://gcc.gnu.org/insta
Sandra Loosemore wrote:
gcc/ChangeLog
PR c++/120518
* omp-general.cc (omp_device_num_check): Look inside a
CLEANUP_POINT_EXPR when trying to optimize special cases.
LGTM. Thanks,
Tobias
[…]
+ tree t = *device_num;
+ if (TREE_CODE (t) == CLEANUP_POINT_EXPR)
+t =
This came up when looking at some context selectors that use 'target_device',
but is largely unrelated to it. (target_device has its own special casing).
Namely, it makes omp_get_initial_device and omp_get_num_devices PURE,
which attributes don't permit for Fortran - based on the state that
the n
Hi Sandra, hello world,
Sandra Loosemore wrote:
On 6/2/25 12:15, Tobias Burnus wrote:
The problem is that 'int'/'int*' became 'omp_interop_rc_t ret_code'
and 'omp_interop_rc_t *ret_code'.
...
I think the patch just confuses readers, as-is. Plus it h
Joseph Myers wrote:
On Sun, 1 Jun 2025, Yuao Ma wrote:
For MPFR versions older than 4.2.0, we've included our own folding functions.
I think the normal practice in GCC would be to avoid the optimizations
when the MPFR support is absent, instead of working around the absence
with possibly less a
Not really new - but as the topic came up elsewhere (OpenMP issue 4455),
I had a second thought about this and I think it make sense to add a note.
GCC uses the OpenMP 6.0 version.
The problem is that 'int'/'int*' became 'omp_interop_rc_t ret_code'
and 'omp_interop_rc_t *ret_code'.
For C++, pas
Tobias Burnus wrote:
PING²
On May 12, 2025, Tobias Burnus wrote:
PING.
There is actually a minor update as meanwhile CUDA 12.8 was
released that added the 'f' suffix and sm_103 and sm_121.
Still, the pattern remains the same; hence, a normal PING.
On April 25, 2025, Tobias Bu
Attached patch adds omp_target_memset and omp_target_memset_async
permitting to set (potentially large) data on the device to a
certain value - in particular to '\0'.
It uses 'memset' on the host (and for shared memory, e.g. via
requires unified_shared_memory/self_maps). For nvptx, cuMemsetD8
is
I have now committed the second declare mapper patch, submitted
by Julian at
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629367.html
again it is based in the associated OG15 commit (kudos to all doing the
rediffs):
69fd51954fc OpenMP: Support OpenMP 5.0 "declare mapper" directives
Sandra Loosemore wrote:
Like the attached V2 patch?
LGTM.
However, I think in metadirective-condition-template.C the
"scan-tree-dump" should now be changed to "scan-tree-dump-times", given
that there are several tests.
Thanks,
Tobias
@Jason – The idea is make semantics.cc's maybe_convert_cond callable
from parser.cc + pt.cc, i.e. to make it a non-static function.
Any reasons not do so?
Sandra Loosemore wrote:
[…] By using the existing front-end
hooks for the implicit conversion to bool in conditional expressions,
we also ge
Hi Harald,
Harald Anlauf wrote:
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_cospi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:2305:3: error: 'mpfr_fmod_ui'
was not declared in this scop
Hi Yuao,
Yuao Ma wrote:
[…]
Done.
LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749.
Thanks for the patch!
Tobias
Sandra Loosemore wrote:
The new testcase included in this patch used to ICE in gcc after
diagnosing the first error, and in g++ it only diagnosed the error in
the first metadirective, ignoring the second one. The solution is to
make error recovery in the C front end more like that in the C++ fro
Sandra Loosemore wrote:
It's not clear whether a metadirective in a loop nest is supposed to
be valid, but GCC certainly shouldn't be ICE'ing after diagnosing it
as an error.
gcc/c/ChangeLog
PR c/120180
* c-parser.cc (c_parser_omp_metadirective): Only consume the
token i
We somehow missed to implement these OpenACC 2.6 functions (the
Fortran routines are newer: 3.3). It is actually used, at least,
by two SPEC hpc/accel (soma + lbm) tests (and OpenACC_VV) - and
it was trivial to implement, which was my workaround to make them
compile.
Besides adding the same-devic
Yuao Ma wrote:
PR113152
If you run your patch through
./contrib/gcc-changelog/git_email.py
0001-fortran-add-constant-input-support-for-trig-function.patch
you will notice that the PR is not recognized. The format as mentioned before is "PR
component/number". Namely:
"PR fortran/113
processing the offload code + deciding
at runtime whether host fallback, gcn or nvptx offloading is
used.)
I will backport this also to GCC 15 as it is affected as well.
Tobias
commit 5d6ed6d604ff949b650e48fa4eaed3ec8b6489c1
Author: Tobias Burnus
Date: Mon May 26 19:50:40 2025 +0200
c-
Jakub Jelinek wrote:
There is also BIND_EXPR_VARS, dunno if that should be walked instead or
in addition.
The usage is to ensure that variables are mapped with lambdas (→
closure_vars_accessed.add (…)) but not if they are local variables (→
data->local_decls.add (var)).
The 'closure_vars_ac
PING²
On May 12, 2025, Tobias Burnus wrote:
PING.
There is actually a minor update as meanwhile CUDA 12.8 was
released that added the 'f' suffix and sm_103 and sm_121.
Still, the pattern remains the same; hence, a normal PING.
On April 25, 2025, Tobias Burnus wrote:
The idea of
Committed as r16-838-gb3d07ec7ac2ccd. When adding the testcase
originally in r15-6963-gfdeceba59bee60 seemingly the compile-time
FAIL when nvptx offload compilation is enabled was missed.
That's now fixed by using an effective target, avoiding the FAIL.
That there is an issue with such code was
This fixes a GCC 12-to-16 Regression related to an
unexpected empty BIND_EXPR_BLOCK, where nonetheless
aBIND_EXPR exists - just by not walking the hence non-existing variables
binding to that block.
Any comments before I commit this to mainline? I also intent to backport
it relatively soonish to
Hi,
Yuao Ma wrote:
I'm pretty swamped for the next couple of days
Same issue here - hence, I haven't completed the review ...
You're absolutely right that the best way to keep changes minimal is to just
rename the `*resolve*` function.
I missed the
-gfc_resolve_trigd,
+gfc_resolve_trig,
c
Hi Yuao,
first comments, I still need to look again at some changes, especially
at simplify.cc.
Yuao Ma wrote:
This patch introduces constant input support for trigonometric functions,
including those involving half-revolutions. Both valid and invalid
inputs have
been thoroughly tested, as
Tobias Burnus wrote:
As mentioned before, the following error is bogus as there is no
requirement to have the base function defined or declared before
the variant function (or at all, or to be available in any TU):
foo.c: In function ‘my.ompvariant1’:
foo.c:4:7: error: no previous declaration
The next two commits fix two mapping issues, the rest are test cases
that should have been in GCC 15 pre-branch. Namely:
r15-9707-g57f73c3956572f OpenMP/Fortran: Fix allocatable-component
mapping of derived-type array comps r15-9706-gab9ca3a8b1af41 OpenMP:
Fix mapping of zero-sized arrays w
Hi Thomas,
coming back to the patch itself – having sent comments in previous email.
As mentioned, I think you either want to have:
* Check whether the runtime knows that USM is supported for the default
device (that is a non-host device), i.e. a no-host device is available
with 'required uni
1 - 100 of 1453 matches
Mail list logo
