Re: [PATCH] RISC-V: Produce better code with complex constants [PR95632] [PR106602]

On Wed, Dec 07, 2022 at 05:55:17PM -0300, Raphael Moreira Zinsly wrote: > Due to RISC-V limitations on operations with big constants combine > is failing to match such operations and is not being able to > produce optimal code as it keeps splitting them. By pretending we > can do those operations

[PATCH] c++: modules and std::source_location::current() def arg [PR100881]

We currently declare __builtin_source_location with a const void* return type instead of the true type (const std::source_location::__impl*), and later when folding this builtin we just obtain the true type via name lookup. But the below testcase demonstrates this name lookup approach seems to

Re: [PATCH] Fortran: handle zero-sized arrays in ctors with typespec [PR108010]

On Wed, Dec 07, 2022 at 09:57:20PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > we need to be careful about zero-sized arrays in arithmetic > reductions (unary & binary), as we otherwise may hit a NULL > pointer dereference on valid code. > > The actual fix is straightforward, see

Re: [PATCH] doc: Correct a clerical error in the document.

在 2022/12/7 下午6:05, Richard Sandiford 写道: Lulu Cheng writes: gcc/ChangeLog: * doc/rtl.texi: Correct a clerical error in the document. --- gcc/doc/rtl.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi index

Re: [PATCH] libstdc++: Add error handler for

Looks perfect to me, thanks. On 06/12/22 22:44, Jonathan Wakely wrote: On Wed, 30 Nov 2022 at 18:00, François Dumont wrote: On 30/11/22 14:07, Jonathan Wakely wrote: On Wed, 30 Nov 2022 at 11:57, Jonathan Wakely wrote: On Wed, 30 Nov 2022 at 11:54, Jonathan Wakely wrote: On Wed, 30 Nov

Re: [PATCH] Fix aarch64 PR 99657: ICE with SVE types used without an error

on 2022/12/7 20:55, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi Richard, >> >> on 2022/12/7 17:16, Richard Sandiford wrote: >>> "Kewen.Lin" writes: Hi, In the recent discussion on how to make some built-in type only valid for some target features efficiently[1],

Add zstd support to libbacktrace

This patch adds zstd support to libbacktrace, to support the new linker option --compress-debug-sections=zstd. The zstd format is fairly complicated, so it's likely that there are some bugs here. It does pass the tests, at least. Unfortunately this decompressor only runs at about 1/3 the speed

[PATCH v4, rs6000] Enable have_cbranchcc4 on rs6000

Hi, This patch enables "have_cbranchcc4" on rs6000 by defining a "cbranchcc4" expander. "have_cbrnachcc4" is a flag in ifcvt.cc to indicate if branch by CC bits is invalid or not. With this flag enabled, some branches can be optimized to conditional moves. Compared to last version, the main

[committed] c: Diagnose auto constexpr used with a type

The constraints on auto in C2x disallow use with other storage-class specifiers unless the type is inferred from an initializer. That includes constexpr; add the missing checks for this case (the combination of auto, constexpr and a type specifier). Bootstrapped with no regressions for

Re: [PATCH] range-op-float, v2: Fix up frange_arithmetic [PR107967]

OK, thanks. Aldy On 12/7/22 16:49, Jakub Jelinek wrote: On Wed, Dec 07, 2022 at 04:26:14PM +0100, Aldy Hernandez wrote: This chunk... ...is quite similar to this one. Could you abstract this? It differs in various small details, plus comment content. Anyway, here it is reworked such that

[committed] preprocessor: Enable __VA_OPT__ for C2x

C2x supports __VA_OPT__, so adjust libcpp not to pedwarn for uses of it (or of not passing any variable arguments to a variable-arguments macro) in standard C2x mode. I didn't try to duplicate existing tests for the details of the feature, just verified -pedantic-errors handling is as expected.

[PATCH] c++: ICE with concepts TS multiple auto deduction [PR101886]

