Re: [PATCH] PR tree-optimization/64992: (B << 2) != 0 is B when B is Boolean.

On Sat, Aug 13, 2022 at 12:35 AM Roger Sayle wrote: > > Hi Richard, > > > -Original Message- > > From: Richard Biener > > Sent: 08 August 2022 12:49 > > Subject: Re: [PATCH] PR tree-optimization/64992: (B << 2) != 0 is B when B > > is > > Boolean. > > > > On Mon, Aug 8, 2022 at 11:06 AM

PING^4 [PATCH v3] rs6000: Fix the check of bif argument number [PR104482]

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html BR, Kewen Hi, As PR104482 shown, it's one regression about the handlings when the argument number is more than the one of built-in function prototype. The new bif support only catches the

PING^2 [PATCH v4] rs6000: Adjust mov optabs for opaque modes [PR103353]

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597286.html BR, Kewen > > on 2022/6/27 10:47, Kewen.Lin via Gcc-patches wrote: >> Hi Segher! >> >> on 2022/6/25 00:49, Segher Boessenkool wrote: >>> Hi! >>> >>> On Fri, Jun 24, 2022 at 09:03:59AM +0800, Kewen.Lin wrote:

Re: [RFC]rs6000: split complicated constant to memory

On Mon, Aug 15, 2022 at 7:26 AM Jiufu Guo via Gcc-patches wrote: > > Hi, > > This patch tries to put the constant into constant pool if building the > constant requires 3 or more instructions. > > But there is a concern: I'm wondering if this patch is really profitable. > > Because, as I tested,

Re: [x86 PATCH] PR target/106577: force_reg may clobber operands during split.

On Fri, Aug 12, 2022 at 10:41 PM Roger Sayle wrote: > > > This patch fixes PR target/106577 which is a recent ICE on valid regression > caused by my introduction of a *testti_doubleword pre-reload splitter in > i386.md. During the split pass before reload, this converts the virtual >

Re: [PATCH] vect: Don't allow vect_emulated_vector_p type in vectorizable_call [PR106322]

Hi Richi, >> >> Yes, but you just missed the RC for 12.2 so please wait until after GCC 12.2 >> is released and the branch is open again. The testcase looks mightly >> complicated >> so fallout there might be well possible as well ;) I suppose it wasn't >> possible >> to craft a simple C

PING^1 [PATCH v2] rs6000/test: Fix empty TU in some cases of effective targets [PR106345]

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598748.html BR, Kewen on 2022/7/25 14:26, Kewen.Lin via Gcc-patches wrote: > Hi, > > As the failure of test case gcc.target/powerpc/pr92398.p9-.c in > PR106345 shows, some test sources for some powerpc effective >

Re: [PATCH] vect: Don't allow vect_emulated_vector_p type in vectorizable_call [PR106322]

On Mon, Aug 15, 2022 at 10:00 AM Kewen.Lin wrote: > > Hi Richi, > > >> > >> Yes, but you just missed the RC for 12.2 so please wait until after GCC > >> 12.2 > >> is released and the branch is open again. The testcase looks mightly > >> complicated > >> so fallout there might be well possible

