Re: [PATCH] arc: Add --with-fpu support for ARCv2 cpus

On Fri, 11 Jun 2021 14:25:24 +0300 Claudiu Zissulescu wrote: > Hi Bernhard, > > Please find attached my latest patch, it includes (hopefully) all your > feedback. > > Thank you for comments, concise and clean, i wouldn't know what to remove. LGTM. thanks for your patience!

Re: [committed] wwwdocs: gcc-11/changes.html: Editorial changes for RISC-V

On Sun, 13 Jun 2021 07:58:50 +0200 (CEST) Gerald Pfeifer wrote: > RISC-V has received a very nice section in the GCC 11 release notes > thanks to Kito. > > This are a couple of editorial changes, completing some sentence and > breaking longer sentences among others, and a bit of grammar. > > Pu

Re: [PATCH] x86: Replace ix86_red_zone_size with ix86_red_zone_used

On Fri, Jun 11, 2021 at 10:46 PM H.J. Lu wrote: > > Add red_zone_used to machine_function to track if red zone is used. > When expanding function prologue, set red_zone_used to true if red > zone is used. > > gcc/ > > PR target/pr101023 > * config/i386/i386.c (ix86_expand_prologue)

[PATCH] dwarf: Multi-register CFI address support.

Add support for architectures such as AMD GCN, in which the pointer size is larger than the register size. This allows the CFI information to include multi-register locations for the stack pointer, frame pointer, and return address. This patch was originally posted by Andrew Stubbs in https://gcc

Re: [PATCH 1/3]: C N2653 char8_t: Language support

On 6/11/21 12:53 PM, Jakub Jelinek wrote: On Fri, Jun 11, 2021 at 12:20:48PM -0400, Tom Honermann wrote: I'm open to whatever signaling mechanism would be preferred.  It took me a while to settle on _CHAR8_T_SOURCE as the mechanism to propose as I didn't find much for other precedents. I agree

[committed] More improvements to H8 logicals for test/compare elimination

Another round of redundant test/compare elimination on the H8. This improves our ability to use QImode logicals.  Part of the problem we needed to resolve here was that we support generating the b* instructions which do not set condition codes as well as the usual and, ior, xor. The approach

Re: [PATCH 0/3]: C N2653 char8_t implementation