In extract_autos_r, we need to reset TYPE_CANONICAL for the template type parameter after adjusting its index, otherwise we end up with a comptypes ICE for the below testcase. Note that such in-place type adjustment isn't generallly safe to do since the type could be the TYPE_CANONICAL of another

[PATCH] RISC-V: Produce better code with complex constants [PR95632] [PR106602]

Due to RISC-V limitations on operations with big constants combine is failing to match such operations and is not being able to produce optimal code as it keeps splitting them. By pretending we can do those operations we can get more opportunities for simplification of surrounding instructions.

Re: [PATCH] RISC-V: Produce better code with complex constants [PR95632] [PR106602]

On 12/7/22 13:55, Raphael Moreira Zinsly wrote: Due to RISC-V limitations on operations with big constants combine is failing to match such operations and is not being able to produce optimal code as it keeps splitting them. By pretending we can do those operations we can get more

[PATCH] PR tree-optimization/107985 - Ensure arguments to range-op handler are supported.

THis patch invalidates a range-op handler object if an operand type in the statement is not supported. This also triggered a check in stmt dependency resolution which assumed there must be a valid handler for any stmt with an appropriate LHS type... which is a false assumption. This should

RE: [PATCH] arm: fix mve intrinsics scan body tests for C++

Hi Andrea, > -Original Message- > From: Andrea Corallo > Sent: Wednesday, December 7, 2022 3:03 PM > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov ; Richard Earnshaw > ; Andrea Corallo > Subject: [PATCH] arm: fix mve intrinsics scan body tests for C++ > > Hi all, > > this patch is

Re: [PATCH][AArch64] Cleanup move immediate code

Hi Andreas, Thanks for the report, I've committed the fix: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108006 Cheers, Wilco

Re: AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]

Hi Richard, Please find attached a patch that follows your recommendations to generate the BTI_C instructions. Please let me know if the patch can be further improved. The patch passed bootstrap and regressions tests on arm64-linux. Thanks, Sebastian From:

[committed] testsuite: Add test for C90 auto with implicit int

Add a test for the case of auto with implicit int in C90 mode, which is incompatible with C2x semantics (I missed adding such a test when implementing C2x auto). Tested for x86_64-pc-linux-gnu. * gcc.dg/c90-auto-1.c: New test. diff --git a/gcc/testsuite/gcc.dg/c90-auto-1.c

[PATCH 3/3] btf: correct generation for extern funcs [PR106773]

The eBPF loader expects to find entries for functions declared as extern in the corresponding BTF_KIND_DATASEC record, but we were not generating these entries. This patch adds support for the 'extern' linkage of function types in BTF, and creates entries for for them BTF_KIND_DATASEC records as

[PATCH 2/3] btf: fix 'extern const void' variables [PR106773]

The eBPF loader expects to find BTF_KIND_VAR records for references to extern const void symbols. We were mistakenly identifing these as unsupported types, and as a result skipping emitting VAR records for them. In addition, the internal DWARF representation from which BTF is produced does not

[PATCH 1/3] btf: add 'extern' linkage for variables [PR106773]

Add support for the 'extern' linkage value for BTF_KIND_VAR records, which is used for variables declared as extern in the source file. PR target/106773 gcc/ * btfout.cc (BTF_LINKAGE_STATIC): New define. (BTF_LINKAGE_GLOBAL): Likewise. (BTF_LINKAGE_EXTERN):

[PATCH 1/2] OpenMP/Fortran: Combined directives with map/firstprivate of same symbol

On Wed, 26 Oct 2022 12:39:39 +0200 Tobias Burnus wrote: > The ICE seems to be because gcc/fortran/trans-openmp.cc's > gfc_split_omp_clauses mishandles this as the dump shows the following: > >#pragma omp target firstprivate(a) map(tofrom:a) > #pragma omp parallel firstprivate(a) >

