Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]

Hi Harald, On 13.12.22 23:27, Harald Anlauf wrote: Am 13.12.22 um 22:41 schrieb Tobias Burnus: Back to differences: 'diff -U0 -p -w' against the last GCC 11 branch shows: ... @@ -35,0 +37,2 @@ export_proto(cfi_desc_to_gfc_desc); +/* NOTE: Since GCC 12, the FE generates code to do the

[PATCH (pushed)] docs: document --param=ipa-sra-ptrwrap-growth-factor

gcc/ChangeLog: * doc/invoke.texi: Document ipa-sra-ptrwrap-growth-factor. --- gcc/doc/invoke.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 0459714d100..7dc1d45e275 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi

[PATCH] tree-optimization/107617 - big-endian .LEN_STORE VN

The following fixes a mistake in interpreting .LEN_STORE definitions during value-numbering when in big-endian mode. We cannot offset the encoding of the RHS but instead encode to an offsetted position which is then treated correctly by the endian aware copying code. Bootstrapped and tested on

[PATCH] RISC-V: Support VSETVL PASS for RVV support

From: Ju-Zhe Zhong This patch is to support VSETVL PASS for RVV support. 1.The optimization and performance is guaranteed LCM (Lazy code motion). 2.Base on RTL_SSA framework to gain better optimization chances. 3.Also we do VL/VTYPE, demand information backward propagation across blocks by

[PATCH] RISC-V: Support VSETVL PASS for RVV support

From: Ju-Zhe Zhong This patch is to support VSETVL PASS for RVV support. 1.The optimization and performance is guaranteed LCM (Lazy code motion). 2.Base on RTL_SSA framework to gain better optimization chances. 3.Also we do VL/VTYPE, demand information backward propagation across blocks by

[PATCH] RISC-V: Support VSETVL PASS for RVV support

From: Ju-Zhe Zhong This patch is to support VSETVL PASS for RVV support. 1.The optimization and performance is guaranteed LCM (Lazy code motion). 2.Base on RTL_SSA framework to gain better optimization chances. 3.Also we do VL/VTYPE, demand information backward propagation across blocks by

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

On 12/13/22 10:44, David Faust wrote: [Changes from v1: - Remove #defines for LINKAGE_* values, instead mirror enums from linux/btf.h to include/btf.h and use those. - Fix BTF generation for extern variable with both non-defining and defining decls in the same CU. Add a test for

[PATCH] RISC-V: Fix RVV machine mode attribute configuration

From: Ju-Zhe Zhong The attribute configuration of each machine mode are support in the previous patch. I noticed some of them are not correct during VSETVL PASS testsing. Correct them in the single patch now. gcc/ChangeLog: * config/riscv/riscv-vector-switch.def (ENTRY): Correct

[PATCH] RISC-V: Change vlmul printing rule

From: Ju-Zhe Zhong This patch is preparing patch for the following patch (VSETVL PASS) support since the current vlmul printing rule is not appropriate information for VSETVL PASS. I split this fix in a single patch. gcc/ChangeLog: * config/riscv/riscv-v.cc (emit_vlmax_vsetvl): Pass

[PATCH] RISC-V: Fix RVV mask mode size

From: Ju-Zhe Zhong This patch is to fix RVV mask modes size. Since mask mode size are adjust as a whole RVV register size LMUL = 1 which not only make each mask type for example vbool32_t tied to vint8m1_t but also increase memory consuming. I notice this issue during development of VSETVL

PING [PATCH, rs6000] Splat vector small V2DI constants with ISA 2.07 instructions [PR104124]

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601909.html Thanks Gui Haochen 在 2022/9/21 13:13, HAO CHEN GUI 写道: > Hi, > This patch adds a new insn for vector splat with small V2DI constants on P8. > If the value of constant is in RANGE (-16, 15) and not 0

[PATCH] [x86] x86: Don't add crtfastmath.o for -shared and add a new option -mdaz-ftz to enable FTZ and DAZ flags in MXCSR.

Don't add crtfastmath.o for -shared to avoid changing the MXCSR register when loading a shared library. crtfastmath.o will be used only when building executables. Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. Ok for trunk? gcc/ChangeLog: PR target/55522 PR

Re: [PATCH] Fix intrin name in Intel CMPccXADD

On Wed, Dec 14, 2022 at 9:46 AM Haochen Jiang via Gcc-patches wrote: > > Hi all, > > We usually use only one "_" but not two "__" as prefix in intrin. > > This patch aims to fix the intrin name for CMPccXADD. > > Bootstrapped and regtested on x86_64-pc-linux-gnu. Ok for trunk? Ok, I think there's

[PATCH] Fix intrin name in Intel CMPccXADD

Hi all, We usually use only one "_" but not two "__" as prefix in intrin. This patch aims to fix the intrin name for CMPccXADD. Bootstrapped and regtested on x86_64-pc-linux-gnu. Ok for trunk? BRs, Haochen gcc/ChangeLog: * config/i386/cmpccxaddintrin.h (__cmpccxadd_epi32):

[GCC-10][committed] libphobos: Fix std.path.expandTilde raising onOutOfMemory

Hi, This patch backports from mainline a fix for std.path.expandTilde erroneously raising onOutOfMemory after failed call to `getpwnam_r()'. Regression tested on x86_64-linux-gnu/-m32/-mx32, committed to releases/gcc-10 branch. Regards, Iain. --- libphobos/ChangeLog: * src/std/path.d

[GCC-11][committed] libphobos: Backport library and bindings fixes from mainline

Hi, This patch backports some fixes for the libphobos library from mainline that fix build and testsuite failures. Regression tested on x86_64-linux-gnu/-m32/-mx32, committed to releases/gcc-11 branch. D Runtime changes: - Fix MIPS64 bindings for CRuntime_UClibc. Phobos changes:

[GCC-12][committed] libphobos: Backport library and bindings fixes from mainline

Hi, This patch backports some fixes for the libphobos library from mainline that fix build and testsuite failures. Regression tested on x86_64-linux-gnu/-m32/-mx32, committed to releases/gcc-12 branch. D Runtime changes: - Fix MIPS64 bindings for CRuntime_UClibc. Phobos changes:

Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]

Hi Tobias, Am 13.12.22 um 22:41 schrieb Tobias Burnus: Note: We only talk about those two functions, the other functions are used by both GCC <= 11 and GCC >= 12. yes. Fortunately, these functions matter most as they map GFC internals to CFI internals or vice versa. Most other functions are

Re: [PATCH] libgccjit: Allow comparing vector types

On Tue, 2022-12-13 at 16:27 -0500, Antoni Boucher wrote: > Thanks! > > David: you mentioned gcc 10. For now, I only intend to make changes > to > the next release (13). Is this OK or should I backport all my fixes > to > all active releases? (I'm not sure what are GCC policies here.) I think it

Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]

Hi Harald, On 13.12.22 21:53, Harald Anlauf via Gcc-patches wrote: I now did so - except for three fixes (cf. changelog). See also PR: https://gcc.gnu.org/PR108056 There is no testcase as it needs to be compiled by GCC <= 11 and then run with linking (dynamically) to a GCC 12 or 13

Re: [PATCH] libgccjit: Allow comparing vector types

Thanks! David: you mentioned gcc 10. For now, I only intend to make changes to the next release (13). Is this OK or should I backport all my fixes to all active releases? (I'm not sure what are GCC policies here.) On Tue, 2022-12-13 at 16:24 -0500, David Malcolm wrote: > On Mon, 2022-12-12 at

Re: [PATCH] libgccjit: Allow comparing vector types

On Mon, 2022-12-12 at 21:31 -0500, Antoni Boucher via Jit wrote: > Hi. > This fixes bug 108078. > Thanks for the review. [...snip...] > diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h > index 5d7c7177cc3..4ec0fff4843 100644 > --- a/gcc/jit/jit-recording.h > +++

Re: [PATCH V6] rs6000: Optimize cmp on rotated 16bits constant

Hi! Sorry for the tardiness. On Mon, Aug 29, 2022 at 11:42:16AM +0800, Jiufu Guo wrote: > When checking eq/ne with a constant which has only 16bits, it can be > optimized to check the rotated data. By this, the constant building > is optimized. > > As the example in PR103743: > For "in ==

[PATCH] libstdc++: Deliver names of C functions in

From: Björn Schäpers One could add (), these are not part of __name. One could also try to check upfront if __cxa_demangle should be called at all. -- >8 -- Tested on i686-w64-mingw32. __cxa_demangle is only to demangle C++ names, for all C functions, extern "C" functions, and including main

Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]

Hi Tobias, Am 13.12.22 um 17:29 schrieb Tobias Burnus: This is a 12/13 regression as come changes to fix the GFC/CFI descriptor that went into GCC 12 fail with the (bogus) descriptor passed via by a GCC-11-compiled program. As later GCC 12 changes moved the descriptor to the front end, those

Re: [PATCH Rust front-end v4 46/46] gccrs: Add README, CONTRIBUTING and compiler logo

On Tue, 13 Dec 2022, Martin Liška wrote: > If the Rust folks are willing to use Sphinx, then yes, I'm going to > prepare a common infrastructure (baseconf.py, common license files and a > common Makefile). So something similar to what I prepared for the Sphinx > conversion that didn't make it.

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

[Changes from v1: - Add enum btf_func_linkage to include/btf.h and use it. - Minor updates to comments based on review. ] 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

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

[Changes from v1: Minor updates to comments per review. ] 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

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

[Changes from v1: - Add enum btf_var_linkage in include/btf.h and use that instead of local #defines. - Fix BTF generation for extern variable with both non-defining and defining decls in the same CU. Add a test for this. ] Add support for the 'extern' linkage value for BTF_KIND_VAR

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

[Changes from v1: - Remove #defines for LINKAGE_* values, instead mirror enums from linux/btf.h to include/btf.h and use those. - Fix BTF generation for extern variable with both non-defining and defining decls in the same CU. Add a test for this. - Update several comments per review

Re: [PATCH 4/9] ipa-sra: Treat REFERENCE_TYPES as always dereferencable

Hi, On Mon, Dec 12 2022, Jan Hubicka wrote: >> [...] >> gcc/ChangeLog: >> >> 2022-11-11 Martin Jambor >> >> PR ipa/103585 >> * ipa-sra.c (struct gensum_param_access): New field load_count. >> (struct gensum_param_desc): New field safe_ref, adjusted comments. >>

Re: [PATCH 3/9] ipa-cp: Leave removal of unused parameters to IPA-SRA

Hi, On Mon, Dec 12 2022, Jan Hubicka wrote: >> [...] >> diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc >> index cc031ebed0f..172ea353c49 100644 >> --- a/gcc/ipa-cp.cc >> +++ b/gcc/ipa-cp.cc >> @@ -3722,7 +3722,10 @@ estimate_local_effects (struct cgraph_node *node) >>

[Patch] OpenMP: Parse align clause in allocate directive in C/C++

We have a working parsing support for the 'allocate' directive (failing immediately with a sorry after parsing). To be in line with the rest of the allocat(e,or) etc. handling, it makes sense to take care of 'align' as well, which is this patch does - it still fails with a 'sorry' after parsing.

RE: [PATCH]AArch64 Fix ILP32 tbranch

> -Original Message- > From: Tamar Christina > Sent: Tuesday, December 13, 2022 5:14 PM > To: gcc-patches@gcc.gnu.org > Cc: nd ; Richard Earnshaw ; > Marcus Shawcroft ; Kyrylo Tkachov > ; Richard Sandiford > > Subject: [PATCH]AArch64 Fix ILP32 tbranch > > Hi All, > > the baremetal

[PATCH]AArch64 Fix ILP32 tbranch

Hi All, the baremetal builds are currently broken because the shift ends up in the wrong representation if the mode is SImode and the shift amount if 31. To fix this create the rtx constant with an explicit mode so the backend passes know which representation it needs to take. Bootstrapped

[Patch] Fortran: Extend align-clause checks of OpenMP's allocate clause

I missed that 'align' needs to be a power of 2 - contrary to 'aligned', which does not have this restriction for some odd reason. OK for mainline? Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter

[Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]

This is a 12/13 regression as come changes to fix the GFC/CFI descriptor that went into GCC 12 fail with the (bogus) descriptor passed via by a GCC-11-compiled program. As later GCC 12 changes moved the descriptor to the front end, those functions are only in libgomp.so to cater for old program.

[OG12][committed] OpenMP, libgomp: Handle unified shared memory in omp_target_is_accessible.

This patch handles Unified Shared Memory (USM) in the OpenMP runtime routine omp_target_is_accessible implementation. A previous patch was submitted some months ago (https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594187.html) but not yet reviewed due to dependencies on the Unified Shared

Re: [PATCH] i386: Fix up *concat*_{5,6,7} patterns [PR108044]

On Tue, Dec 13, 2022 at 01:21:54PM +0100, Uros Bizjak wrote: > On Tue, Dec 13, 2022 at 10:20 AM Jakub Jelinek wrote: > > > > Hi! > > > > The following patch fixes 2 issues with the *concat3_5 and > > *concat3_{6,7} patterns. > > One is that if the destination is memory rather than register, then

Ping---[V3][PATCH 2/2] Add a new warning option -Wstrict-flex-arrays.

Richard, Do you have any decision on this one? Do we need this warning option For GCC? thanks. Qing > On Dec 6, 2022, at 11:18 AM, Qing Zhao wrote: > > '-Wstrict-flex-arrays' > Warn about inproper usages of flexible array members according to > the LEVEL of the 'strict_flex_array

Re: [PATCH] gcov: Fix -fprofile-update=atomic

On Fri, Dec 9, 2022 at 2:56 PM Sebastian Huber wrote: > > The code coverage support uses counters to determine which edges in the > control > flow graph were executed. If a counter overflows, then the code coverage > information is invalid. Therefore the counter type should be a 64-bit >

Re: Patch [0/3] for PR target/107299 (GCC does not build on PowerPC when long double is IEEE 128-bit)

On Tue, Dec 06, 2022 at 04:03:35PM +0100, Jakub Jelinek wrote: > On Tue, Dec 06, 2022 at 08:56:09AM -0600, Segher Boessenkool wrote: > > > In the past, _Float128 was a C extended type, > > > but now it is a part of the C/C++ 2x standards. > > > > Only if you select a new enough -std=, it

[PATCH] tree-optimization/105801 - CCP and .DEFERRED_INIT

This makes sure we treat .DEFERRED_INIT as producing UNDEFINED so we can continue optimizing uninitialized uses the same as without -ftrivial-auto-var-init=zero. For the testcase this means we catch the return 1 optimization opportunity at CCP rather than only at FRE which already does the right

Re: [pushed] c++: build initializer_list in a loop [PR105838]

On 08/12/2022 19:45, Jason Merrill via Gcc-patches wrote: Tested x86_64-pc-linux-gnu, applying to trunk. Bisecting shows this started to break $ cat test.cc #include template struct ConstCharArrayDetector; template struct ConstCharArrayDetector { using Type = int; }; struct OUString {

Re: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR target/107299

On Tue, Dec 13, 2022 at 01:14:39AM -0500, Michael Meissner wrote: > On Mon, Dec 12, 2022 at 06:20:14PM +0800, Kewen.Lin wrote: > > Without or with patch #1, the below ICE in libgcc exists, the ICE should > > have > > nothing to do with the special handling for building_libgcc in patch #1. I > >

Re: Rust front-end patches v4

Hi Martin, On 12/13/22 14:30, Martin Liška wrote: On 12/13/22 14:26, Arthur Cohen wrote: Thank you, and congratulations, to all the contributors. We thank you!! Congratulations. Thank you :) I have one question: do you have a list of supported architectures Rust FE can support right now?

Re: Rust front-end patches v4

We've also added one more commit, which only affects files inside the Rust front-end folder. This commit adds an experimental flag, which blocks the compilation of Rust code when not used. We hope this helps indicate to users that the compiler is not yet ready, but can still be experimented

Re: Rust front-end patches v4

On 12/13/22 14:26, Arthur Cohen wrote: > Thank you, and congratulations, to all the contributors. We thank you!! Congratulations. I have one question: do you have a list of supported architectures Rust FE can support right now? What are you plans for GCC 13.1 release? Cheers, Martin > > All 

Re: Rust front-end patches v4

Hi everyone, I have pushed the commits onto master. Thanks again for all the reviews and support. Thank you, and congratulations, to all the contributors. All the best, Arthur On 12/6/22 12:03, Richard Biener via Gcc-rust wrote: On Tue, Dec 6, 2022 at 11:11 AM wrote: This patchset

Re: [PATCH Rust front-end v4 46/46] gccrs: Add README, CONTRIBUTING and compiler logo

On 12/13/22 02:43, Joseph Myers wrote: > On Fri, 9 Dec 2022, Martin Liška wrote: > >> On 12/6/22 11:14, arthur.co...@embecosm.com wrote: >>> |We still need to write out a documentation section, but these READMEs will >>> help in the meantime.| >> >> Hello. >> >> Just a quick comment: The Sphinx

Re: [PATCH 8/9] ipa-sra: Make scan_expr_access bail out on uninteresting expressions

On Mon, 12 Dec 2022, Jan Hubicka wrote: > > > Hi, > > > > > > I'm re-posting patches which I have posted at the end of stage 1 but > > > which have not passed review yet. > > > > > > 8< > > > > > > I have noticed that

[PATCH] build: doc: Obsolete Solaris 11.3 support

This patch implements the Solaris 11.[0-3] obsoletion just announced in https://gcc.gnu.org/pipermail/gcc/2022-December/240322.html Bootstrapped without regressions on Solaris 11.3 (i386-pc-solaris2.11, sparc-sun-solaris2.11 without and with --enable-obsolete) and 11.4. Ok for trunk?

Re: [PATCH] i386: Fix up *concat*_{5,6,7} patterns [PR108044]

On Tue, Dec 13, 2022 at 10:20 AM Jakub Jelinek wrote: > > Hi! > > The following patch fixes 2 issues with the *concat3_5 and > *concat3_{6,7} patterns. > One is that if the destination is memory rather than register, then > we can't use movabsq and so can't support all the possible immediates. >

[PATCH] tree-optimization/108076 - if-conversion and forced labels

When doing if-conversion we simply throw away labels without checking whether they are possibly targets of non-local gotos or have their address taken. The following rectifies this and refuses to if-convert such loops. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. PR

Re: [PATCH] vect-patterns: Fix up vect_recog_rotate_pattern [PR108064]

> Am 13.12.2022 um 10:28 schrieb Jakub Jelinek via Gcc-patches > : > > Hi! > > Since vect_recog_rotate_pattern has been extended to work also > on signed types in r13-1100 we miscompile the testcase below. > vect_recog_rotate_pattern actually emits correct scalar code into > the pattern def

Re: [PATCH] libstdc++: Update backtrace-rename.h

On Tue, Dec 13, 2022 at 09:50:23AM +, Jonathan Wakely via Gcc-patches wrote: > On Tue, 13 Dec 2022 at 09:44, Jakub Jelinek wrote: > > > > Hi! > > > > When writing the r13-4629 commit log I've realized that libsanitizer > > isn't the only place which nowadays renames libbacktrace symbols, > >

Re: [PATCH] c++, libstdc++: Add typeinfo for _Float{16, 32, 64, 128, 32x, 64x} and __bf16 types [PR108075]

On Tue, 13 Dec 2022 at 09:40, Jakub Jelinek wrote: > > Hi! > > The following patch adds typeinfos for the extended floating point > types and _Float{32,64}x. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? The libstdc++ parts look good, thanks. > 2022-12-13 Jakub

Re: [PATCH] libstdc++: Update backtrace-rename.h

On Tue, 13 Dec 2022 at 09:44, Jakub Jelinek wrote: > > Hi! > > When writing the r13-4629 commit log I've realized that libsanitizer > isn't the only place which nowadays renames libbacktrace symbols, > libstdc++ does that too. > > Ok for trunk if this passes bootstrap/regtest? OK, thanks. When

[PATCH] libstdc++: Update backtrace-rename.h

Hi! When writing the r13-4629 commit log I've realized that libsanitizer isn't the only place which nowadays renames libbacktrace symbols, libstdc++ does that too. Ok for trunk if this passes bootstrap/regtest? 2022-12-13 Jakub Jelinek * src/libbacktrace/backtrace-rename.h

[PATCH] c++, libstdc++: Add typeinfo for _Float{16,32,64,128,32x,64x} and __bf16 types [PR108075]

Hi! The following patch adds typeinfos for the extended floating point types and _Float{32,64}x. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2022-12-13 Jakub Jelinek PR libstdc++/108075 gcc/cp/ * rtti.cc (emit_support_tinfos): Add pointers to

[committed] libsanitizer: Fix up libbacktrace build after r13-4547 [PR108072]

Hi! The r13-4547 commit added new non-static function to libbacktrace: backtrace_uncompress_zstd but for the libsanitizer use we need to rename it, so that it is in __asan_* namespace and doesn't clash with other copies of libbacktrace. Bootstrapped/regtested on x86_64-linux and i686-linux,

[PATCH] vect-patterns: Fix up vect_recog_rotate_pattern [PR108064]

Hi! Since vect_recog_rotate_pattern has been extended to work also on signed types in r13-1100 we miscompile the testcase below. vect_recog_rotate_pattern actually emits correct scalar code into the pattern def sequence (in particular cast to utype, doing the 2 shifts in utype so that the right

[PATCH] i386: Fix up *concat*_{5,6,7} patterns [PR108044]

Hi! The following patch fixes 2 issues with the *concat3_5 and *concat3_{6,7} patterns. One is that if the destination is memory rather than register, then we can't use movabsq and so can't support all the possible immediates. I see 3 possibilities to fix that. One would be to use

PING: New reg note REG_CFA_NORESTORE

Hi, I need a way to save registers on the stack and generate proper CFI for it. Since I do not intend to restore them I needed a way to tell the CFI generation step about it: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606128.html Is this ok for mainline? Bye, Andreas

Re: [PATCH 8/9] ipa-sra: Make scan_expr_access bail out on uninteresting expressions

> Am 12.12.2022 um 22:59 schrieb Jan Hubicka via Gcc-patches > : > >  >> >>> Hi, >>> >>> I'm re-posting patches which I have posted at the end of stage 1 but >>> which have not passed review yet. >>> >>> 8< >>> >>> I