[RFC]RISC-V: Support RV64-ILP32

From: Liao Shihua This patch support rv64 insn in ilp32 ABI. It was inspired by aarch64 both support 64-bit and 32-bit ABI with the same set of instructions. gcc/ChangeLog: * config.gcc: Implememt ilp32* with rv64*. * config/riscv/riscv.cc (riscv_option_override):

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

I have submitted a new replacement patch for this patch: | Date: Tue, 1 Nov 2022 22:40:43 -0400 | Subject: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR target/107299 | Message-ID: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608368.html -- Michael Meissner, IBM PO Box

[PATCH V2] Rework 128-bit complex multiply and divide, PR target/107299

In the patch I previously submitted: | Date: Tue, 1 Nov 2022 22:40:43 -0400 | Subject: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR target/107299 | Message-ID: Kewen.Lin questioned whether we needed to disable the special handling of the IEEE 128-bit complex multiply/divide if we

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

On 12/12/22 12:47, David Faust wrote: On 12/8/22 22:55, Indu Bhagat wrote: Hi David, On 12/7/22 12:57, David Faust wrote: 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/

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

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 > think patch #2 which makes _Float128 and __float128 use the same internal >

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

On 12/12/22 12:31, David Faust wrote: On 12/8/22 23:36, Indu Bhagat wrote: On 12/7/22 12:57, David Faust wrote: 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

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

On 12/12/22 12:59, David Faust wrote: On 12/8/22 23:34, Indu Bhagat wrote: Looks OK to me overall. Minor comments below. Thanks On 12/7/22 12:57, David Faust wrote: The eBPF loader expects to find BTF_KIND_VAR records for references to extern const void symbols. We were mistakenly

Re: Extend fold_vec_perm to fold VEC_PERM_EXPR in VLA manner

On Tue, 6 Dec 2022 at 21:00, Richard Sandiford wrote: > > Prathamesh Kulkarni via Gcc-patches writes: > > On Fri, 4 Nov 2022 at 14:00, Prathamesh Kulkarni > > wrote: > >> > >> On Mon, 31 Oct 2022 at 15:27, Richard Sandiford > >> wrote: > >> > > >> > Prathamesh Kulkarni writes: > >> > > On

Re: [PATCH PING] build: add -Wconditionally-supported to strict_warn [PR64867]

