Re: [PATCH, V2] Define KFmode constants for libgcc.

Hi! On Thu, Apr 29, 2021 at 05:48:53PM -0400, Michael Meissner wrote: > This patch defines the constants needed for libgcc for the PowerPC > specific IEEE 128-bit floating point types (KFmode). It doesn't do that though? > The 4/28 changes to libgcc need these constants defined. I wondered what

Re: [PATCH, V2] Define KFmode constants for libgcc.

On Thu, Apr 29, 2021 at 05:50:03PM -0500, Segher Boessenkool wrote: > Hi! > > On Thu, Apr 29, 2021 at 05:48:53PM -0400, Michael Meissner wrote: > > This patch defines the constants needed for libgcc for the PowerPC > > specific IEEE 128-bit floating point types (KFmode). > > It doesn't do that th

Re: [PATCH, V2] Define KFmode constants for libgcc.

On Thu, Apr 29, 2021 at 07:23:03PM -0400, Michael Meissner wrote: > On Thu, Apr 29, 2021 at 05:50:03PM -0500, Segher Boessenkool wrote: > > On Thu, Apr 29, 2021 at 05:48:53PM -0400, Michael Meissner wrote: > > > This patch defines the constants needed for libgcc for the PowerPC > > > specific IEEE

Re: [PATCH] [RISCV] Add Pattern for builtin overflow

On Wed, Apr 28, 2021 at 10:43 PM Levy Hsu wrote: > From: LevyHsu > > Added implementation for builtin overflow detection, new patterns are > listed below. > This looks OK. You are missing a ChangeLog entry. I added one. I had to fix some whitespace and formatting issues. Open parens should

Re: About implementation of the Negative property of options.

On Wed, Apr 28, 2021 at 1:11 PM Joseph Myers wrote: > Could you please explain the bug at the *user-visible* level? That is, > the particular options passed to the compiler, how those options behave, > and how you think they should behave instead. I added this to the riscv.opt file to create s

Re: [PATCH] RISC-V: For '-march' and '-mabi' options, add 'Negative' property mentions itself.

On Wed, Apr 28, 2021 at 1:30 AM Geng Qi via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > gcc/ChangeLog: > * config/riscv/riscv.opt (march=,mabi=): Negative itself. > Thanks. I committed this. Do we need to backport to release branches? This looks like an uncommon problem, or we woul

Re: [PATCH/RFC] Add a new memory gathering optimization for loop (PR98598)

>> This patch implements a new loop optimization according to the proposal >> in RFC given at >> https://gcc.gnu.org/pipermail/gcc/2021-January/234682.html. >> So do not repeat the idea in this mail. Hope your comments on it. > > With the caveat that I'm not an optimization expert (but no one else

[PATCH][AVX512] Fix ICE for vpexpand*.

Hi: This patch is to fix ice which was introduced by my r11-5696-g35c4c67e6c534ef3d6ba7a7752ab7e0fbc91755b. Bootstrapped and regtested on x86_64-linux-gnu{-m32,}. Ok for trunk and backport to GCC11? gcc/ChangeLog PR target/100310 * config/i386/i386-expand.c (ix86_e

[PATCH][AVX512] Optimize vpexpand* to mask mov when mask have all ones in it's lower part (including 0 and -1).

Hi: For v{,p}expand* When mask is 0, -1, or has all all one bits in its lower part, it can be optimized to simple mov or mask mov. Bootstrapped and regtested on x86_64-linux-gnu{-m32,} and x86_64-linux-gnu{m32\ -march=cascadelake,-m64\ -march=cascadelake}, gcc/ChangeLog: * config/i38

[PATCH] RISC-V: Implement __clear_cache via __builtin__clear_cache

We have had an implementation of __builtin__clear_cache since the beginning, but didn't have the cooresponding __clear_cache library routine implemented. This directly conflicts the GCC manual in a handful of places, which indicates that __clear_cache should work and that __builtin_clear_cache sho

Re: [Ping, PATCH 2/n] AVR CC0 conversion - adjust peepholes

Could someone please approve this patch too? The base conversion patch (https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568658.html) was approved and committed, and fixing peepholes addresses a bunch of code size regressions introduced by the base patch. No regressions on all 4 devices, as

Re: [PATCH V7 4/7] CTF/BTF debug formats

On Thu, 29 Apr 2021, Indu Bhagat wrote: > Hello, > > On 4/29/21 5:10 AM, Richard Biener wrote: > > On Thu, 29 Apr 2021, Jose E. Marchesi wrote: > > > >> This commit introduces support for generating CTF debugging > >> information and BTF debugging information from GCC. > > > > Comments inline.

Re: [Ping, PATCH 2/n] AVR CC0 conversion - adjust peepholes

On Fri, 30 Apr 2021, Senthil Kumar Selvaraj wrote: > > Could someone please approve this patch too? The base conversion patch > (https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568658.html) was > approved and committed, and fixing peepholes addresses a bunch of code > size regressions introd

[PATCH 1/1] PR100281 C++: Fix SImode pointer handling

The problem appears to be triggered by two locations in the front-end where non-POINTER_SIZE pointers aren't handled right now. 1. An assertion in strip_typedefs is triggered because the alignment of the types don't match. This in turn is caused by creating the new type with build_pointer_type ins

[PATCH] rs6000: Fix wrong code generation for vec_sel [PR94613]

The vsel instruction is a bit-wise select instruction. Using an IF_THEN_ELSE to express it in RTL is wrong and leads to wrong code being generated in the combine pass. Per element selection is a subset of per bit-wise selection,with the patch the pattern is written using bit operations. But ther

Re: [PATCH v2] IBM Z: Handle hard registers in s390_md_asm_adjust()

On 4/28/21 3:48 AM, Ilya Leoshkevich wrote: > Bootstrapped and regtested on s390x-redhat-linux. Tested with valgrind > too (PR 100278 is now fixed). Ok for master? > > v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568771.html > v1 -> v2: Use the UNSPEC pattern, which is less efficient

<    1   2