[r13-4590 Regression] FAIL: gfortran.dg/gomp/declare-variant-2.f90 -O (test for excess errors) on Linux/x86_64

On Linux/x86_64, 84f6f8a2a97f88be01e223c9c9dbab801a4f501f is the first bad commit commit 84f6f8a2a97f88be01e223c9c9dbab801a4f501f Author: Tobias Burnus Date: Sat Dec 10 08:34:04 2022 +0100 Fortran: Replace simple '.' quotes by %<.%> caused FAIL: gfortran.dg/gomp/declare-variant-2.f90

[PATCH v4 1/3] libcpp: reject codepoints above 0x10FFFF

Unicode does not support such values because they are unrepresentable in UTF-16. libcpp/ * charset.cc: Reject encodings of codepoints above 0x10. UTF-16 does not support such codepoints and therefore all Unicode rejects such values. Signed-off-by: Ben Boeckel ---

[PATCH v4 3/3] p1689r5: initial support

This patch implements support for [P1689R5][] to communicate to a build system the C++20 module dependencies to build systems so that they may build `.gcm` files in the proper order. Support is communicated through the following three new flags: - `-fdeps-format=` specifies the format for the

[PATCH v4 2/3] libcpp: add a function to determine UTF-8 validity of a C string

This simplifies the interface for other UTF-8 validity detections when a simple "yes" or "no" answer is sufficient. libcpp/ * charset.cc: Add `_cpp_valid_utf8_str` which determines whether a C string is valid UTF-8 or not. * internal.h: Add prototype for

[PATCH v4 0/3] RFC: P1689R5 support

Hi, This patch adds initial support for ISO C++'s [P1689R5][], a format for describing C++ module requirements and provisions based on the source code. This is required because compiling C++ with modules is not embarrassingly parallel and need to be ordered to ensure that `import some_module;`

Re: Rust front-end patches v4

Hi Martin! On 2022-12-09T14:24:18+0100, Martin Liška wrote: > I noticed a minor git issues when I tried [applying] the patches: [...] > > Can you please take a look at that? Done via "Fix whitespace errors". I've then force-updated the staging

Re: [PATCH] Fortran: reject bad SIZE argument while simplifying ISHFTC [PR106911]

On Sat, Dec 10, 2022 at 10:14:06PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > we should not try to simplify ISHFTC if the SIZE argument > is known to be outside the allowed range. It's better to > generate an error by terminating the simplification. > > Regtested on

[PATCH] Fortran: fix ICE on bad use of statement function [PR107995]

Dear all, I'm submitting the attached patch on behalf of Steve. It fixes an ICE that occurs on an obscure use of a statement function as argument to that function. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald From f717054e7d656588650f6d4fd5a03840c6dc9a9c Mon Sep 17

[PATCH] Fortran: reject bad SIZE argument while simplifying ISHFTC [PR106911]

Dear all, we should not try to simplify ISHFTC if the SIZE argument is known to be outside the allowed range. It's better to generate an error by terminating the simplification. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald From ae4438537fbc2ed04f3b0fb32d4e02b0ed6977a1

Re: [PATCH] contracts: Stop relying on mangling for naming .pre/.post clones

Hi Arsen, On 10 December 2022 14:14:59 CET, "Arsen Arsenović via Gcc-patches" wrote: > >Arsen Arsenović writes: > >> Afternoon, >> >> This change prevents contracts from emitting wrapper functions that have the >> same name as the original function, by moving the logic that disambiguates >>

[PATCH] coroutines: Build pointer initializers with nullptr_node [PR107768]

From: Andrew Pinski This is Andrew Pinski's patch, I just did testing, adjusted the test case and provided the Changelog. tested on x86-64-Darwin21, OK for trunk? Iain --- >8 --- The PR reports that using integer_zero_node triggers a warning for -Wzero-as-null-pointer-constant which comes from

Re: [PATCH] contracts: Stop relying on mangling for naming .pre/.post clones

Arsen Arsenović writes: > Afternoon, > > This change prevents contracts from emitting wrapper functions that have the > same name as the original function, by moving the logic that disambiguates > them > from the mangler into the build_contract_condition_function helper. > > Thanks, have nice

[PATCH] contracts: Stop relying on mangling for naming .pre/.post clones

If the mangler is relied on, functions with extern "C" on them emit multiple definitions of the same name. gcc/cp/ChangeLog: * contracts.cc (build_contract_condition_function): Add pre/post suffixes to pre- and postcondition clones. * mangle.cc (write_encoding): Don't

Re: [PATCH 2/2] OpenMP: Duplicate checking for map clauses in Fortran (PR107214)

Hi Julian, On 10.12.22 13:10, Julian Brown wrote: On Thu, 8 Dec 2022 13:04:20 +0100 Tobias Burnus wrote: All in all, I am fine with the patch - but I spotted some issues. ... I believe this patch covers all the above cases (hopefully appropriately generalised), at least for Fortran. I

Re: [PATCH 2/2] OpenMP: Duplicate checking for map clauses in Fortran (PR107214)