On 6/11/21 1:27 PM, Joseph Myers wrote: On Fri, 11 Jun 2021, Tom Honermann via Gcc-patches wrote: The option is needed because it impacts core language backward compatibility (for both C and C++, the type of u8 string literals; for C++, the type of u8 character literals and the new char8_t fund

[Patch, fortran] PR fortran/101047/101048 Pointer explicit initialization

Hi All! Proposed patch to: Bug 101047 - Pointer explicit initialization fails Bug 101048 - Class pointer explicit initialization refuses valid Patch tested only on x86_64-pc-linux-gnu. This patch deals with implementation of explicit initialization for pointer variables. It basically relies

Re: [Patch, fortran] PR fortran/101047/101048 Pointer explicit initialization

On 13/06/21 15:46, José Rui Faustino de Sousa wrote: Hi All! Proposed patch to: And again I forgot to add the patch... Sorry for the inconvenience. Best regards, José Rui diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c index 93118ad..5670d18 100644 --- a/gcc/fortran/class.c +++ b/gc

Re: [RFC/PATCH] updating global ranges and their effect on __builtin_unreachable code

On Mon, Jun 7, 2021 at 4:32 PM Andrew MacLeod wrote: > Aldy, I think this means we can use global information in the get_global > query for ranger if "cfun->after_inlining" is true, otherwise do what we > currently do. Tested on x86-64 Linux. OK for trunk? Aldy From 914810565183ad2cdac82ed5bab

[PATCH, pushed] use range based for loops to iterate over vec<>

This changes users of FOR_EACH_VEC_ELT to use range based for loops, where the index variables are otherwise unused. As such the index variables are all deleted, producing shorter and simpler code. bootstrapped and regtested on x86_64-linux-gnu. Pushed as pre approved by Richi, in each case the

[PATCH] Fix PR 100944 - Array boundary misscalculation

This patch proposes a fix to PR 100944 by improving the array boundary computation when the flexible array has no clear constructor: if no constructor were found in the input code, we compute the size of the array as: offset(array begin) - offset(next element in RECORD_TYPE) If no next element

Re: [PATCH] c++: Don't complain about [[maybe_unused]] on non-static data members

On Fri, Jun 11, 2021 at 5:44 PM Jakub Jelinek wrote: > On Fri, Jun 11, 2021 at 10:35:58PM +0200, Jakub Jelinek wrote: > > > But I also agree that GCC shouldn't warn here. > > > > We could do that by using a wrapper around handle_unused_attribute > > for the maybe_unused attribute, that way warn o

Re: [committed] wwwdocs: readings: Remove PRU-ICSS documentation reference

On Mon, May 31, 2021 at 12:20:21AM +0200, Gerald Pfeifer wrote: > TI's server has been telling us that "The PRU-ICSS wiki is in the > process of being migrated to software-dl.ti.com" for five months. > Time to pull the plug. > --- > htdocs/readings.html | 1 - > 1 file changed, 1 deletion(-) > >

[PATCH] avr: Add atmega324pb MCU

Reference: https://www.microchip.com/wwwproducts/en/ATMEGA324PB Signed-off-by: Matwey V. Kornilov --- gcc/config/avr/avr-mcus.def | 1 + gcc/doc/avr-mmcu.texi | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/config/avr/avr-mcus.def b/gcc/config/avr/avr-mcus.def inde

[Patch, fortran] PR fortran/100948 - [12 Regression] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9069

Hi all! Proposed partial patch to: Bug 100948 - [12 Regression] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9069 Patch tested only on x86_64-pc-linux-gnu. Reuse previously calculated full string length to set string section default upper bound. This patch only fixes the ICE the code

[PATCH] i386: Improve variable permutation insn avoidance [PR101021]

Emit constant permutation insn directly from expand_vec_perm_shufb. 2021-06-13 Uroš Bizjak gcc/ PR target/101021 * config/i386/i386-expand.c (expand_vec_perm_pshufb): Emit constant permutation insn directly from here. Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Re: [RFC/PATCH] updating global ranges and their effect on __builtin_unreachable code

On 6/13/2021 10:02 AM, Aldy Hernandez via Gcc-patches wrote: On Mon, Jun 7, 2021 at 4:32 PM Andrew MacLeod wrote: Aldy, I think this means we can use global information in the get_global query for ranger if "cfun->after_inlining" is true, otherwise do what we currently do. Tested on x86-64

Re: [PATCH] arc: Add --with-fpu support for ARCv2 cpus

On 6/13/2021 4:06 AM, Bernhard Reutner-Fischer wrote: On Fri, 11 Jun 2021 14:25:24 +0300 Claudiu Zissulescu wrote: Hi Bernhard, Please find attached my latest patch, it includes (hopefully) all your feedback. Thank you for comments, concise and clean, i wouldn't know what to remove. LGTM

Re: [r12-1405 Regression] FAIL: gcc.dg/c2x-attr-maybe_unused-1.c (test for warnings, line 31) on Linux/x86_64

On 6/12/2021 3:41 PM, sunil.k.pandey via Gcc-patches wrote: On Linux/x86_64, c0f769fa3114ea852a26d93f0ee3f9595463de0b is the first bad commit commit c0f769fa3114ea852a26d93f0ee3f9595463de0b Author: Jason Merrill Date: Fri Jun 11 16:10:50 2021 -0400 c-family: don't warn for [[maybe_un

Re: [PATCH] PR tree-optimization/96392 Optimize x+0.0 if x is an integer

On 6/11/2021 5:54 AM, Richard Biener via Gcc-patches wrote: On Thu, Jun 10, 2021 at 9:45 PM Roger Sayle wrote: The patch implements a missed optimization enhancement. Under usual IEEE rules, x+0.0 can't be simplified to x when x might potentially be an IEEE minus zero (-0.0). The current

Re: [PATCH] PR libstdc++/98842: Fixed Constraints on operator<=>(optional, U)

Awesome, thanks! On Mon, Jun 7, 2021 at 11:30 AM Jonathan Wakely wrote: > On Fri, 4 Jun 2021 at 21:41, Jonathan Wakely wrote: > > > > On Thu, 3 Jun 2021 at 17:27, Seija K. via Libstdc++ < > libstd...@gcc.gnu.org> > > wrote: > > > > > The original operator was underconstrained. _Up needs to fulfi

Re: [r12-1405 Regression] FAIL: gcc.dg/c2x-attr-maybe_unused-1.c (test for warnings, line 31) on Linux/x86_64

Should be fixed now. On Sun, Jun 13, 2021, 5:36 PM Jeff Law wrote: > > > On 6/12/2021 3:41 PM, sunil.k.pandey via Gcc-patches wrote: > > On Linux/x86_64, > > > > c0f769fa3114ea852a26d93f0ee3f9595463de0b is the first bad commit > > commit c0f769fa3114ea852a26d93f0ee3f9595463de0b > > Author: Jason

Re: [PATCH] teach compute_objsize about placement new (PR 100876)

On 6/2/2021 3:40 PM, Martin Sebor via Gcc-patches wrote: The two forms of placement operator new defined in return their pointer argument and may not be displaced by user-defined functions. But because they are ordinary (not built-in) functions this property isn't reflected in their declarati

[RFA] Minor improvement to compare elimination

I was reviewing the generated code in libgcc for the H8 to see if there were any obvious redundant test/compares.  Sure enough I found one in the first file I looked at ;-) So after IRA we have something like this: (insn 43 112 44 4 (set (subreg:SI (reg:DI 40) 0)     (and:SI (subreg:SI (re

Re: [PATCH v2] Add a target calls hook: TARGET_PUSH_ARGUMENT

On 5/27/2021 2:18 PM, H.J. Lu via Gcc-patches wrote: 1. Replace PUSH_ARGS with a target calls hook, TARGET_PUSH_ARGUMENT, which takes an integer argument. When it returns true, push instructions will be used to pass outgoing arguments. If the argument is nonzero, it is the number of bytes to

Re: [PATCH] config: Backport "Rely less on internal symbols" (serial 68) to gettext.m4

On 5/23/2021 6:30 PM, Michael Forney wrote: GNU gettext introduced this change[0] in version 0.19.8 to fix gettext detection with musl libc, since it does not define these internal symbols. This allows gcc to build with musl gettext rather than falling back to the bundled version. [0] https:

Re: Ping: [PATCH 1/2] correct BB frequencies after loop changed

On 5/6/2021 8:36 PM, guojiufu via Gcc-patches wrote: Gentle ping. Original message: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html I think you need a more aggressive ping  :-) OK for the trunk.  Sorry for the long delay.  I kept hoping someone else would step in and lo

Re: [PATCH] teach compute_objsize about placement new (PR 100876)

On 14 June 2021 01:45:36 CEST, Jeff Law via Gcc-patches wrote: > > >On 6/2/2021 3:40 PM, Martin Sebor via Gcc-patches wrote: >> The two forms of placement operator new defined in return their >> pointer argument and may not be displaced by user-defined functions. >> But because they are ordinary

Re: [PATCH] teach compute_objsize about placement new (PR 100876)

On 14 June 2021 07:56:38 CEST, Bernhard Reutner-Fischer wrote: >On 14 June 2021 01:45:36 CEST, Jeff Law via Gcc-patches > wrote: >> >> >>On 6/2/2021 3:40 PM, Martin Sebor via Gcc-patches wrote: >>> The two forms of placement operator new defined in return >their >>> pointer argument and may not

Re: [PATCH] Fix PR 100944 - Array boundary misscalculation

On Sun, Jun 13, 2021 at 7:00 PM Giuliano Belinassi via Gcc-patches wrote: > > This patch proposes a fix to PR 100944 by improving the array boundary > computation when the flexible array has no clear constructor: if no > constructor were found in the input code, we compute the size of the > array