Re: [PATCH] range-op-float, v2: frange_arithmetic tweaks for MODE_COMPOSITE_P

OK, thanks. Aldy On 12/7/22 17:05, Jakub Jelinek wrote: On Wed, Dec 07, 2022 at 04:38:14PM +0100, Aldy Hernandez wrote: So, perhaps a combination of that, change frange_nextafter to do the above and change frange_arithmetic for the initial inexact rounding only to do it by hand using

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

> Hi Julian, > > I had a first quick lock at this patch, I should have a closer look > later. However, I stumbled over the following: > > On 20.10.22 18:14, Julian Brown wrote: > > typedef struct gfc_symbol > > { > > ... > >struct gfc_symbol *old_symbol; > > > >unsigned mark:1,

Re: [PATCH v5 3/4] OpenMP: Pointers and member mappings

Hi Julian, I think this patch is OK; however, at least for gimplify.cc Jakub needs to have a second look. As remarked for the 2/4 patch, I believe mapping 'map(tofrom: var%f(2:3))' should work without explicitly mapping 'map(tofrom: var%f)' (→ [TR11 157:21-26] (approx. [5.2 154:22-27], [5.1

[COMMITTED] AArch64: Fix assert in aarch64_move_imm [PR108006]

Ensure we only pass SI/DImode which fixes the assert. Committed as obvious. gcc/         PR target/108006 * config/aarch64/aarch64.c (aarch64_expand_sve_const_vector):         Fix call to aarch64_move_imm to use SI/DI. --- diff --git a/gcc/config/aarch64/aarch64.cc

Re: [PATCH] PR tree-optimization/107985 - Ensure arguments to range-op handler are supported.

On Wed, Dec 7, 2022 at 5:45 PM Andrew MacLeod via Gcc-patches wrote: > > THis patch invalidates a range-op handler object if an operand type in > the statement is not supported. > > This also triggered a check in stmt dependency resolution which assumed > there must be a valid handler for any

[PATCH 0/3] btf: fix BTF for extern items [PR106773]

Hi, This series fixes the issues reported in target/PR106773. I decided to split it into three commits, as there are ultimately three distinct issues and fixes. See each patch for details. Tested on bpf-unknown-none and x86_64-linux-gnu, no known regressions. OK to push? Thanks. David Faust

[PATCH] Fortran: handle zero-sized arrays in ctors with typespec [PR108010]

Dear all, we need to be careful about zero-sized arrays in arithmetic reductions (unary & binary), as we otherwise may hit a NULL pointer dereference on valid code. The actual fix is straightforward, see attached patch. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald From

Re: [PATCH v2 0/2] gcc: xtensa: allow dynamic configuration

On Mon, Nov 28, 2022 at 4:46 PM Max Filippov wrote: > > Hello, > > this series addresses the long standing issue with xtensa configuration > support by adding a way to configure toolchain for a specific xtensa > core at runtime using the xtensa-dynconfig [1] library as a plugin. > On a platform

Re: [PATCH] libstdc++: Add error handler for

On Wed, 7 Dec 2022 at 17:58, François Dumont wrote: > > Looks perfect to me, thanks. OK thanks, it's pushed to trunk now. > > On 06/12/22 22:44, Jonathan Wakely wrote: > > On Wed, 30 Nov 2022 at 18:00, François Dumont wrote: > >> On 30/11/22 14:07, Jonathan Wakely wrote: > >>> On Wed, 30 Nov

[PATCH] docs: Suggest options to improve ASAN stack traces

I got a complaint that while Clang docs suggest options that improve the quality of the backtraces ASAN prints (cf. ), our docs don't say anything to that effect. This patch amends that with a new paragraph. (It deliberately doesn't

Re: [PATCH] Fix aarch64 PR 99657: ICE with SVE types used without an error

"Kewen.Lin" writes: > on 2022/12/7 20:55, Richard Sandiford wrote: >> "Kewen.Lin" writes: >>> Hi Richard, >>> >>> on 2022/12/7 17:16, Richard Sandiford wrote: "Kewen.Lin" writes: > Hi, > > In the recent discussion on how to make some built-in type only valid for > some

Re: AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]

"Pop, Sebastian" writes: > Hi Richard, > > > Please find attached a patch that follows your recommendations to generate > the BTI_C instructions. > > Please let me know if the patch can be further improved. > > The patch passed bootstrap and regressions tests on arm64-linux. LGTM. OK for

Re: [PATCH] docs: Suggest options to improve ASAN stack traces

* Marek Polacek via Gcc-patches: > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > index 726392409b6..2de14466dd3 100644 > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -16510,6 +16510,14 @@ The option cannot be combined with > @option{-fsanitize=thread} or >

[PATCH] range-op-float: Fix up frange_arithmetic [PR107967]

Hi! The addition of PLUS/MINUS/MULT/RDIV_EXPR frange handlers causes miscompilation of some of the libm routines, resulting in lots of glibc test failures. A part of them is purely PR107608 fold-overflow-1.c etc. issues, say when the code does return -0.5 / 0.0; and expects division by zero to

Re: [PATCH Rust front-end v4 20/46] gccrs: Add wrapper for make_unique

arthur.co...@embecosm.com writes: > This is a wrapper for make_unique. We can likely get rid of this, as there > are other implementations available, or simply keep using the unique_ptr > constructor. > --- > gcc/rust/util/rust-make-unique.h | 35 > 1 file

Re: [PATCH Rust front-end v4 20/46] gccrs: Add wrapper for make_unique

Hi! On 2022-12-07T09:50:40+0100, Arsen Arsenović via Gcc-patches wrote: > arthur.co...@embecosm.com writes: > >> This is a wrapper for make_unique. We can likely get rid of this, as there >> are other implementations available, or simply keep using the unique_ptr >> constructor. >> --- >>

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

On 06.12.22 08:45, Tobias Burnus wrote: * As follow-up, libgomp.texi must be updated That is what the attached patch does – obviously, it is depending on the main patch. OK (once the main patch is in)? Tobias - Siemens Electronic Design Automation GmbH; Anschrift:

Re: [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC

Hi > On 7 Dec 2022, at 07:54, Sebastian Huber > wrote: > > > > On 07.12.22 08:10, Thomas Schwinge wrote: >> Hi! >> On 2022-12-07T07:04:10+0100, Sebastian Huber >> wrote: >>> On 06.12.22 22:06, Thomas Schwinge wrote: >>> I suppose I just fail to see some detail here, but: >>> On

Re: AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]

"Pop, Sebastian" writes: > Thanks Richard for your review and for pointing out the issue with BTI. > > > The current patch removes the existing BTI instruction, > > and then adds the BTI hint when expanding the patchable_area pseudo. Thanks. I still think... > The attached patch passed

Re: [PATCH] Fix aarch64 PR 99657: ICE with SVE types used without an error

"Kewen.Lin" writes: > Hi, > > In the recent discussion on how to make some built-in type only valid for > some target features efficiently[1], Andrew mentioned this patch which he > made previously (Thanks!). I confirmed it can help rs6000 related issue, > and noticed PR99657 is still opened, so

Re: [PATCH v3 16/19] modula2 front end: bootstrap and documentation tools

Martin Liška writes: > On 12/6/22 15:47, Gaius Mulley wrote: >> |Hi Martin, here is the revised patch having applied all previous >> recommendations: >> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603436.html. Is >> this ok now? Thanks for the improvement suggestions.| > > Hello. > >

Re: [PATCH] Fix aarch64 PR 99657: ICE with SVE types used without an error

Hi Richard, on 2022/12/7 17:16, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi, >> >> In the recent discussion on how to make some built-in type only valid for >> some target features efficiently[1], Andrew mentioned this patch which he >> made previously (Thanks!). I confirmed it can

[PATCH] preprocessor: __has_include_next should not error out [PR80755]

If __has_include_next reaches the end of the search path, it causes an error. The use of __has_include_next at the end of the search path is legal and it should return false instead. Bootstrapped and tested on x86_64-linux-gnu. Patched cross toolchain for i686-gnu (hurd) built many packages.

Re: [committed] onlinedocs: Add documentation links to gdc

Hi Gerald, Excerpts from Gerald Pfeifer's message of Dezember 6, 2022 2:13 pm: > On Tue, 6 Dec 2022, Iain Buclaw wrote: >> Now that the D front-end documentation has been generated and pushed to >> the site after r13-4421, this can be added to the main index page. >> >> This is a simple copy

Re: [PATCH] i386: fix assert (__builtin_cpu_supports ("x86-64") >= 0)

On Fri, Nov 25, 2022 at 01:57:35PM +0100, Martin Liška wrote: > PR target/107551 > > gcc/ChangeLog: > > * config/i386/i386-builtins.cc (fold_builtin_cpu): Use same path > as for PR103661. > * doc/extend.texi: Fix "x86-64" use. > > gcc/testsuite/ChangeLog: > > *

[committed] MAINTAINERS: Add myself as Rust front-end maintainer

From: Arthur Cohen Changelog: * MAINTAINERS: Add Arthur Cohen as Rust front-end maintainer. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 55c5ef95806..d2eea049667 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -165,6 +165,7 @@ D front

[PATCH V3] Use reg mode to move sub blocks for parameters and returns

Hi, When assigning a parameter to a variable, or assigning a variable to return value with struct type, "block move" are used to expand the assignment. It would be better to use the register mode according to the target/ABI to move the blocks if the parameter/return is passed through registers.

Re: [PATCH] Fix a few incorrect accesses.

Hi Andrew! On 2022-12-02T09:12:23-0500, Andrew MacLeod via Gcc-patches wrote: > This consists of 3 changes which stronger type checking has indicated > are non-compliant with the type field. I'm curious what that "stronger type checking" is? Grüße Thomas > I doubt they are super important

Re: [PATCH] i386: fix assert (__builtin_cpu_supports ("x86-64") >= 0)

On 12/2/22 10:54, Uros Bizjak wrote: > I'm not quite familiar with this part of the compiler, but if Jakub is > OK with the patch, consider it rubber-stamped OK. Thanks Uros, Jakub can you please approve it? Thanks, Martin > > Thanks, > Uros.

[PATCH] range-op-float: frange_arithmetic tweaks for MODE_COMPOSITE_P

Hi! As mentioned in PR107967, ibm-ldouble-format documents that +- has 1ulp accuracy, * 2ulps and / 3ulps. So, even if the result is exact, we need to widen the range a little bit. The following patch does that. I just wonder what it means for reverse division (the op1_range case), which we

Re: [PATCH v3 16/19] modula2 front end: bootstrap and documentation tools

On 12/6/22 15:47, Gaius Mulley wrote: > |Hi Martin, here is the revised patch having applied all previous > recommendations: > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603436.html. Is this > ok now? Thanks for the improvement suggestions.| Hello. It looks much better and I'm

Re: [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC

Sebastian Huber writes: > On 06.12.22 22:06, Thomas Schwinge wrote: >> Hi! >> >> I suppose I just fail to see some detail here, but: >> >> On 2022-11-21T08:25:25+0100, Sebastian >> Huber wrote: >>> gcc/ChangeLog: >>> >>>* gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined. >>>

Re: [PATCH] doc: Correct a clerical error in the document.

Lulu Cheng writes: > gcc/ChangeLog: > > * doc/rtl.texi: Correct a clerical error in the document. > --- > gcc/doc/rtl.texi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi > index 43c9ee8bffe..44858d12892 100644 > ---

[PATCH] ipa/105676 - pure attribute suggestion for const function

When a function is declared const (even though it technically accesses memory), ipa-modref discovering pureness shouldn't end up suggesting that attribute. The following thus exempts 'const' functions from ipa_make_function_pure handling. Bootstrapped and tested on x86_64-unknown-linux-gnu,

[PATCH] tree-optimization/104475 - bogus -Wstringop-overflow

The following avoids a bogus -Wstringop-overflow diagnostic by properly recognizing that >m_mutex cannot be nullptr in C++ even if m_mutex is at offset zero. The frontend already diagnoses a >m_mutex != nullptr comparison and the following transfers this knowledge to the middle-end which sees

[PATCH] range-op-float, v2: Fix up frange_arithmetic [PR107967]

On Wed, Dec 07, 2022 at 04:26:14PM +0100, Aldy Hernandez wrote: > This chunk... > > ...is quite similar to this one. Could you abstract this? It differs in various small details, plus comment content. Anyway, here it is reworked such that those various small details are based on whether inf is

[PATCH] range-op-float, v2: frange_arithmetic tweaks for MODE_COMPOSITE_P

On Wed, Dec 07, 2022 at 04:38:14PM +0100, Aldy Hernandez wrote: > > So, perhaps a combination of that, change frange_nextafter to do the above > > and change frange_arithmetic for the initial inexact rounding only to > > do it by hand using range_nextafter and starting from value. > > Either way

Re: [PATCH v5 2/4] OpenMP/OpenACC: Rework clause expansion and nested struct handling

Hi Julian, On 07.12.22 16:16, Julian Brown wrote: On Wed, 7 Dec 2022 15:54:42 +0100 Tobias Burnus wrote: If I understand Deepak's comment (on OpenMP.org's omp-lang list, sorry it is a nonpublic list) correctly, the following wording implies that a 'from: s.w[z:4]' for a pointer 's.w' also

Re: [PATCH] Fix aarch64 PR 99657: ICE with SVE types used without an error

"Kewen.Lin" writes: > Hi Richard, > > on 2022/12/7 17:16, Richard Sandiford wrote: >> "Kewen.Lin" writes: >>> Hi, >>> >>> In the recent discussion on how to make some built-in type only valid for >>> some target features efficiently[1], Andrew mentioned this patch which he >>> made previously

[PATCH] tree-optimization/106904 - bogus -Wstringopt-overflow with vectors

The following avoids CSE of >wp to >wp.hwnd confusing -Wstringopt-overflow by making sure to produce addresses to the biggest container from vectorization. For this I introduce strip_zero_offset_components which turns >wp.hwnd into &(*ps) and use that to base the vector data references on. That

Re: [PATCH v2 1/2] RISC-V: Support _Float16 type.

Hi Maciej: It’s not intentionally, I suspect that is because I port from our internal old gcc branch, will send patch to fix that later, thanks for catching this! Maciej W. Rozycki 於 2022年12月5日 週一，21:05寫道： > Hi Kito, > > I came across this issue while inspecting code and I have been wondering

Re: [PATCH][AArch64] Cleanup move immediate code

FAIL: gcc.target/aarch64/sve/cond_arith_5.c (internal compiler error: in aarch64_move_imm, at config/aarch64/aarch64.cc:5692) FAIL: gcc.target/aarch64/sve/const_3.c (internal compiler error: in aarch64_move_imm, at config/aarch64/aarch64.cc:5692) FAIL: gcc.target/aarch64/sve/loop_add_5.c

Re: [PATCH 1/2] select .rodata for const volatile variables.

Hi Jeff, First of all thanks for your quick review. Apologies for the delay replying, the message got lost in my inbox. > On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: >> Changed target code to select .rodata section for 'const volatile' >> defined variables. >> This change is in

Re: [PATCH v5 2/4] OpenMP/OpenACC: Rework clause expansion and nested struct handling

On Wed, 7 Dec 2022 15:54:42 +0100 Tobias Burnus wrote: > Hi Julian, > > If I understand Deepak's comment (on OpenMP.org's omp-lang list, sorry > it is a nonpublic list) correctly, the following wording implies that > a 'from: s.w[z:4]' for a pointer 's.w' also implies a mapping of > 's.w' - if

Re: [PATCH] range-op-float: frange_arithmetic tweaks for MODE_COMPOSITE_P

On 12/7/22 13:10, Jakub Jelinek wrote: Hi! As mentioned in PR107967, ibm-ldouble-format documents that +- has 1ulp accuracy, * 2ulps and / 3ulps. So, even if the result is exact, we need to widen the range a little bit. The following patch does that. I just wonder what it means for reverse

Re: [PATCH V3] Use reg mode to move sub blocks for parameters and returns

Hi! On Wed, Dec 07, 2022 at 08:00:08PM +0800, Jiufu Guo wrote: > When assigning a parameter to a variable, or assigning a variable to > return value with struct type, "block move" are used to expand > the assignment. It would be better to use the register mode according > to the target/ABI to

Re: [PATCH] range-op-float: Fix up frange_arithmetic [PR107967]

On 12/7/22 09:29, Jakub Jelinek wrote: Hi! The addition of PLUS/MINUS/MULT/RDIV_EXPR frange handlers causes miscompilation of some of the libm routines, resulting in lots of glibc test failures. A part of them is purely PR107608 fold-overflow-1.c etc. issues, say when the code does

Re: [PATCH] range-op-float: frange_arithmetic tweaks for MODE_COMPOSITE_P

On 12/7/22 16:31, Jakub Jelinek wrote: On Wed, Dec 07, 2022 at 04:21:09PM +0100, Aldy Hernandez wrote: On 12/7/22 13:10, Jakub Jelinek wrote: + switch (code) + { + case PLUS_EXPR: + case MINUS_EXPR: + //

Re: [PATCH 2/2] Corrected pr25521.c target matching.

> On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote: >> This commit is a follow up of bugzilla #107181. >> The commit /a0aafbc/ changed the default implementation of the >> SELECT_SECTION hook in order to match clang/llvm behaviour w.r.t the >> placement of `const volatile' objects. >>

Re: [PATCH v5 2/4] OpenMP/OpenACC: Rework clause expansion and nested struct handling

Hi Julian, If I understand Deepak's comment (on OpenMP.org's omp-lang list, sorry it is a nonpublic list) correctly, the following wording implies that a 'from: s.w[z:4]' for a pointer 's.w' also implies a mapping of 's.w' - if 's' is used inside the target region and, thus, gets implicitly

Re: [PATCH] Fix a few incorrect accesses.

On 12/7/22 05:08, Thomas Schwinge wrote: Hi Andrew! On 2022-12-02T09:12:23-0500, Andrew MacLeod via Gcc-patches wrote: This consists of 3 changes which stronger type checking has indicated are non-compliant with the type field. I'm curious what that "stronger type checking" is?

Re: [PATCH] range-op-float: frange_arithmetic tweaks for MODE_COMPOSITE_P

On Wed, Dec 07, 2022 at 04:21:09PM +0100, Aldy Hernandez wrote: > On 12/7/22 13:10, Jakub Jelinek wrote: > > + switch (code) > > + { > > + case PLUS_EXPR: > > + case MINUS_EXPR: > > + // ibm-ldouble-format documents 1ulp for + and -. > > +

[PATCH] c++, TLS: Support cross-tu static initialization for targets without alias support [PR106435].

This has been tested on x86_64 and arm64 Darwin and on x86_64 linux gnu. The basic patch is live in the homebrew macOS support and so has had quite wide coverage on non-trivial codebases. OK for master? Iain Since this actually fixes wrong code, I wonder if we should also consider