On 12/6/22 08:26, Jason Merrill wrote: Tested x86_64-pc-linux-gnu, OK for trunk? Ping. -- 8< -- The PR (which isn't resolved by this commit) pointed out to me that GCC should build with -Wconditionally-supported to support bootstrapping with a C++11 compiler that makes different choices.

Ping^5: [PATCH V6] rs6000: Optimize cmp on rotated 16bits constant

Hi, I would like to ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html BR, Jeff (Jiufu) Jiufu Guo via Gcc-patches writes: > Hi, > > Gentle ping: > https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html > > BR, > Jeff(Jiufu) > > Jiufu Guo via Gcc-patches

[PATCH] libgccjit: Allow comparing vector types

Hi. This fixes bug 108078. Thanks for the review. From 016d23eeab1536e2ce0607d422fe4bb42b55c2dc Mon Sep 17 00:00:00 2001 From: Antoni Boucher Date: Fri, 24 Jun 2022 21:05:29 -0400 Subject: [PATCH] libgccjit: Allow comparing vector types gcc/jit/ChangeLog: PR jit/108078 * jit-recording.h: Add

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

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 conversion didn't make it for all GCC >

[PATCH PING] GC unused SIMD clones

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607195.html The patch referenced in the original post is now approved and committed. -Sandra

Re: [PATCH] longlong.h: Do no use asm input cast for clang

On Mon, Dec 12, 2022 at 02:10:16PM -0300, Adhemerval Zanella Netto wrote: > On 30/11/22 20:24, Segher Boessenkool wrote: > > I understand that the casts should be no-ops on the asm side (maybe they > > change the sign) and they are present as type-checking. Can we implement > > this type-checking

libgo patch committed: Bump major version

This libgo patch bumps the major version. The current version is the same as for GCC 12, but there have been minor changes like new type descriptors that make it impossible to run Go programs built with GCC 12 with the current GCC. This fixes https://gcc.gnu.org/PR108057. Bootstrapped on

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

> > 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 scan_expr_access passes all the expressions it > > gets to

Re: [PATCH 9/9] ipa: Avoid looking for IPA-SRA replacements where there are none

> Hi, > > I'm re-posting patches which I have posted at the end of stage 1 but > which have not passed review yet. > > 8< > > While modifying the code, I realized that we do look into statements > even when there are no

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

> 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 scan_expr_access passes all the expressions it > gets to get_ref_base_and_extent

Re: [PATCH 7/9] ipa-sra: Forward propagation of sizes which are safe to dereference

> gcc/ChangeLog: > > 2022-11-11 Martin Jambor > > * ipa-sra.cc (isra_param_desc): New fields safe_size, > conditionally_dereferenceable and safe_size_set. > (struct gensum_param_desc): New field conditionally_dereferenceable. > (struct isra_param_flow): Updated comment

Re: [PATCH 6/9] ipa-sra: Be optimistic about Fortran descriptors

> Hi, > > I'm re-posting patches which I have posted at the end of stage 1 but > which have not passed review yet. > > 8< > > Fortran descriptors are structures which are often constructed just > for a particular argument of a

Re: [PATCH 5/9] ipa-sra: Move caller->callee propagation before callee->caller one

> gcc/ChangeLog: > > 2022-11-11 Martin Jambor > > * ipa-sra.c (ipa_sra_analysis): Move top-down analysis before > bottom-up analysis. Replace FOR_EACH_VEC_ELT with C++11 iteration. > > gcc/testsuite/ChangeLog: > > 2021-12-14 Martin Jambor > > *

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

> Hi, > > I'm re-posting patches which I have posted at the end of stage 1 but > which have not passed review yet. > > 8< > > C++ and especially Fortran pass data by references which are not > pointers potentially pointing

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

> Hi, > > I'm re-posting patches which I have posted at the end of stage 1 but > which have not passed review yet. > > 8< > > Looking at some benchmarks I have noticed many cases when IPA-CP > cloned a function for all contexts

Re: [PATCH 1/9] ipa-cp: Write transformation summaries of all functions

> gcc/ChangeLog: > > 2022-11-25 Martin Jambor > > * ipa-prop.cc (useful_ipcp_transformation_info_p): New function. > (write_ipcp_transformation_info): Added a parameter, simplified > given that is known not to be NULL. > (ipcp_write_transformation_summaries): Write out

Re: [PATCH 2/9] ipa: Better way of applying both IPA-CP and IPA-SRA (PR 103227)

> 2022-11-11 Martin Jambor > > PR ipa/103227 > * ipa-param-manipulation.h (class ipa_param_adjustments): Removed > member function get_updated_index_or_split. > (class ipa_param_body_adjustments): New overload of > register_replacement, new member function

Re: [PATCH][X86_64] Separate znver4 insn reservations from older znvers

> I have addressed all your comments in this revised patch, PFA and inlined > below. > > Is it ok for trunk? > > Thanks and Regards, > Tejas > > gcc/ChangeLog: > > * gcc/common/config/i386/i386-common.cc (processor_alias_table): > Use CPU_ZNVER4 for znver4. > *

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

On 12/8/22 23:34, Indu Bhagat wrote: > Looks OK to me overall. Minor comments below. > > Thanks > > On 12/7/22 12:57, David Faust wrote: >> The eBPF loader expects to find BTF_KIND_VAR records for references to >> extern const void symbols. We were mistakenly identifing these as >>

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

On 12/8/22 22:55, Indu Bhagat wrote: > Hi David, > > On 12/7/22 12:57, David Faust wrote: >> 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

Re: [PATCH 1/9] ipa-cp: Write transformation summaries of all functions

> -void > -write_ipcp_transformation_info (output_block *ob, cgraph_node *node) > +/* Return true if the IPA-CP transformation summary TS is non-NULL and > contains > + useful info. */ > +static bool > +useful_ipcp_transformation_info_p (ipcp_transformation *ts) > { > - int node_ref; > -

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

On 12/8/22 23:36, Indu Bhagat wrote: > On 12/7/22 12:57, David Faust wrote: >> 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'

[PATCH] Fortran: NULL pointer dereference while parsing a function [PR107423]

Dear all, here's another obvious patch by Steve which prevents a NULL pointer dereference during parsing. Regtested on x86_64-pc-linux-gnu. Will commit to mainline within 24h unless there are comments. Thanks, Harald From f23a5252ee086f9b78c44150d409e40a445c6928 Mon Sep 17 00:00:00 2001 From:

Re: [PATCH] Fortran: improve checking of assumed size array spec [PR102180]

On Mon, Dec 12, 2022 at 08:49:50PM +0100, Harald Anlauf via Fortran wrote: > > Committed as r13-4623-gcf5327b89ab610. > To be clear, I have no problems with this commit. But, just a FYI, there is gfc_peek_ascii_char(), which allows you to look at the next character without having to keep track

Re: [PATCH] Fortran: improve checking of assumed size array spec [PR102180]

Hi Steve, Am 12.12.22 um 00:52 schrieb Steve Kargl via Gcc-patches: On Sun, Dec 11, 2022 at 11:33:43PM +0100, Harald Anlauf via Fortran wrote: Dear all, the attached patch improves checking of array specs in two ways: - bad assumed size array spec - a bad first array element spec may already

[committed] d: Fix undefined reference to nested lambda in template (PR108055)

Hi, This patch fixes a linker error caused by gdc not emitting all symbols. Sometimes, nested lambdas of templated functions get no code generation due to them being marked as instantianted outside of all modules being compiled in the current compilation unit. This despite enclosing template

Re: [PATCH] longlong.h: Do no use asm input cast for clang

Hi! On Thu, Dec 01, 2022 at 08:26:52AM +0100, Richard Biener wrote: > On Thu, Dec 1, 2022 at 12:26 AM Segher Boessenkool > wrote: > > On Wed, Nov 30, 2022 at 03:16:25PM -0300, Adhemerval Zanella via > > Gcc-patches wrote: > > > clang by default rejects the input casts with: > > > > > > error:

[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

[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

[PATCH] libstdc++: enable on windows

From: Björn Schäpers libstdc++-v3/Changelog * acinclude.m4: Add check for windows.h. * acinclude.m4: Add pecoff as FORMAT_FILE. * config.h.in: Regenerate. * configure: Regenerate. * src/libbacktrace/Makefile.am: Regenerate. *

[PATCH] c++: template friend with variadic constraints [PR108066]

When instantiating a constrained hidden template friend, we need to substitute into its constraints for sake of declaration matching. For this substitution we use a full argument vector whose outer levels correspond to the class's arguments and innermost level corresponds to the template's

Re: [PATCH] longlong.h: Do no use asm input cast for clang

On 30/11/22 20:24, Segher Boessenkool wrote: > Hi! > > On Wed, Nov 30, 2022 at 03:16:25PM -0300, Adhemerval Zanella via Gcc-patches > wrote: >> clang by default rejects the input casts with: >> >> error: invalid use of a cast in a inline asm context requiring an >> lvalue: remove the cast

[PATCH 7/9] ipa-sra: Forward propagation of sizes which are safe to dereference

Hi, I'm re-posting patches which I have posted at the end of stage 1 but which have not passed review yet. 8< The previous patch established a way to propagate information about parameters from callers to callees (even though

[PATCH 9/9] ipa: Avoid looking for IPA-SRA replacements where there are none

Hi, I'm re-posting patches which I have posted at the end of stage 1 but which have not passed review yet. 8< While modifying the code, I realized that we do look into statements even when there are no replacements. This patch

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

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 scan_expr_access passes all the expressions it gets to get_ref_base_and_extent even when we are

[PATCH 6/9] ipa-sra: Be optimistic about Fortran descriptors

Hi, I'm re-posting patches which I have posted at the end of stage 1 but which have not passed review yet. 8< Fortran descriptors are structures which are often constructed just for a particular argument of a particular call

[PATCH 5/9] ipa-sra: Move caller->callee propagation before callee->caller one

Hi, I'm re-posting patches which I have posted at the end of stage 1 but which have not passed review yet. 8< This patch does not do any functional changes, it merely moves top-down propagation in the IPA-SRA WPA phase before

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

Hi, I'm re-posting patches which I have posted at the end of stage 1 but which have not passed review yet. 8< Looking at some benchmarks I have noticed many cases when IPA-CP cloned a function for all contexts just because it

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

Hi, I'm re-posting patches which I have posted at the end of stage 1 but which have not passed review yet. 8< C++ and especially Fortran pass data by references which are not pointers potentially pointing anywhere and so can be

[PATCH 2/9] ipa: Better way of applying both IPA-CP and IPA-SRA (PR 103227)

Hi, I'm re-posting patches which I have posted at the end of stage 1 but which have not passed review yet. I would really like to have at least the previous patch and this one accepted for GCC 13 so that PR 103227 is fixed ina way which does not sometimes leave unused parameters behind. The

[PATCH 1/9] ipa-cp: Write transformation summaries of all functions

Hi, I'm re-posting patches which I have posted at the end of stage 1 but which have not passed review yet. I would really like to have at least this patch and the subsequent one accepted for GCC 13 so that PR 103227 is fixed ina way which does not sometimes leave unused parameters behind. The

Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

On 12/12/2022 12:18, Jonathan Wakely wrote: If Clang already treats __is_signed as a conditionally-active built-in, it should do the same for __is_unsigned. Wasn't aware of that special handling of __is_signed. Filed "Also allow __is_unsigned to be used as

Re: [PATCH v5, rs6000] Change mode and insn condition for VSX scalar extract/insert instructions

Hi! On Fri, Dec 02, 2022 at 03:03:46PM +0800, HAO CHEN GUI wrote: > For scalar extract/insert instructions, exponent field can be stored in a > 32-bit register. So this patch changes the mode of exponent field from DI to > SI so that these instructions can be generated in a 32-bit environment.

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

On Wed, 7 Dec 2022 17:13:42 +0100 Tobias Burnus wrote: > I think we need to distinguish: > >#pragma omp target enter data map(to: s.w[:10]) > > from > >#pragma omp target map(tofrom: s.arr[:20]) > s.arr[0] = 5; > > As in the latter case 's' gets implicitly mapped and then

Re: [PATCH 9/12 V2] arm: Make libgcc bti compatible

Richard Earnshaw writes: > On 22/07/2022 16:09, Andrea Corallo via Gcc-patches wrote: >> Richard Earnshaw writes: >> >>> On 21/07/2022 10:17, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw writes: > On 28/04/2022 10:48, Andrea Corallo via Gcc-patches wrote: >> This

Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

On Mon, 12 Dec 2022 at 11:18, Jonathan Wakely wrote: > > On Mon, 12 Dec 2022 at 07:12, Stephan Bergmann via Libstdc++ > wrote: > > > > On 11/21/22 21:43, Jonathan Wakely via Libstdc++ wrote: > > > + static constexpr bool __is_unsigned > > > + = __and_v, > > > +

[committed] libstdc++: Fix constraint on std::basic_format_string [PR108024]

Tested x86_64-linux. Pushed to trunk. -- >8-- Also remove some redundant std::move calls for return statements. libstdc++-v3/ChangeLog: PR libstdc++/108024 * include/std/format (basic_format_string): Fix constraint. * testsuite/std/format/format_string.cc: New test. ---

[committed] libstdc++: Add a test checking for chrono::duration overflows

Tested x86_64-linux. Pushed to trunk. -- >8-- This test fails if chrono::days::rep or chrono::years::rep is a 32-bit type, because a large days or years value silently overflows a 32-bit integer when converted to seconds. It would be conforming to implement chrono::days as chrono::duration>, but

[committed] libstdc++: Change names that clash with Win32 or Clang

Tested x86_64-linux. Pushed to trunk. -- >8-- Clang now defines an __is_unsigned built-in, and Windows defines an _Out_ macro. Replace uses of those as identifiers. There might also be a problem with __is_signed, which we use in several places. libstdc++-v3/ChangeLog: *

[committed] libstdc++: Define atomic lock-free type aliases for C++20 [PR98034]

Tested x86_64-linux. Pushed to trunk. -- >8-- libstdc++-v3/ChangeLog: PR libstdc++/98034 * include/std/atomic (__cpp_lib_atomic_lock_free_type_aliases): Define macro. (atomic_signed_lock_free, atomic_unsigned_lock_free): Define aliases. *

[committed] libstdc++: Make operator<< for stacktraces less templated (LWG 3515)

Tested x86_64-linux. Pushed to trunk. -- >8-- This change was approved for C++23 last month. libstdc++-v3/ChangeLog: * include/std/stacktrace (operator<<): Only output to narrow ostreams (LWG 3515). * testsuite/19_diagnostics/stacktrace/synopsis.cc: ---

RE: [PATCH] Fix memory constraint on MVE v[ld/st][2/4] instructions [PR107714]

Hi Stam, > -Original Message- > From: Stam Markianos-Wright > Sent: Friday, December 9, 2022 1:32 PM > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov ; Richard Earnshaw > ; Ramana Radhakrishnan > ; ni...@redhat.com > Subject: [PATCH] Fix memory constraint on MVE v[ld/st][2/4]

[PATCH (pushed)] mklog: do not parse binary file for PR entry

contrib/ChangeLog: * mklog.py: Do not search PR entry in a file that is binary. --- contrib/mklog.py | 34 ++ 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/contrib/mklog.py b/contrib/mklog.py index 3a6ec681b65..358b7fc6b8b 100755 ---

Re: [PATCH] Backport gcc-12: jobserver FIFO support

On 12/12/22 12:42, Jakub Jelinek wrote: > On Mon, Dec 12, 2022 at 12:39:36PM +0100, Martin Liška wrote: >>> I'm fine with backporting the whole >>> series to GCC 12 but I wonder if earlier still maintained versions are also >>> affected (noting that the series also addresses WPA streaming which is

Re: [PATCH] Backport gcc-12: jobserver FIFO support

On Mon, Dec 12, 2022 at 12:39:36PM +0100, Martin Liška wrote: > > I'm fine with backporting the whole > > series to GCC 12 but I wonder if earlier still maintained versions are also > > affected (noting that the series also addresses WPA streaming which is > > not part of the "troubles" here). >

Re: [PATCH] Backport gcc-12: jobserver FIFO support

On 12/11/22 11:47, Richard Biener wrote: > On Fri, Dec 9, 2022 at 11:07 AM Martin Liška wrote: >> >> Hi. >> >> As make 4.4 has been release, it switches to FIFO by default. That makes >> troubles to the latest GCC release, version 12. > > Can you elaborate on "troubles" here? Sure. Problem with

Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

On Mon, 12 Dec 2022 at 07:12, Stephan Bergmann via Libstdc++ wrote: > > On 11/21/22 21:43, Jonathan Wakely via Libstdc++ wrote: > > + static constexpr bool __is_unsigned > > + = __and_v, > > + is_unsigned>; > > Using `__is_unsigned` as an identifier here causes

[Ping x6] Re: [PATCH, nvptx, 1/2] Reimplement libgomp barriers for nvptx

Ping x6 On 2022/12/6 12:21 AM, Chung-Lin Tang wrote: > Ping x5 > > On 2022/11/22 12:24 上午, Chung-Lin Tang wrote: >> Ping x4 >> >> On 2022/11/8 12:34 AM, Chung-Lin Tang wrote: >>> Ping x3. >>> >>> On 2022/10/31 10:18 PM, Chung-Lin Tang wrote: Ping x2. On 2022/10/17 10:29 PM,

[PATCH][committed] aarch64: Add __ARM_FEATURE_PAUTH and __ARM_FEATURE_BTI ACLE defines

Hi all, Recent ACLE additions specified the __ARM_FEATURE_PAUTH and __ARM_FEATURE_BTI macros [1] that the compiler should define when the pointer authentication and BTI instructions are available (and don't act as NOPs). We've received requests to enable them in GCC for aarch64, similar to

Re: [PATCH 10/15 V5] arm: Implement cortex-M return signing address codegen

On 09/12/2022 14:16, Andrea Corallo via Gcc-patches wrote: Hi Richard, thanks for reviewing. Richard Earnshaw writes: On 07/11/2022 08:57, Andrea Corallo via Gcc-patches wrote: Hi all, please find attached the lastest version of this patch incorporating some more improvents. Feel free

Re: [PATCH v5, rs6000] Change mode and insn condition for VSX scalar extract/insert instructions

on 2022/12/12 11:23, HAO CHEN GUI wrote: > Hi Kewen, > > 在 2022/12/8 16:47, Kewen.Lin 写道: >> This documentation update reminds me of that the current prototype of >> __ieee128 >> variant can be: >> >> unsigned int scalar_extract_exp (__ieee128 source); >> >> type unsigned int is enough for the

Re: [PATCH] tree-optimization/99919 - bogus uninit diagnostic with bitfield guards

On Thu, Dec 8, 2022 at 12:07 PM Richard Biener via Fortran wrote: > > For the testcase in this PR what fold-const.cc optimize_bit_field_compare > does to bitfield against constant compares is confusing the uninit > predicate analysis and it also makes SRA obfuscate instead of optimize > the code.

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

on 2022/12/9 06:04, Michael Meissner wrote: > On Wed, Dec 07, 2022 at 03:55:41PM +0800, Kewen.Lin wrote: >> Hi Mike, >> >> on 2022/12/7 14:44, Michael Meissner wrote: >>> On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote: Hi Mike, Thanks for fixing this! Could you

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

Richard Biener writes: > On Sat, Dec 10, 2022 at 1:49 AM Gaius Mulley via Gcc-patches > wrote: >> >> >> While writing the ChangeLog entries git gcc-verify spotted an oversight >> with v3 of this patch set. I had forgotten to post gm2.texi and also a >> tiny patchlet in gcc/configure.ac (to

[PATCH] Revert parts of ADDR_EXPR/CONSTRUCTOR treatment change in match.pd

This reverts the part that substitutes from the definition of an SSA name to the capture, thus ADDR_EXPR@0 eventually yielding _1->a[i_2] instead of _3. That's because I didn't think of how to deal with substituting @0 in the result pattern. So the following re-instantiates the SSA def