Re: [PATCH take #2] PR tree-optimization/71343: Optimize (X<

On Fri, Aug 12, 2022 at 11:45 PM Roger Sayle wrote: > > > Hi Richard, > Many thanks for the review and useful suggestions. I (think I) agree that > handling non-canonical forms in value_numbering makes more sense, > so this revised patch is just the first (non-controversial) part of the >

PING^1 [PATCH] rs6000: Suggest unroll factor for loop vectorization

Hi, Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598601.html BR, Kewen on 2022/7/20 17:30, Kewen.Lin via Gcc-patches wrote: > Hi, > > Commit r12-6679-g7ca1582ca60dc8 made vectorizer accept one > unroll factor to be applied to vectorization factor when > vectorizing the main

PING^4 [PATCH] rs6000: Handle unresolved overloaded builtin [PR105485]

Hi, Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594699.html BR, Kewen >> >>> on 2022/5/13 13:29, Kewen.Lin via Gcc-patches wrote: Hi, PR105485 exposes that new builtin function framework doesn't handle unresolved overloaded builtin function well. With new

Re: [PATCH] Support threading of just the exit edge

On Fri, 12 Aug 2022, Aldy Hernandez wrote: > On Fri, Aug 12, 2022 at 2:01 PM Richard Biener wrote: > > > > This started with noticing we add ENTRY_BLOCK to our threads > > just for the sake of simplifying the conditional at the end of > > the first block in a function. That's not really

Re: [PATCH] Tame path_range_query::compute_imports

On Thu, 11 Aug 2022, Aldy Hernandez wrote: > On Thu, Aug 11, 2022 at 3:59 PM Andrew MacLeod wrote: > > > > > > On 8/11/22 07:42, Richard Biener wrote: > > > This avoids going BBs outside of the path when adding def chains > > > to the set of imports. It also syncs the code with > > >

[PATCH] Implement __builtin_issignaling

Hi! The following patch implements a new builtin, __builtin_issignaling, which can be used to implement the ISO/IEC TS 18661-1 issignaling macro. It is implemented as type-generic function, so there is just one builtin, not many with various suffixes. This patch doesn't address PR56831 nor

Re: [PATCH, OpenMP, Fortran] requires unified_shared_memory 2/2: insert USM allocators into libgfortran

On 2022/8/15 7:06 PM, Chung-Lin Tang wrote: I know this is a big pile of yarn wrt how the main program/libgomp/libgfortran  interacts, but it's finally working. Again tested without regressions. Preparing to commit to  devel/omp/gcc-12, and seeking approval for mainline when the requires 

Re: [PATCH] Implement __builtin_issignaling

On Mon, 15 Aug 2022, Jakub Jelinek wrote: > Hi! > > The following patch implements a new builtin, __builtin_issignaling, > which can be used to implement the ISO/IEC TS 18661-1 issignaling > macro. > > It is implemented as type-generic function, so there is just one > builtin, not many with

[PATCH] analyzer: warn on the use of floating points in the size argument [PR106181]

This patch fixes the ICE reported in PR106181 and adds a new warning to the analyzer complaining about the use of floating point operands. I decided to move the warning for floats inside the size argument out of the allocation size checker code and toward the allocation such that the warning only

Re: Where in C++ module streaming to handle a new bitfield added in "tree_decl_common"

On 8/2/22 10:44, Qing Zhao wrote: Hi, Nathan, I am adding a new bitfield “decl_not_flexarray” in “tree_decl_common” (gcc/tree-core.h) for the new gcc feature -fstrict-flex-arrays. diff --git a/gcc/tree-core.h b/gcc/tree-core.h index ea9f281f1cc..458c6e6ceea 100644 --- a/gcc/tree-core.h

[PATCH] fortran: Expand ieee_arithmetic module's ieee_value inline [PR106579]

Hi! The following patch expands IEEE_VALUE function inline in the FE. Bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64le-linux and powerpc64-linux, ok for trunk? 2022-08-15 Jakub Jelinek PR fortran/106579 * trans-intrinsic.cc: Include realmpfr.h.

[PATCH] fortran: Expand ieee_arithmetic module's ieee_class inline [PR106579]

Hi! The following patch expands IEEE_CLASS inline in the FE, using the __builtin_fpclassify, __builtin_signbit and the new __builtin_issignaling builtins. Bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64le-linux and powerpc64-linux, ok for trunk? 2022-08-15 Jakub Jelinek

Re: [PATCH] ifcvt: Fix up noce_convert_multiple_sets [PR106590]

On Mon, 15 Aug 2022, Jakub Jelinek wrote: > Hi! > > The following testcase is miscompiled on x86_64-linux. > The problem is in the noce_convert_multiple_sets optimization. > We essentially have: > if (g == 1) > { > g = 1; > f = 23; > } > else > { > g = 2; > f = 20; > } >

Re: [PATCH] tree-optimization/106593 - fix ICE with backward threading

On Fri, 12 Aug 2022, Andrew MacLeod wrote: > > On 8/12/22 07:31, Aldy Hernandez wrote: > > On Fri, Aug 12, 2022 at 12:59 PM Richard Biener wrote: > >> With the last re-org I failed to make sure to not add SSA names > >> nor supported by ranger into m_imports which then triggers an > >> ICE in

[PATCH] analyzer: fix for ICE in sm-fd.cc [PR106551]

This patch fixes the ICE caused by valid_to_unchecked_state in sm-fd.cc by exiting early if first argument of any "dup" functions is invalid. gcc/analyzer/ChangeLog: PR analyzer/106551 * sm-fd.cc (check_for_dup): exit early if first argument is invalid for all dup

[PATCH, OpenMP, Fortran] requires unified_shared_memory 1/2: adjust libgfortran memory allocators

Hi, this patch is to fix the case where 'requires unified_shared_memory' doesn't work due to memory allocator mismatch. Currently this is only for OG12 (devel/omp/gcc-12), but will apply to mainline as well once those requires patches get in. Basically, under 'requires unified_shared_memory'

[PATCH, OpenMP, Fortran] requires unified_shared_memory 2/2: insert USM allocators into libgfortran

After the first libgfortran memory allocator preparation patch, this is the actual patch that organizes unified_shared_memory allocation into libgfortran. In the current OpenMP requires implementation, the requires_mask is collected through offload LTO processing, and presented to libgomp when

Re: [PATCH] tree-optimization/106514 - revisit m_import compute in backward threading

On Thu, 11 Aug 2022, Andrew MacLeod wrote: > > On 8/10/22 06:46, Richard Biener wrote: > > > > I see the solver itself adds relations from edges on the path so > > the cruical item here seems to be to add imports for the path > > entry conditional, but those would likely be GORI imports for that

[PATCH] ifcvt: Fix up noce_convert_multiple_sets [PR106590]

Hi! The following testcase is miscompiled on x86_64-linux. The problem is in the noce_convert_multiple_sets optimization. We essentially have: if (g == 1) { g = 1; f = 23; } else { g = 2; f = 20; } and for each insn try to create a conditional move sequence. There is code

Re: [PATCH v6] LoongArch: add addr_global attribute

Can we make a final solution to this soon? Now the merge window of Linux 6.0 is closed and we have two Linux kernel releases not possible to be built with Binutils or GCC with new relocation types. This is just ugly... On Fri, 2022-08-12 at 17:17 +0800, Xi Ruoyao via Gcc-patches wrote: > v5 ->

Re: [PATCH] Implement __builtin_issignaling

On Aug 15 2022, Jakub Jelinek via Gcc-patches wrote: > That seems like a glibc bug/weird feature in the __MATH_TG macro > or _Generic. __MATH_TG is only defined for real floating types, since all of the type generic macros in only accept real floating types. -- Andreas Schwab, SUSE Labs,

Re: [PATCH] c++: Implement P2327R1 - De-deprecating volatile compound operations

On Mon, Aug 15, 2022 at 12:31:10PM +0200, Jakub Jelinek wrote: > Hi! > > From what I can see, this has been voted in as a DR and as it means > we warn less often than before in -std={gnu,c}++2{0,3} modes or with > -Wvolatile, I wonder if it shouldn't be backported to affected release > branches

c++: Fix module line no testcase

Not all systems have the same injected headers, leading to line location table differences that are immaterial to the test. Fix the regexp more robustly. nathan -- Nathan SidwellFrom af088b32def1c56538f0f3aaea16f013e9292d64 Mon Sep 17 00:00:00 2001 From: Nathan Sidwell Date: Mon, 15 Aug 2022

Re: Rust frontend patches v1

On 8/15/22 16:07, Manuel López-Ibáñez via Gcc-patches wrote: > Dear Philip, > > Another thing to pay attention to is the move to Sphinx for documentation: > https://gcc.gnu.org/pipermail/gcc/2022-August/239233.html Hi. Which is something I can help you with. I have a script that converts a

[PATCH] libgfortran: Use __builtin_issignaling in libgfortran

Hi! The following patch makes use of the new __builtin_issignaling, so it no longer needs the fallback implementation and can use the builtin even where glibc provides the macro. Bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64le-linux and powerpc64le-linux, ok for trunk?

Re: Rust frontend patches v1

Dear Philip, Another thing to pay attention to is the move to Sphinx for documentation: https://gcc.gnu.org/pipermail/gcc/2022-August/239233.html Best, Manuel. On Wed, 10 Aug 2022 at 20:57, Philip Herron wrote: > Hi everyone > > For my v2 of the patches, I've been spending a lot of time

Re: [x86_64 PATCH] Support shifts and rotates by integer constants in TImode STV.

On Mon, Aug 15, 2022 at 10:29 AM Roger Sayle wrote: > > > Many thanks to Uros for reviewing/approving all of the previous pieces. > This patch adds support for converting 128-bit TImode shifts and rotates > to SSE equivalents using V1TImode during the TImode STV pass. > Previously, only logical

Re: [PATCH] Implement __builtin_issignaling

On Mon, Aug 15, 2022 at 11:24:14AM +, Richard Biener wrote: > Unlike the issignalling macro from glibc the builtin will return > false for sNaN arguments when -fno-signalling-nans is used (similar > to isinf, isnan, etc.). I think this deserves mentioning in the > documentation (and I have my

Re: Where in C++ module streaming to handle a new bitfield added in "tree_decl_common"

On Mon, Aug 15, 2022 at 3:29 PM Nathan Sidwell via Gcc-patches wrote: > > On 8/2/22 10:44, Qing Zhao wrote: > > Hi, Nathan, > > > > I am adding a new bitfield “decl_not_flexarray” in “tree_decl_common” > > (gcc/tree-core.h) for the new gcc feature -fstrict-flex-arrays. > > > > > > diff

Re: [PATCH] predict: Adjust optimize_function_for_size_p [PR105818]

on 2022/7/11 11:42, Kewen.Lin wrote: > on 2022/6/15 14:20, Kewen.Lin wrote: >> Hi Honza, >> >> Thanks for the comments! Some replies are inlined below. >> >> on 2022/6/14 19:37, Jan Hubicka wrote: Hi, Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO if func->decl

Re: [PATCH] libgfortran: Use __builtin_issignaling in libgfortran

Hi Jakub, The following patch makes use of the new __builtin_issignaling, so it no longer needs the fallback implementation and can use the builtin even where glibc provides the macro. Bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64le-linux and powerpc64le-linux, ok for trunk?

Re: [PATCH] Implement __builtin_issignaling

On Mon, 15 Aug 2022, Jakub Jelinek wrote: > On Mon, Aug 15, 2022 at 11:24:14AM +, Richard Biener wrote: > > Unlike the issignalling macro from glibc the builtin will return > > false for sNaN arguments when -fno-signalling-nans is used (similar > > to isinf, isnan, etc.). I think this

Re: [PATCH] Implement __builtin_issignaling

On Mon, Aug 15, 2022 at 12:07:38PM +, Richard Biener wrote: > Ah, I misread > > +static rtx > +expand_builtin_issignaling (tree exp, rtx target) > +{ > + if (!validate_arglist (exp, REAL_TYPE, VOID_TYPE)) > +return NULL_RTX; > + > + tree arg = CALL_EXPR_ARG (exp, 0); > +

[x86_64 PATCH] Support shifts and rotates by integer constants in TImode STV.

Many thanks to Uros for reviewing/approving all of the previous pieces. This patch adds support for converting 128-bit TImode shifts and rotates to SSE equivalents using V1TImode during the TImode STV pass. Previously, only logical shifts by multiples of 8 were handled (from my patch earlier this

[PATCH] c++: Implement P2327R1 - De-deprecating volatile compound operations

Hi! >From what I can see, this has been voted in as a DR and as it means we warn less often than before in -std={gnu,c}++2{0,3} modes or with -Wvolatile, I wonder if it shouldn't be backported to affected release branches as well. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for

Re: [PATCH] Support threading of just the exit edge

On 8/12/2022 10:03 AM, Aldy Hernandez wrote: On Fri, Aug 12, 2022 at 2:01 PM Richard Biener wrote: This started with noticing we add ENTRY_BLOCK to our threads just for the sake of simplifying the conditional at the end of the first block in a function. That's not really threading anything

Re: [PATCH] analyzer: fix for ICE in sm-fd.cc [PR106551]

On Mon, 2022-08-15 at 14:02 +0530, Immad Mir wrote: > This patch fixes the ICE caused by valid_to_unchecked_state > in sm-fd.cc by exiting early if first argument of any "dup" > functions is invalid. > > gcc/analyzer/ChangeLog: > PR analyzer/106551 > * sm-fd.cc (check_for_dup):

Re: [PATCH] Implement __builtin_issignaling

Hi Jakub, Thank you for taking this on (this patch and the Fortran ones), it is really appreciated and will improve gfortran's IEEE conformance. - "Implement __builtin_issignaling”: is approved for the tiny Fortran part - "libgfortran: Use __builtin_issignaling in libgfortran”: was approved by

Re: [PATCH] Implement __builtin_issignaling

On Mon, Aug 15, 2022 at 06:14:22PM +0200, FX wrote: > Thank you for taking this on (this patch and the Fortran ones), it is really > appreciated and will improve gfortran's IEEE conformance. > > - "Implement __builtin_issignaling”: is approved for the tiny Fortran part > - "libgfortran: Use

Re: [PATCH] analyzer: warn on the use of floating points in the size argument [PR106181]

On Mon, 2022-08-15 at 14:35 +0200, Tim Lange wrote: > This patch fixes the ICE reported in PR106181 and adds a new warning > to > the analyzer complaining about the use of floating point operands. Thanks for the patch. Various comments inline... > > I decided to move the warning for floats

[COMMITTED] PR tree-optimization/106621 - Check for undefined and varying first.

We treat POLY_INT_CSTs as VARYING, but the check in irange::set for them was occurring after we called irange::set_range.  This patch merely shuffles the orders of checks around such that we check for undefined, and then varying/polyints before the other cases.  Performance impact is

Re: [PATCH] Support threading of just the exit edge

On Mon, Aug 15, 2022 at 11:39 AM Richard Biener wrote: > > On Fri, 12 Aug 2022, Aldy Hernandez wrote: > > > On Fri, Aug 12, 2022 at 2:01 PM Richard Biener wrote: > > > > > > This started with noticing we add ENTRY_BLOCK to our threads > > > just for the sake of simplifying the conditional at the

Re: [PATCH] s390: Add z15 to s390_issue_rate.

On 8/12/22 12:02, Robin Dapp wrote: > Hi, > > this patch tries to be more explicit by mentioning z15 in s390_issue_rate. > > No changes in testsuite, bootstrap or SPEC obviously. > > Is it OK? > > Regards > Robin > > gcc/ChangeLog: > > * config/s390/s390.cc (s390_issue_rate): Add z15.

Re: [PATCH] s390: Add -munroll-only-small-loops.

On 8/12/22 12:00, Robin Dapp wrote: > Hi, > > inspired by Power we also introduce -munroll-only-small-loops. This > implies activating -funroll-loops and -munroll-only-small-loops at -O2 > and above. > > Bootstrapped and regtested. > > This introduces one regression in

Re: [PATCH] c: Implement C23 nullptr (N3042)

On Sat, 13 Aug 2022, Marek Polacek via Gcc-patches wrote: > This patch also defines nullptr_t in . I'm uncertain about > the __STDC_VERSION__ version I should be checking. Also, I'm not We're using defined (__STDC_VERSION__) && __STDC_VERSION__ > 201710L until the final version for C23 is

[committed] analyzer: fix direction of -Wanalyzer-out-of-bounds note [PR106626]

Fix a read/write typo. Also, add more test coverage of -Wanalyzer-out-of-bounds to help establish a baseline for experiments on tweaking the wording of the warning (PR analyzer/106626). Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r13-2054-g23e8c0b0d99f58.

[committed] analyzer: better fix for -Wanalyzer-use-of-uninitialized-value [PR106573]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r13-2053-gca123e019bb92f. gcc/analyzer/ChangeLog: PR analyzer/106573 * region-model.cc (region_model::on_call_pre): Use check_call_args when ensuring that we call get_arg_svalue on all args.

[PATCH] tree-object-size: Support strndup and strdup

Use string length of input to strdup to determine the usable size of the resulting object. Avoid doing the same for strndup since there's a chance that the input may be too large, resulting in an unnecessary overhead or worse, the input may not be NULL terminated, resulting in a crash where there

Re: [PATCH] Support threading of just the exit edge

heh. or just +  int_range<2> r; +  if (!fold_range (r, const_cast (cond_stmt)) +      || !r.singleton_p ()) if you do not provide a range_query to any of the fold_using_range code, it defaults to: fur_source::fur_source (range_query *q) {   if (q)     m_query = q;   else if (cfun)

Re: [PATCH] fortran: Expand ieee_arithmetic module's ieee_class inline [PR106579]

Question to the Fortran maintainers: Do you know if the standard allows IEEE_CLASS and IEEE_VALUE to be used as procedure pointers? I think not, because they do not follow (in F2008) the standard constraint C729 / R740. If so, we need to keep these functions implementations in libgfortran for

Re: [PATCH] c++: Implement P2327R1 - De-deprecating volatile compound operations

On 8/15/22 03:31, Jakub Jelinek wrote: From what I can see, this has been voted in as a DR and as it means we warn less often than before in -std={gnu,c}++2{0,3} modes or with -Wvolatile, I wonder if it shouldn't be backported to affected release branches as well. If people are complaining

Re: [PATCH] Support threading of just the exit edge

On Mon, Aug 15, 2022 at 9:24 PM Andrew MacLeod wrote: > > heh. or just > > > + int_range<2> r; > + if (!fold_range (r, const_cast (cond_stmt)) > + || !r.singleton_p ()) > > > if you do not provide a range_query to any of the fold_using_range code, > it defaults to: > >

Re: [PATCH] c++: Implement -Wself-move warning [PR81159]

On 8/9/22 09:37, Marek Polacek wrote: About 5 years ago we got a request to implement -Wself-move, which warns about useless moves like this: int x; x = std::move (x); This patch implements that warning. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? PR c++/81159

Re: [PATCH] c: Implement C23 nullptr (N3042)

On 8/13/22 14:35, Marek Polacek wrote: This patch implements the C23 nullptr literal: , which is intended to replace the problematic definition of NULL which might be either of integer type or void*. Since C++ has had nullptr for over

Re: [PATCH v3] rs6000: Adjust mov optabs for opaque modes [PR103353]

Hi! On Mon, Jun 27, 2022 at 10:47:26AM +0800, Kewen.Lin wrote: > on 2022/6/25 00:49, Segher Boessenkool wrote: > Many thanks for all the further explanation above! The attached patch > updated the misleading comments as you pointed out and suggested, could > you help to have another look?

[committed] d: Field names of anonymous delegates should be same as regular delegate types.

Hi, This patch adjusts the field names of delegate csts constructed inline. Doesn't change anything in the code generation or ABI, but makes it consistent with regular delegates as names would match up when inspecting tree dumps. Regression tested on x86_64-linux-gnu and committed to mainline.

[committed] d: Build internal TypeInfo types when module name is "object"

Hi, This patch is a fix-up for a previous change in r13-1070. If for whatever reason the module declaration doesn't exist in the object file, ensure that the internal definitions for TypeInfo and TypeInfo_Class are still created, otherwise an ICE could occur later if they are required for a

[committed] d: Defer compiling inline definitions until after the module has finished.

Hi, This patch is a follow-up to r13-2002 and r12-8673 (PR d/106563), that instead pushes inline definitions onto a deferred list to be compiled after the current module has finished. This is to prevent the case of when generating the methods of a struct type, we don't accidentally emit an

Re: [PATCH v2] c++: Extend -Wredundant-move for const-qual objects [PR90428]

On 8/8/22 13:27, Marek Polacek wrote: On Sat, Aug 06, 2022 at 03:58:13PM -0800, Jason Merrill wrote: On 8/6/22 11:13, Marek Polacek wrote: In this PR, Jon suggested extending the -Wredundant-move warning to warn when the user is moving a const object as in: struct T { }; T f(const T&

Re: [PATCH][_GLIBCXX_DEBUG] Add basic_string::starts_with/ends_with checks

With the patch ! On 14/08/22 17:32, François Dumont wrote: I think we can add those checks. Note that I wonder if it was needed as in basic_string_view I see usages of __attribute__((__nonnull__)). But running the test I saw no impact even after I try to apply this attribute to the

[committed] d: Fix internal compiler error: Segmentation fault at gimple-expr.cc:88

Hi, This patch fixes an ICE in the middle-end caused by the D front-end's code generation for the special enum representing native complex types. Because complex types are deprecated in the language, the new way to expose native complex types is by defining an enum with a basetype of a

Re: [PATCH] Implement __builtin_issignaling

On Mon, Aug 15, 2022 at 12:12 PM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > The following patch implements a new builtin, __builtin_issignaling, > which can be used to implement the ISO/IEC TS 18661-1 issignaling > macro. > > It is implemented as type-generic function, so there is just one

Re: [PATCH] fortran: Expand ieee_arithmetic module's ieee_value inline [PR106579]

Hi Jakub, I have two questions, on this and the ieee_class patch: > + tree type = TREE_TYPE (arg); > + gcc_assert (TREE_CODE (type) == RECORD_TYPE); > + tree field = NULL_TREE; > + for (tree f = TYPE_FIELDS (type); f != NULL_TREE; f = DECL_CHAIN (f)) > +if (TREE_CODE (f) == FIELD_DECL)

Re: [PATCH] fortran: Expand ieee_arithmetic module's ieee_class inline [PR106579]

On Mon, Aug 15, 2022 at 09:47:45PM +0200, FX wrote: > Question to the Fortran maintainers: > > Do you know if the standard allows IEEE_CLASS and IEEE_VALUE to be used as > procedure pointers? I think not, because they do not follow (in F2008) the > standard constraint C729 / R740. > > If so,

Re: [PATCH] fortran: Expand ieee_arithmetic module's ieee_value inline [PR106579]

On Mon, Aug 15, 2022 at 10:00:02PM +0200, FX wrote: > I have two questions, on this and the ieee_class patch: > > > > + tree type = TREE_TYPE (arg); > > + gcc_assert (TREE_CODE (type) == RECORD_TYPE); > > + tree field = NULL_TREE; > > + for (tree f = TYPE_FIELDS (type); f != NULL_TREE; f =

Re: [RFC]rs6000: split complicated constant to memory

Hi! On Mon, Aug 15, 2022 at 01:25:19PM +0800, Jiufu Guo wrote: > This patch tries to put the constant into constant pool if building the > constant requires 3 or more instructions. > > But there is a concern: I'm wondering if this patch is really profitable. > > Because, as I tested, 1. for

Re: [PATCH v3] rs6000: Adjust mov optabs for opaque modes [PR103353]

Hi Segher, Thanks for the review! on 2022/8/16 05:30, Segher Boessenkool wrote: > Hi! > > On Mon, Jun 27, 2022 at 10:47:26AM +0800, Kewen.Lin wrote: >> on 2022/6/25 00:49, Segher Boessenkool wrote: >> Many thanks for all the further explanation above! The attached patch >> updated the

Re: [PATCH] s390: Use vpdi and verllg in vec_reve.

On 8/12/22 12:13, Robin Dapp wrote: > Hi, > > swapping the two elements of a V2DImode or V2DFmode vector can be done > with vpdi instead of using the generic way of loading a permutation mask > from the literal pool and vperm. > > Analogous to the V2DI/V2DF case reversing the elements of a

Re: -Wformat-overflow handling for %b and %B directives in C2X standard

вт, 12 апр. 2022 г. в 00:56, Marek Polacek : > > On Thu, Apr 07, 2022 at 02:10:48AM +0500, Frolov Daniil wrote: > > Hello! Thanks for your feedback. I've tried to take into account your > > comments. New patch applied to the letter. > > Thanks. > > > The only thing I have not removed is the

Re: [RFC]rs6000: split complicated constant to memory

Hi, Richard Biener writes: > On Mon, Aug 15, 2022 at 7:26 AM Jiufu Guo via Gcc-patches > wrote: >> >> Hi, >> >> This patch tries to put the constant into constant pool if building the >> constant requires 3 or more instructions. >> >> But there is a concern: I'm wondering if this patch is

[PATCH] RISC-V missing __builtin_lceil and __builtin_lfloor

Hello, Currently, __builtin_lceil and __builtin_lfloor doesn't generate an existing instruction fcvt, but rather calls ceil and floor from the library. This patch adds the missing iterator and attributes for lceil and lfloor to produce the optimized code. The test cases check the correct

Re: [PATCH V2] arm: add -static-pie support

Yes, this is a 1st submission. Yes, I guess I was going for DCO rules. I will look at running the test suite. Does this need to be done on the target? because my arm target is a measly dual core 1ghz embedded chip and low ram. Netgear R7000 router actually. regards Lance On 8/10/2022 2:30

Re: [PATCH] xtensa: Turn on -fsplit-wide-types-early by default

On Sun, Aug 14, 2022 at 2:31 AM Takayuki 'January June' Suwa wrote: > > Since GCC10, the "subreg2" optimization pass was no longer tied to enabling > "subreg1" unless -fsplit-wide-types-early was turned on (PR88233). However > on the Xtensa port, the lack of "subreg2" can degrade the quality of