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

2022-12-07 Thread Richard Sandiford via Gcc-patches
"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 targe

Re: AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]

2022-12-07 Thread Richard Sandiford via Gcc-patches
"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 trunk,

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

2022-12-07 Thread Florian Weimer via Gcc-patches
* 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 > @option{-fsani

[PATCH v4, rs6000] Enable have_cbranchcc4 on rs6000

2022-12-07 Thread HAO CHEN GUI via Gcc-patches
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 ch

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

2022-12-07 Thread Kewen.Lin via Gcc-patches
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], Andre

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

2022-12-07 Thread Lulu Cheng
在 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 43c9ee8bffe..448

Add zstd support to libbacktrace

2022-12-07 Thread Ian Lance Taylor via Gcc-patches
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 t

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

2022-12-07 Thread Joseph Myers
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 x86_64-pc-

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

2022-12-07 Thread Steve Kargl via Gcc-patches
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 atta

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

2022-12-07 Thread Patrick Palka via Gcc-patches
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 int

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

2022-12-07 Thread Jakub Jelinek via Gcc-patches
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 w

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

2022-12-07 Thread Jeff Law via Gcc-patches
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 opportunitie

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

2022-12-07 Thread David Faust via Gcc-patches
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): Likewi

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

2022-12-07 Thread David Faust via Gcc-patches
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 n

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

2022-12-07 Thread David Faust via Gcc-patches
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 gen

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

2022-12-07 Thread David Faust via Gcc-patches
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 (3)

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

2022-12-07 Thread Harald Anlauf via Gcc-patches
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 02a

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

2022-12-07 Thread Raphael Moreira Zinsly
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. 20

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

2022-12-07 Thread Marek Polacek via Gcc-patches
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 mention

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

2022-12-07 Thread Patrick Palka via Gcc-patches
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

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

2022-12-07 Thread Jonathan Wakely via Gcc-patches
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 2

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

2022-12-07 Thread Joseph Myers
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 b/gcc/testsui

[committed] preprocessor: Enable __VA_OPT__ for C2x

2022-12-07 Thread Joseph Myers
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. A

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

2022-12-07 Thread Julian Brown
> 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, comp_mark:

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

2022-12-07 Thread Julian Brown
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: AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]

2022-12-07 Thread Pop, Sebastian via Gcc-patches
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:

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

2022-12-07 Thread Max Filippov via Gcc-patches
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 wi

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

2022-12-07 Thread François Dumont via Gcc-patches
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] range-op-float, v2: frange_arithmetic tweaks for MODE_COMPOSITE_P

2022-12-07 Thread Aldy Hernandez via Gcc-patches
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 range_next

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

2022-12-07 Thread Aldy Hernandez via Gcc-patches
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 th

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

2022-12-07 Thread Richard Biener via Gcc-patches
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 stmt

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

2022-12-07 Thread Kyrylo Tkachov via Gcc-patches
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 t

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

2022-12-07 Thread Wilco Dijkstra via Gcc-patches
Hi Andreas, Thanks for the report, I've committed the fix: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108006 Cheers, Wilco

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

2022-12-07 Thread Wilco Dijkstra via Gcc-patches
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 b/gcc/config/aarch64/a

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

2022-12-07 Thread Andrew MacLeod via Gcc-patches
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 d

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

2022-12-07 Thread Tobias Burnus
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 35

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

2022-12-07 Thread Tobias Burnus
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 impl

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

2022-12-07 Thread Jakub Jelinek via Gcc-patches
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 i

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

2022-12-07 Thread Jakub Jelinek via Gcc-patches
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 n

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

2022-12-07 Thread Cupertino Miranda via Gcc-patches
> 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. >> Ho

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

2022-12-07 Thread Iain Sandoe via Gcc-patches
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 back-p

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

2022-12-07 Thread Aldy Hernandez via Gcc-patches
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: + // ibm-ldouble-format

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

2022-12-07 Thread Jakub Jelinek via Gcc-patches
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 -. > > +

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

2022-12-07 Thread Aldy Hernandez via Gcc-patches
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 return

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

2022-12-07 Thread Segher Boessenkool
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 move

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

2022-12-07 Thread Aldy Hernandez via Gcc-patches
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 v5 2/4] OpenMP/OpenACC: Rework clause expansion and nested struct handling

2022-12-07 Thread Julian Brown
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 1/2] select .rodata for const volatile variables.

2022-12-07 Thread Cupertino Miranda via Gcc-patches
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 t

Re: [PATCH] Fix a few incorrect accesses.

2022-12-07 Thread Andrew MacLeod via Gcc-patches
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? Remnants

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

2022-12-07 Thread Andreas Schwab via Gcc-patches
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 (interna

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

2022-12-07 Thread Tobias Burnus
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 mappe

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

2022-12-07 Thread Kito Cheng via Gcc-patches
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 >

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

2022-12-07 Thread Richard Biener via Gcc-patches
The following avoids CSE of &ps->wp to &ps->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 &ps->wp.hwnd into &(*ps) and use that to base the vector data references

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

2022-12-07 Thread Richard Sandiford via Gcc-patches
"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 (Th

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

2022-12-07 Thread Jakub Jelinek via Gcc-patches
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 impl

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

2022-12-07 Thread Jiufu Guo via Gcc-patches
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. An

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

2022-12-07 Thread arthur . cohen
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

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

2022-12-07 Thread Kewen.Lin via Gcc-patches
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 help

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

2022-12-07 Thread Jakub Jelinek via Gcc-patches
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: > > * gcc.targe

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

2022-12-07 Thread Richard Biener via Gcc-patches
The following avoids a bogus -Wstringop-overflow diagnostic by properly recognizing that &d->m_mutex cannot be nullptr in C++ even if m_mutex is at offset zero. The frontend already diagnoses a &d->m_mutex != nullptr comparison and the following transfers this knowledge to the middle-end which see

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

2022-12-07 Thread Martin Liška
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] ipa/105676 - pure attribute suggestion for const function

2022-12-07 Thread Richard Biener via Gcc-patches
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, pushe

Re: [PATCH] Fix a few incorrect accesses.

2022-12-07 Thread Thomas Schwinge
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] doc: Correct a clerical error in the document.

2022-12-07 Thread Richard Sandiford via Gcc-patches
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 > --- a/gcc/doc/rtl

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

2022-12-07 Thread Iain Buclaw via Gcc-patches
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 from

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

2022-12-07 Thread Richard Sandiford via Gcc-patches
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 v3 16/19] modula2 front end: bootstrap and documentation tools

2022-12-07 Thread Gaius Mulley via Gcc-patches
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. > > I

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

2022-12-07 Thread Helmut Grohne
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. gcc/

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

2022-12-07 Thread Martin Liška
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 send

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

2022-12-07 Thread Richard Sandiford via Gcc-patches
"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 Rust front-end v4 20/46] gccrs: Add wrapper for make_unique

2022-12-07 Thread Thomas Schwinge
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. >> --- >> gcc/r

Re: AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]

2022-12-07 Thread Richard Sandiford via Gcc-patches
"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 bootstra

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

2022-12-07 Thread Arsen Arsenović via Gcc-patches
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 change

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

2022-12-07 Thread Jakub Jelinek via Gcc-patches
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 v2 1/2] Allow subtarget customization of CC1_SPEC

2022-12-07 Thread Iain Sandoe
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 2022-1

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

2022-12-07 Thread Tobias Burnus
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: Arnulfstraß