[PATCH] ipa-prop: Fix another case of missing BUILT_IN_UNREACHABLE_TRAP handling [PR106258]

On Wed, Feb 22, 2023 at 07:46:46PM +0100, Richard Biener wrote: > Ok for stage1 Thanks. In that case, can we get at least following into GCC 13, another spot that handles in IPA just BUILT_IN_UNREACHABLE and not BUILT_IN_UNREACHABLE_TRAP? Bootstrapped/regtested on x86_64-linux and i686-linux.

Re: [PATCH] vect: Check that vector factor is a compile-time constant

Hi Jeff, We do not have two independent implementations: my work is 100% based on the vector intrinsic foundation in upstream GCC. In fact I have only added two core patterns, vector add and subtract, that are based on the existing vector intrinsics implementation: (define_expand "add3"  

Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant

>> I would object to anyone trying to push forward an autovec implementation >> into >> gcc-13. We're well past that point IMHO, even if the changes only >> affected the RISC-V backend. Yes, I am agree with Jeff's opinion. I finished infrastructure (intrinsic and VSETVL PASS) of RVV now. Now,

Re: [PATCH] vect: Check that vector factor is a compile-time constant

On 2/22/23 10:54, Michael Collison wrote: Juzhe, I disagree with this comment. There are many stakeholders for autovectorization and waiting until GCC 14 is not a viable solution for us as well as other stakeholders ready to begin work on autovectorization. As we discussed I have been

[PATCH 2/2] xtensa: Fix missing mode warnings in machine description

gcc/ChangeLog: * config/xtensa/xtensa.md (zero_cost_loop_start, zero_cost_loop_end, loop_end): Add missing "SI:" to PLUS RTXes. --- gcc/config/xtensa/xtensa.md | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/gcc/config/xtensa/xtensa.md

[PATCH 1/2] xtensa: Fix non-fatal regression introduced by b2ef02e8cbbaf95fee98be255f697f47193960ec

In commit b2ef02e8cbbaf95fee98be255f697f47193960ec, the sibling call insn included (use (reg:SI A0_REG)) to fix the problem, which added a USE chain unconditionally to the data flow of register A0 during the sibling call. As a result, df_regs_ever_live_p (A0_REG) returns true, so even if register

Re: Ping^2: [PATCH+wwwdocs 0/8] A small Texinfo refinement

On Tue, 21 Feb 2023, Arsen Arsenović wrote: > Ping. Like last time, I rebased the series. Thank you! > The first two times around, I did not notice there's dedicated > maintainers for the documentation component, and so, I am adding Gerald, > Joseph and Sandra to CC this time. Apologies for

Re: [PATCH+wwwdocs 0/8] A small Texinfo refinement

On Fri, 27 Jan 2023, Arsen Arsenović via Gcc-patches wrote: > Some patches from this patchset appear to have been dropped due to size > limits. I neglected to compress them last night. Here they are again: I pushed 2/8 after spot checking the huge patch. Just 2 out of 970 hunks FAILED (for

Re: [committed 034/103] gccrs: dump: Emit visibility when dumping items

Just noticed this by chance: How does this patch constitute a functional change (that matches the ChangeLog)? It looks it only adds an empty line to the source code? Gerald On Tue, 21 Feb 2023, arthur.co...@embecosm.com wrote: > From: Arthur Cohen > > gcc/rust/ChangeLog: > > *

Re: [PATCH 3/7] **/*.texi: Reorder index entries

Hi Arsen, On Fri, 27 Jan 2023, Arsen Arsenović via Gcc-patches wrote: > gcc/d/ChangeLog: > > * implement-d.texi: Reorder index entries around @items. > > gcc/ChangeLog: > > * doc/cfg.texi: Reorder index entries around @items. > * doc/cpp.texi: Ditto. > *

[PATCH] c++: variable template and targ deduction [PR108550]

In this test, we get a bogus error because we failed to deduce the auto in constexpr auto is_pointer_v = is_pointer::value; to bool. Then ensure_literal_type_for_constexpr_object thinks the object isn't literal and an error is reported. This is another case of the interaction between tf_partial

Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant

Besides, since GCC 13 currently is on stage 4. Unlike the infrastructure that I am building for intrinsic && auto-vec which is safe and will not affect the original RISC-V port functionality. Auto-vectorization will potentially affect the orignal RISC-V port functionality which is not safe to

Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant

Currently, upstream GCC is not ready to support auto-vec. I am building the basic infrastructure of RVV and need more testing. I can't support auto-vec now since it depends on the infrastructure tha I am building. I have open source "rvv-next" in RISC-V foundation repo which fully support

Re: [wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

On Wed, 22 Feb 2023, Tobias Burnus wrote: > Comments? Suggestions? OpenMP update for gcc-13/changes.html + projects/gomp/ --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html + Reverse offload is now supported with nvptx and AMD GCN devices. Would it make sense to sort AMD

[pushed] wwwdocs: gcc-9: Various changes around -flive-patching

This is on top of what Qing nicely added back in 2018 - backlog on my disk. Pushed. Gerald --- htdocs/gcc-9/changes.html | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html index 7dfae89c..89c20985 100644 ---

Re: [PATCH] c-family: avoid compile-time-hog in c_genericize [PR108880]

On Wed, Feb 22, 2023 at 05:37:45PM -0500, Marek Polacek wrote: > This fixes a compile-time hog with UBSan. This only happened in cc1 but > not cc1plus. The problem is ultimately that c_genericize_control_stmt/ > STATEMENT_LIST -> walk_tree_1 doesn't use a hash_set to remember visited > nodes, so

[PATCH] c-family: avoid compile-time-hog in c_genericize [PR108880]

This fixes a compile-time hog with UBSan. This only happened in cc1 but not cc1plus. The problem is ultimately that c_genericize_control_stmt/ STATEMENT_LIST -> walk_tree_1 doesn't use a hash_set to remember visited nodes, so it kept on recursing for a long time. We should be able to use the

Re: [PR100127] Test for coroutine header in clang-compatible tests

On Feb 17, 2023, Iain Sandoe wrote: > As a matter of interest, do you know of any other compiler claiming > “__clang__” (I have > treated that as safe so far). We've had (or found it more convenient, not sure) to do that to gcc on some recent combinations of version and target of vxworks, for

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

On Feb 21, 2023, Richard Earnshaw wrote: > Rather than scanning for the triplet, a better test would be > { xfail { arm_eabi } } Indeed, thanks. Here's the updated patch, retested. Ok to install? [PR105224] C++ modules and AAPCS/ARM EABI clash on inline key methods From: Alexandre Oliva

[PATCH] c++: unevaluated array new-expr size constantness [PR108219]

Here we're mishandling the unevaluated array new-expressions due to a supposed non-constant array size ever since r12-5253-g4df7f8c79835d569, made us no longer perform constant evaluation of non-manifestly-constant expressions within unevaluated contexts. This shouldn't make a difference here

Re: [PATCH] tree, v2: Add 3 argument fndecl_built_in_p

> Am 22.02.2023 um 19:34 schrieb Jakub Jelinek : > > On Wed, Feb 22, 2023 at 12:35:24PM +, Jonathan Wakely wrote: >> Yes, I was right, it doesn't work in gcc 4.8. This does though (with >> typos above fixed too, and actually tested on GCC 4.8.5): > > I think we don't need the

Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

On 2/22/23 13:03, Tamar Christina wrote: -Original Message- From: Andrew MacLeod Sent: Wednesday, February 22, 2023 4:42 PM To: Tamar Christina ; Richard Biener ; Richard Sandiford Cc: Tamar Christina via Gcc-patches ; nd ; j...@ventanamicro.com Subject: Re: [PATCH 1/2]middle-end:

[PATCH] tree, v2: Add 3 argument fndecl_built_in_p

On Wed, Feb 22, 2023 at 12:35:24PM +, Jonathan Wakely wrote: > Yes, I was right, it doesn't work in gcc 4.8. This does though (with > typos above fixed too, and actually tested on GCC 4.8.5): I think we don't need the DECL_FUNCTION_CODE (node) in every recursive call, we can just pass

Re: [PATCH 1/2] PR target/107299: Fix build issue when long double is IEEE 128-bit

On Wed, Feb 22, 2023 at 06:37:39PM +0800, Kewen.Lin wrote: > Thanks for working on this! If updating libgcc source to workaround this > issue > is the best option we can have at this moment, it's fine. Thanks. Yes, I agree that it does not fix the root issue. > Comparing to one > previous

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

> -Original Message- > From: Andrew MacLeod > Sent: Wednesday, February 22, 2023 4:42 PM > To: Tamar Christina ; Richard Biener > ; Richard Sandiford > Cc: Tamar Christina via Gcc-patches ; nd > ; j...@ventanamicro.com > Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of

New Romanian PO file for 'cpplib' (version 13.1-b20230212)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Romanian team of translators. The file is available at: https://translationproject.org/latest/cpplib/ro.po (This file,

Contents of PO file 'cpplib-13.1-b20230212.ro.po'

cpplib-13.1-b20230212.ro.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.

Re: [PATCH 2/2] Rework 128-bit complex multiply and divide.

On Wed, Feb 22, 2023 at 06:13:07PM +0800, Kewen.Lin wrote: > These two above paragraphs look a bit out of date (two patches now). :) Thanks. > IIUC this patch actually fixes a latent issue, so it is independent of the one > fixing the bootstrapping issue, right? This updated version of patch

Re: [PATCH] vect: Check that vector factor is a compile-time constant

Juzhe, I disagree with this comment. There are many stakeholders for autovectorization and waiting until GCC 14 is not a viable solution for us as well as other stakeholders ready to begin work on autovectorization. As we discussed I have been moving forward with patches for

Sort-of ping for [PATCH] testsuite: Handle "packed" targets in c-c++-common/auto-init-7.c and -8.c

> From: Qing Zhao > Date: Wed, 15 Feb 2023 20:30:00 +0100 > Thank you for fixing this issue. Thanks! Although you're not holding an approver position I'm tempted to take that as approval, as you're the author of that test. This being a patch of no particular significance and having seen no

New German PO file for 'cpplib' (version 13.1-b20230212)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the German team of translators. The file is available at: https://translationproject.org/latest/cpplib/de.po (This file,

Contents of PO file 'cpplib-13.1-b20230212.de.po'

cpplib-13.1-b20230212.de.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.

Re: [PATCH] Skip module_cmi_p and related unsupported module test

On Feb 20, 2023, Jason Merrill wrote: > This seems like an ugly kludge around that problem, but I don't have > any clever ideas of a better approach short of rewriting everything. > So, OK with a comment explaining the rationale above your overridden > "unsupported". > Also, your commit subject

Re: [PATCH] [arm] disable aes-1742098 mitigation for a72 combine tests

Hello, Kyrylo, On Feb 20, 2023, Kyrylo Tkachov wrote: > So rather than overriding this awkward part with > -mno-fix-cortex-a57-aes-1742098 I'd rather just select a different > CPU that enables that fusion and isn't afflicted by this workaround, > such as -mcpu=cortex-a53. Sounds good to me. >

Re: [PATCH] vect: Check that vector factor is a compile-time constant

Richard how would I check for a full masked main vector loop? On 2/22/23 03:20, Richard Biener wrote: On Wed, Feb 22, 2023 at 12:03 AM Michael Collison wrote: While working on autovectorizing for the RISCV port I encountered an issue where vect_do_peeling assumes that the vectorization factor

Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

On 2/15/23 13:42, Andrew MacLeod wrote: On 2/15/23 12:50, Andrew MacLeod wrote: On 2/15/23 12:13, Tamar Christina wrote: On 2/15/23 07:51, Tamar Christina wrote: void operator_plus::wi_fold (irange , tree type,     const wide_int _lb, const wide_int _ub,    

Contents of PO file 'cpplib-13.1-b20230212.es.po'

cpplib-13.1-b20230212.es.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.

New Spanish PO file for 'cpplib' (version 13.1-b20230212)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Spanish team of translators. The file is available at: https://translationproject.org/latest/cpplib/es.po (This file,

Re: [PATCH] Share work directories

On Wed, Feb 22, 2023 at 4:22 AM Yash Shinde wrote: > > From: Khem Raj > > Fix configure and Makefile files to read the defaults.hand t-oe from build > directory, > so that the source can be shared between gcc-cross-initial, > gcc-cross-intermediate, gcc-cross, gcc-runtime, > and also the sdk

Re: [PATCH] Accept pmf-vbit-in-delta extra warning

On Feb 17, 2023, Jason Merrill wrote: > On 2/17/23 23:02, Alexandre Oliva wrote: >> >> cp_build_binary_op, that issues -Waddress warnings, issues an extra >> warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect >> when comparing a pointer-to-member-function literal with null.

Re: [PATCH] Share work directories

Hi! On 2023-02-22T04:19:04-0800, Yash Shinde wrote: > From: Khem Raj > > Fix configure and Makefile files to read the defaults.h and t-oe from build > directory, > so that the source can be shared between gcc-cross-initial, > gcc-cross-intermediate, gcc-cross, gcc-runtime, > and also the sdk

[PATCH] vect: Check that vector factor is a compile-time constant

> gcc/ > > * tree-vect-loop-manip.cc (vect_do_peeling): Verify > that vectorization factor is a compile-time constant. > > --- > gcc/tree-vect-loop-manip.cc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/tree-vect-loop-manip.cc

Re: [PATCH] [vxworks] make wint_t and wchar_t the same distinct type

Hello, Jason, On Feb 17, 2023, Jason Merrill wrote: > On 2/17/23 23:04, Alexandre Oliva wrote: >> >> We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and >> wchar_t mapped to the same underlying type, but this caused a glitch >> in Wstringop-overflow-6.C: on vxworks, wint_t is

Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

On 2/22/23 08:06, Tamar Christina wrote: Hi Andrew, all the range-op integer code is in gcc/range-op.cc.  As this is a basic binary operation, you should be able to get away with implementing a single routine,  wi_fold () which adds 2 wide int bounds  together and returns a result.  THis si

Re: [PATCH] [PR77760] [libstdc++] encode __time_get_state in tm

On Feb 17, 2023, Jakub Jelinek wrote: > My worry is that people often invoke the time_get APIs on uninitialized > struct tm. Yeah. I thought you meant get(), but it looks like you meant do_get() as well. I seem to have overread the permissions to overwrite tm members, to update its current

Re: Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types (was: Modula-2 / Rust: Many targets failing)

Hi Thomas, On 2/22/23 12:25, Thomas Schwinge wrote: Hi! Richard, you may remember your words from "ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O -fno-tree-scev-cprop -ftree-vectorize": Ideally we'd never use lang_hooks.types.type_for_mode (or

Re: [PATCH] [arm] adjust tests for quotes around +cdecp

On 2/22/23 13:38, Alexandre Oliva wrote: Hello, Christophe, On Feb 20, 2023, Christophe Lyon wrote: On 2/17/23 08:17, Alexandre Oliva via Gcc-patches wrote: Back when quotes were added around "+cdecp" in the "coproc must be a constant immediate" error in arm-builtins.cc, tests for that

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

Hi Andrew, > > all the range-op integer code is in gcc/range-op.cc.  As this is a basic > binary operation, you should be able to get away with implementing a > single routine,  wi_fold () which adds 2 wide int bounds  together and > returns a result.  THis si the implelemntaion for

Re: [PATCH] cygwin: Don't try to support multilibs [PR107998]

On 2/22/23 09:25, Jakub Jelinek wrote: Hi! As discussed in the PR, t-cygwin-w64 file has been introduced in 2013 and has one important problem, two different multilib options -m64 and -m32, but MULTILIB_DIRNAMES with just one word in it. Before the genmultilib sanity checking was added, my

Re: [PATCH] cygwin: Don't try to support multilibs [PR107998]

On 2/22/23 09:25, Jakub Jelinek wrote: Hi! As discussed in the PR, t-cygwin-w64 file has been introduced in 2013 and has one important problem, two different multilib options -m64 and -m32, but MULTILIB_DIRNAMES with just one word in it. Before the genmultilib sanity checking was added, my

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

> -Original Message- > From: Andrew MacLeod > Sent: Wednesday, February 15, 2023 6:43 PM > To: Tamar Christina ; Richard Biener > ; Richard Sandiford > Cc: Tamar Christina via Gcc-patches ; nd > ; j...@ventanamicro.com > Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of

Re: [PATCH] tree: Add 3 argument fndecl_built_in_p

On Wed, Feb 22, 2023 at 1:17 PM Jonathan Wakely via Gcc-patches wrote: > > On Wed, 22 Feb 2023 at 11:49, Richard Biener wrote: > > > > On Wed, 22 Feb 2023, Jakub Jelinek wrote: > > > > > On Wed, Feb 22, 2023 at 09:52:06AM +, Richard Biener wrote: > > > > > The following testcase ICEs because

Re: [PATCH] RISC-V: When the TARGET_COMPUTE_MULTILIB hook is implemented, check the version of each extension.

Hi Jin: Curious, did you introduce version info into the multi-lib path in your donwstream GCC? I suspect we need a more complete solution to deal with the multiversion issue, so it would be great if you can provide more experience with this part? Thanks :) On Wed, Feb 22, 2023 at 5:44 PM Jin

Re: [PATCH] [arm] adjust tests for quotes around +cdecp

Hello, Christophe, On Feb 20, 2023, Christophe Lyon wrote: > On 2/17/23 08:17, Alexandre Oliva via Gcc-patches wrote: >> >> Back when quotes were added around "+cdecp" in the "coproc must be >> a constant immediate" error in arm-builtins.cc, tests for that message >> lagged behind. Fixed

Re: [PATCH] tree: Add 3 argument fndecl_built_in_p

On Wed, 22 Feb 2023 at 12:16, Jonathan Wakely wrote: > > On Wed, 22 Feb 2023 at 11:49, Richard Biener wrote: > > > > On Wed, 22 Feb 2023, Jakub Jelinek wrote: > > > > > On Wed, Feb 22, 2023 at 09:52:06AM +, Richard Biener wrote: > > > > > The following testcase ICEs because we still have

[PATCH] Pass CXXFLAGS_FOR_BUILD to avoid build failure errors.

From: Richard Purdie If CXXFLAGS contains something unsupported by the build CXX, we see build failures (e.g. using -fmacro-prefix-map for the target). ChangeLog: * Makefile.in: Regenerate. * Makefile.tpl: Add missing CXXFLAGS_FOR_BUILD overrides. Signed-off-by: Richard

[PATCH] libgcc_s: Use alias for __cpu_indicator_init instead of symver

From: Khem Raj Adapter from https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00899.html This fix was debated but hasnt been applied gcc upstream since they expect musl to support '@' in symbol versioning which is a sun/gnu versioning extention. This patch however avoids the need for the '@'

[PATCH] Share work directories

From: Khem Raj Fix configure and Makefile files to read the defaults.hand t-oe from build directory, so that the source can be shared between gcc-cross-initial, gcc-cross-intermediate, gcc-cross, gcc-runtime, and also the sdk build which use a separate build directory compared to source

[committed] RISC-V: Make the test condition more strict for gcc.target/riscv/_Float16-zhinxmin-1.c

LTO might generate random string for the section name, which might contain `mv`, then might cause random false alarm. gcc/testsuite/ChangeLog: * gcc.target/riscv/_Float16-zhinxmin-1.c: Tweak test condition. --- gcc/testsuite/gcc.target/riscv/_Float16-zhinxmin-1.c | 2 +- 1 file

Re: [PATCH] tree: Add 3 argument fndecl_built_in_p

On Wed, 22 Feb 2023 at 11:49, Richard Biener wrote: > > On Wed, 22 Feb 2023, Jakub Jelinek wrote: > > > On Wed, Feb 22, 2023 at 09:52:06AM +, Richard Biener wrote: > > > > The following testcase ICEs because we still have some spots that > > > > treat BUILT_IN_UNREACHABLE specially but not

Re: [PATCH] RISC-V: Don't report an error until the link phase if suitable multilib isn't found.

This will break some scenario which is to build anything by themself, which does not use any header or library from the builtin one. So that's why the spec needs to guard so many conditions, no -nostartfiles, -nodefaultlibs, -nolibc and -nostdlib appears.

Re: Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types (was: Modula-2 / Rust: Many targets failing)

On Wed, 22 Feb 2023, Thomas Schwinge wrote: > Hi! > > Richard, you may remember your words from > "ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O > -fno-tree-scev-cprop -ftree-vectorize": > > > Ideally we'd never use lang_hooks.types.type_for_mode (or

Re: [PATCH] tree: Add 3 argument fndecl_built_in_p

On Wed, 22 Feb 2023, Jakub Jelinek wrote: > On Wed, Feb 22, 2023 at 09:52:06AM +, Richard Biener wrote: > > > The following testcase ICEs because we still have some spots that > > > treat BUILT_IN_UNREACHABLE specially but not BUILT_IN_UNREACHABLE_TRAP > > > the same. > > This patch uses

Contents of PO file 'cpplib-13.1-b20230212.fr.po'

cpplib-13.1-b20230212.fr.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.

New French PO file for 'cpplib' (version 13.1-b20230212)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the French team of translators. The file is available at: https://translationproject.org/latest/cpplib/fr.po (This file,

Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types (was: Modula-2 / Rust: Many targets failing)

Hi! Richard, you may remember your words from "ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O -fno-tree-scev-cprop -ftree-vectorize": > Ideally we'd never use lang_hooks.types.type_for_mode (or _for_size) in the > middle-end but had a pure middle-end

[PATCH] tree: Add 3 argument fndecl_built_in_p

On Wed, Feb 22, 2023 at 09:52:06AM +, Richard Biener wrote: > > The following testcase ICEs because we still have some spots that > > treat BUILT_IN_UNREACHABLE specially but not BUILT_IN_UNREACHABLE_TRAP > > the same. This patch uses (fndecl_built_in_p (node, BUILT_IN_UNREACHABLE)

[wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

Update the release notes and the impl.status for some newer changes: Reverse offload for AMD GCN now works. Additionally, I thinko for TR11 was fixed (propagating a libgomp.texi change): the other clauses already support 'strict' as listed elsewhere (earlier OpenMP version and alreaddy

Contents of PO file 'cpplib-13.1-b20230212.uk.po'

cpplib-13.1-b20230212.uk.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.

New Ukrainian PO file for 'cpplib' (version 13.1-b20230212)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Ukrainian team of translators. The file is available at: https://translationproject.org/latest/cpplib/uk.po (This file,

Re: [PATCH, rs6000] Merge two vector shift when their sources are the same

Hi Haochen, on 2023/2/20 10:04, HAO CHEN GUI wrote: > Hi, > This patch merges two "vsldoi" insns when their sources are the > same. Particularly, it is simplified to be one move if the total > shift is multiples of 16 bytes. > > Bootstrapped and tested on powerpc64-linux BE and LE with no >

Re: [PATCH 1/2] PR target/107299: Fix build issue when long double is IEEE 128-bit

Hi Mike, on 2023/2/3 13:49, Michael Meissner wrote: > This patch is a repost of a patch: > > | Date: Thu, 19 Jan 2023 11:37:27 -0500 > | Subject: [PATCH] PR target/107299: Fix build issue when long double is IEEE > 128-bit > | Message-ID: > > This patch updates the IEEE 128-bit types used in

Re: [PATCH] rs6000: fmr gets used instead of faster xxlor [PR93571]

On 21/02/23 7:39 pm, Segher Boessenkool wrote: > On Tue, Feb 21, 2023 at 06:00:52PM +0530, Ajit Agarwal wrote: >> On 21/02/23 4:34 pm, Segher Boessenkool wrote: >>> Please domn't use a switch, it isn't needed. Instead use the "isa" >>> attribute (with p7v here), and put the preferred

[PATCH] RISC-V: Don't report an error until the link phase if suitable multilib isn't found.

When suitable multilib isn't found, an error is not reported until the link period, which is inconsistent with the result of compiling option `-print-multi-directory`. For example, when suitable multilib isn't found, the return result of `-print-multi-directory` is the default value '.', while the

New template for 'gcc' made available

Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'gcc' has been made available to the language teams for translation. It is archived as:

Rust: Move void_list_node init to common code (was: [PATCH] Move void_list_node init to common code)

Hi! On 2022-09-14T16:06:55+0200, Richard Biener via Gcc-patches wrote: > All frontends replicate this, so move it. At that time, the Rust front end was not yet in master branch; I've now pushed to master branch commit 334f23d83261997ca89d8919b94b97aa22003a65 "Rust: Move void_list_node init to

GCC 13.0.1 Status Report (2023-02-22)

Status == The GCC development branch which will become GCC 13 is in regression and documentation fixing mode (Stage 4) until we reach zero P1 regressions and branch for the release. We are making slow progress towards this goal, new bugs are coming in at a high pace. Please help triaging

Re: [PATCH 2/2] Rework 128-bit complex multiply and divide.

Hi Mike, on 2023/2/3 13:53, Michael Meissner wrote: > This patch reworks how the complex multiply and divide built-in functions are > done. Previously we created built-in declarations for doing long double > complex > multiply and divide when long double is IEEE 128-bit. The old code also did

New template for 'cpplib' made available

Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'cpplib' has been made available to the language teams for translation. It is archived as:

Re: [PATCH] cgraph: Handle BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE in more spots [PR106258]

On Wed, 22 Feb 2023, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs because we still have some spots that > treat BUILT_IN_UNREACHABLE specially but not BUILT_IN_UNREACHABLE_TRAP > the same. > > The following patch fixes that, bootstrapped/regtested on x86_64-linux and > i686-linux,

Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

在 2023/2/22 下午5:35, WANG Xuerui 写道: On 2023/2/22 17:30, Lulu Cheng wrote: 在 2023/2/21 下午9:56, WANG Xuerui 写道: Hi, On 2023/2/21 21:03, Lulu Cheng wrote: 在 2023/2/21 下午3:41, Xi Ruoyao 写道: On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote: Like la264 only has 40 effective bits of

[PATCH] RISC-V: When the TARGET_COMPUTE_MULTILIB hook is implemented, check the version of each extension.

When there is an extension with different versions, the result of the TARGET_COMPUTE_MULTILIB hook is generally wrong, so the version needs to be considered. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_subset_list::match_score): Match the version of each

Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

On 2023/2/22 17:30, Lulu Cheng wrote: 在 2023/2/21 下午9:56, WANG Xuerui 写道: Hi, On 2023/2/21 21:03, Lulu Cheng wrote: 在 2023/2/21 下午3:41, Xi Ruoyao 写道: On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote: Like la264 only has 40 effective bits of virtual address space. I'm OK with the

Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

在 2023/2/21 下午9:56, WANG Xuerui 写道: Hi, On 2023/2/21 21:03, Lulu Cheng wrote: 在 2023/2/21 下午3:41, Xi Ruoyao 写道: On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote: Like la264 only has 40 effective bits of virtual address space. I'm OK with the change.  But the VA length is configurable

[PATCH] cygwin: Don't try to support multilibs [PR107998]

Hi! As discussed in the PR, t-cygwin-w64 file has been introduced in 2013 and has one important problem, two different multilib options -m64 and -m32, but MULTILIB_DIRNAMES with just one word in it. Before the genmultilib sanity checking was added, my understanding is that this essentially

[PATCH] cgraph: Handle BUILT_IN_UNREACHABLE_TRAP like BUILT_IN_UNREACHABLE in more spots [PR106258]

Hi! The following testcase ICEs because we still have some spots that treat BUILT_IN_UNREACHABLE specially but not BUILT_IN_UNREACHABLE_TRAP the same. The following patch fixes that, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2023-02-22 Jakub Jelinek PR

[PATCH] c++: Don't recurse on DECL_INITIAL for DECL_EXPR on non-VAR_DECLs [PR108606]

Hi! The r13-2965-g73d9b0e5947e16 change changed the line touched in this patch from return RECUR (tmp, want_rval); to return RECUR (DECL_INITIAL (tmp), want_rval); This is on DECL_EXPR handling code, where tmp can be lots of different trees and DECL_INITIAL unfortunately also means

Re: [PATCH] vect: Check that vector factor is a compile-time constant

On Wed, Feb 22, 2023 at 12:03 AM Michael Collison wrote: > > While working on autovectorizing for the RISCV port I encountered an > issue where vect_do_peeling assumes that the vectorization factor is a > compile-time constant. The vectorization is not a compile-time constant > on RISCV. > >