On Thu, 8 Dec 2022 13:04:20 +0100 Tobias Burnus wrote: > All in all, I am fine with the patch - but I spotted some issues. > > First, I think you need to set for some error cases mark = 0 to avoid > duplicated errors. Namely: > >! Outputs the error twice ('Symbol ‘y’ present on multiple >

Re: [PATCH] ivopts: Fix IP_END handling for asm goto [PR107997]

> Am 10.12.2022 um 10:40 schrieb Jakub Jelinek via Gcc-patches > : > > Hi! > > The following testcase ICEs, because the latch bb ends with > asm goto which has both fallthrough to the header and one or more labels > in the header too. In that case there is just a single edge out of the >

[PATCH] coroutines: Accept 'extern "C"' coroutines.

This came up in discussion and was relatively easy to 'fix' although it remains to be seen whether it was really intended. Tested on x86_64-darwin21. OK for trunk? Iain --- >8 --- As of now the standard does not appear to forbid this, and clang accepts. The use-cases are somewhat unclear

[PATCH v5 1/19] modula2 front end: changes outside gcc/m2, libgm2 and gcc/testsuite. Addendum.

This patch contains a replacement doc/gm2.texi which uses American spelling, all references to gm2 outside the gcc tree purged and the News/Obtaining sections have been removed. Also included at the end is the lang.opt file for reference. diff -ruw /dev/null

Re: [PATCH 1/4] contracts: Lowercase {MAYBE,NEVER}_CONTINUE

On Sat, 10 Dec 2022, 09:51 Arsen Arsenović via Libstdc++, < libstd...@gcc.gnu.org> wrote: > The lowercase constants are more consistent with the standard, and it is > unlikely that the uppercase versions would've been accepted. > > gcc/cp/ChangeLog: > > * contracts.cc: Rename references

[PATCH 4/4] contrib: Add dg-out-generator.pl

This script is a helper used to generate dg-output lines from an existing program output conveniently. It takes care of escaping Tcl and ARE stuff. contrib/ChangeLog: * dg-out-generator.pl: New file. --- contrib/dg-out-generator.pl | 67 + 1 file

[PATCH 3/4] contracts: Update testsuite against new default viol. handler format

This change was almost entirely mechanical. Save for two files which had very short matches, these changes were produced by two seds and a Perl script, for the more involved cases. The latter will be added in a subsequent commit. The former are as follows: sed -E -i "/dg-output/s/default

[PATCH 2/4] libstdc++: Improve output of default contract violation handler [PR107792]

From: Jonathan Wakely Make the output more readable. Don't output anything unless verbose termination is enabled at configure-time. libstdc++-v3/ChangeLog: PR libstdc++/107792 PR libstdc++/107778 * src/experimental/contract.cc (handle_contract_violation): Make

[PATCH 1/4] contracts: Lowercase {MAYBE,NEVER}_CONTINUE

The lowercase constants are more consistent with the standard, and it is unlikely that the uppercase versions would've been accepted. gcc/cp/ChangeLog: * contracts.cc: Rename references to contract_violation_continuation_mode constants to be lowercase. libstdc++-v3/ChangeLog:

[PATCH 0/4] c++: Small tweaks to contracts

Hi, This patchset includes minor tweaks to contracts, namely, lowercasing the continuation mode constants to align better with the rest of the standard, and updating the testsuite to match Jonathans new default contract violation handler (that patch is also included). Tested on

[PATCH] ivopts: Fix IP_END handling for asm goto [PR107997]

Hi! The following testcase ICEs, because the latch bb ends with asm goto which has both fallthrough to the header and one or more labels in the header too. In that case there is just a single edge out of the latch block, but still the asm goto is stmt_ends_bb_p statement, yet ivopts decides to

[PATCH] c++: Ensure !!var is not an lvalue [PR107065]

Hi! The TRUTH_NOT_EXPR case in cp_build_unary_op is one of the spots where we somewhat fold immediately using invert_truthvalue_loc. I've tried using return build1_loc (location, TRUTH_NOT_EXPR, boolean_type_node, arg); in there instead, but unfortunately that regressed

Re: [Patch] libgomp: Handle OpenMP's reverse offloads

On Sat, Dec 10, 2022 at 09:11:24AM +0100, Tobias Burnus wrote: > It is used as 'typedef struct reverse_splay_tree_node_s > *reverse_splay_tree_node;' in > > struct target_mem_desc { > > reverse_splay_tree_node rev_array; > } > > but also as > > struct gomp_device_descr > { > ... >

Re: [Patch] libgomp.texi: Reverse-offload updates (was: [Patch] libgomp: Handle OpenMP's reverse offloads)

Now that the reverse-offload patch is (nearly) in: On 07.12.22 09:08, Tobias Burnus wrote: On 06.12.22 08:45, Tobias Burnus wrote: * As follow-up, libgomp.texi must be updated Slight update to that uncommitted patch: I extended the nvptx entry to state that only one reverse-offload region

Re: [Patch] libgomp: Handle OpenMP's reverse offloads

On 09.12.22 15:44, Jakub Jelinek wrote: On Tue, Dec 06, 2022 at 08:45:07AM +0100, Tobias Burnus wrote: [...] I think we just shouldn't support libgomp plugins for 32-bit libgomp, only host fallback. If you want offloading, use 64-bit host... (I concur.) libgomp: Handle OpenMP's reverse