Re: Fix testsuite/g++.dg/cpp1y/constexpr-66093.C execution failure...

On Jan 4, 2021, Mike Stump wrote: > Oh, It's possible the comments were stripped from the bug report or > initial email. Never mind then about the comment part. Thanks, I'm installing the initial patch. Please let me know in case I mistook the above as approval thereof. -- Alexandre Oliva,

robustify vxworks glimits.h overriding

The glimits.h overriding used in gcc/config/t-vxworks was fragile: the intermediate file would already be there in a rebuild, and so the adjustments would not be made, so the generated limits.h would miss them, causing limits-width-[12] tests to fail on that target. While changing it, I also

use -mfpu=neon for arm/simd/vmmla_1.c

On some of our arm targets, we get various -mfpu flags implicitly or explicitly passed to the compiler during test runs. The target options pushed in arm_neon.h that affect vmmlaq_s32 set isa_bit_neon, but the caller doesn't have that bit set, so arm_can_inline_p rejects the attempt to inline

add alignment to enable store merging in strict-alignment targets

In g++.dg/opt/store-merging-2.C, the natural alignment of types T and S is a single byte, so we shouldn't expect store merging on strict-alignment platforms. Indeed, without something like the adjust-alignment pass to bump up the alignment of the automatic variable, as in GCC 10, the

calibrate intervals to avoid zero in futures poll test

We get occasional failures of 30_threads/future/members/poll.cc on some platforms whose high resolution clock doesn't have such a high resolution; wait_for_0 ends up as 0, and then some asserts fail as intervals measured as longer than zero are tested for less than several times zero. This

Re: [PATCH]i386: Optimize pmovskb on zero_extend of subreg HI of the result [PR98461]

On Tue, Jan 5, 2021 at 8:04 AM Uros Bizjak wrote: > > > > +(define_split > > + [(set (match_operand:SI 0 "register_operand") > > +(zero_extend:SI > > + (not:HI > > +(subreg:HI > > + (unspec:SI > > +[(match_operand:V16QI 1

Re: [PATCH]i386: Optimize pmovskb on zero_extend of subreg HI of the result [PR98461]

On Tue, Jan 5, 2021 at 7:30 AM Hongtao Liu wrote: > > On Mon, Jan 4, 2021 at 4:59 PM Hongtao Liu wrote: > > > > On Mon, Jan 4, 2021 at 4:49 PM Jakub Jelinek wrote: > > > > > > On Mon, Jan 04, 2021 at 01:56:44PM +0800, Hongtao Liu via Gcc-patches > > > wrote: > > > > +(define_insn_and_split

Re: [PATCH] Restore input_location after recursive expand_call_inline

On 1/4/21 10:23 PM, Jeff Law wrote: > > > On 1/4/21 1:12 PM, Bernd Edlinger wrote: >> Hi, >> >> I spotted a place where input_location is clobbered accidentally. >> >> That is in a recursive call to expand_call_inline. The input_location >> is usually restored by goto egress in this

Re: [PATCH]i386: Optimize pmovskb on zero_extend of subreg HI of the result [PR98461]

On Mon, Jan 4, 2021 at 4:59 PM Hongtao Liu wrote: > > On Mon, Jan 4, 2021 at 4:49 PM Jakub Jelinek wrote: > > > > On Mon, Jan 04, 2021 at 01:56:44PM +0800, Hongtao Liu via Gcc-patches wrote: > > > +(define_insn_and_split "*sse2_pmovskb_zexthisi" > > > + [(set (match_operand:SI 0

Re: [PATCH] x86: Cast to unsigned short first for _mm_extract_pi16

On 1/1/21 6:34 AM, H.J. Lu via Gcc-patches wrote: > _mm_extract_pi16 is intrinsic for pextrw, which should be zero-extended, > not sign-extended. > > gcc/ > > PR target/98495 > * config/i386/xmmintrin.h (_mm_extract_pi16): Cast to unsigned > short first. I'd tend to prefer

Re: [PATCH] ira: Skip some pseudos in move_unallocated_pseudos

Hi Jeff, on 2021/1/5 上午7:13, Jeff Law wrote: > > > On 12/22/20 11:40 PM, Kewen.Lin via Gcc-patches wrote: >> Hi Segher, >> >> on 2020/12/22 下午9:55, Segher Boessenkool wrote: >>> Hi! >>> >>> Just a dumb formatting comment: >>> >>> On Tue, Dec 22, 2020 at 04:05:39PM +0800, Kewen.Lin wrote:

Go patch committed: Accept -fgo-embedcfg option

This patch adds a new -fgo-embedcfg option. This will be used by the go command to implement the go:embed directive that is new in the upcoming Go 1.16 release. The option doesn't yet do anything, this is just framework. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to

[PATCH] c++: ICE with deferred noexcept when deducing targs [PR82099]

In this test we ICE in type_throw_all_p because it got a deferred noexcept which it shouldn't. Here's the story: In noexcept61.C, we call bar, so we perform overload resolution. When adding the (only) candidate, we need to deduce template arguments, so call fn_type_unification as usually. That

Re: [committed] analyzer: fix ICE with -fsanitize=undefined [PR98293]

On Mon, Jan 04, 2021 at 07:22:58PM -0500, David Malcolm via Gcc-patches wrote: > --- a/gcc/analyzer/store.cc > +++ b/gcc/analyzer/store.cc > @@ -524,10 +524,27 @@ binding_map::apply_ctor_to_region (const region > *parent_reg, tree ctor, >unsigned ix; >tree index; >tree val; > + tree

[committed] analyzer: fix ICE with -fsanitize=undefined [PR98293]

-fsanitize=undefined with calls to nonnull functions creates struct __ubsan_nonnull_arg_data instances with CONSTRUCTORs for RECORD_TYPEs with NULL index values. The analyzer was mistakenly using INTEGER_CST for these fields, leading to ICEs. Fix the issue by iterating through the fields in the

Re: [PATCH, rs6000] improve vec_ctf invalid parameter handling. (pr91903)

On Mon, 2020-10-26 at 16:22 -0500, will schmidt wrote: > [PATCH, rs6000] improve vec_ctf invalid parameter handling. > > Hi, > Per PR91903, GCC ICEs when we attempt to pass a variable > (or out of range value) into the vec_ctf() builtin. Per > investigation, the parameter checking exists for

Re: [PATCH] correct -Wmismatched-new-delete for template instantiations (PR 98305)

On 12/16/20 7:10 PM, Martin Sebor via Gcc-patches wrote: > The -Wmismatched-new-delete detection of operator members of class > template instantiations is incomplete and overly simplistic, leading > to incorrect results and false positives.  Rather than reinventing > the wheel and parsing the

Re: [PATCH] store VLA bounds in attribute access as strings (PR 97172)

On 1/4/21 2:10 PM, Jeff Law wrote: On 1/4/21 1:53 PM, Martin Sebor wrote: On 1/4/21 12:23 PM, Jeff Law wrote: On 1/4/21 12:19 PM, Jakub Jelinek wrote: On Mon, Jan 04, 2021 at 12:14:15PM -0700, Jeff Law via Gcc-patches wrote: Doing the STRING_CST is certainly less fragile since the SSA

Re: [PATCH] simplify-rtx: Optimize (x - 1) * y + y [PR98334]

On 12/17/20 7:55 AM, Jakub Jelinek wrote: > Hi! > > We don't try to optimize for signed x, y (int) (x - 1U) * y + y > into x * y, we can't do that with signed x * y, because the former > is well defined for INT_MIN and -1, while the latter is not. > We could perhaps optimize it during isel or

Re: [PATCH] libtool.m4: update GNU/Hurd test from upstream

Hello, Jeff Law, le lun. 04 janv. 2021 13:29:53 -0700, a ecrit: > On 12/23/20 6:12 PM, Samuel Thibault wrote: > > In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed > > detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink. > > This backports it. > > > >

Re: [PATCH] ira: Skip some pseudos in move_unallocated_pseudos

On 12/22/20 11:40 PM, Kewen.Lin via Gcc-patches wrote: > Hi Segher, > > on 2020/12/22 下午9:55, Segher Boessenkool wrote: >> Hi! >> >> Just a dumb formatting comment: >> >> On Tue, Dec 22, 2020 at 04:05:39PM +0800, Kewen.Lin wrote: >>> This patch is to make move_unallocated_pseudos consistent >>>

[PATCH] c++: Fix deduction from the type of an NTTP

In the testcase nontype-auto17.C below, the calls to f and g are invalid because neither deduction nor defaulting of the template parameter T yields a valid specialization. Deducing T doesn't work because T is only used in a non-deduced context, and defaulting T doesn't work because its default

Re: [PATCH] dec_math.f90 needs to be xfailed

On Mon, Jan 04, 2021 at 02:30:43PM -0700, Jeff Law wrote: > > On 1/2/21 1:34 AM, Steve Kargl via Gcc-patches wrote: > > Can someone, anyone, please commit the following trivially patch? > > gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*. > Why will the test never pass on that

Re: [PATCH] configure: Extend SHF_GNU_RETAIN conftest to check for unsupported gold

On 12/16/20 11:39 AM, Jozef Lawrynowicz wrote: > Since "6fbec038f7a Use SHF_GNU_RETAIN to preserve symbol definitions", > GCC could create sections with the 'R' flag, which GAS would map to > SHF_GNU_RETAIN. > > SHF_GNU_RETAIN support was not available in gold until Binutils commit >

Re: [PATCH] Add line debug info for virtual thunks (PR ipa/97937)

On 1/4/21 1:06 PM, Bernd Edlinger wrote: > Hi, > > > currently there is a problem when debugging a virtual thunk. That is > a decl with DECL_IGNORED_P. Currently the line information displayed > in gdb is completely bogus, thus the last line of whatever function > is immediately before the PC

Re: [PATCH] dec_math.f90 needs to be xfailed

On 1/2/21 1:34 AM, Steve Kargl via Gcc-patches wrote: > Can someone, anyone, please commit the following trivially patch? > gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*. Why will the test never pass on that platform?  I don't mind installing the patch, but I'd like to have a bit

Re: [PATCH] Restore input_location after recursive expand_call_inline

On 1/4/21 1:12 PM, Bernd Edlinger wrote: > Hi, > > I spotted a place where input_location is clobbered accidentally. > > That is in a recursive call to expand_call_inline. The input_location > is usually restored by goto egress in this function. > > Additionally the return value of the

Re: [PATCH] store VLA bounds in attribute access as strings (PR 97172)

On Mon, Jan 04, 2021 at 02:10:39PM -0700, Jeff Law wrote: > > I explained what the code handles and when in the pipeline in > > the discussion of the previous patch: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559770.html > Right, but that message talks about GC.  This is not a GC

Re: [PATCH] MIPS: Fix PR target/98491 (ChangeLog)

On 1/4/21 2:00 PM, Jakub Jelinek wrote: > On Mon, Jan 04, 2021 at 01:51:59PM -0700, Jeff Law via Gcc-patches wrote: >>> Sorry, I forgot to include the ChangeLog: >>> >>> gcc/ChangeLog: >>> >>> 2020-12-31 Xi Ruoyao >>> >>> PR target/98491 >>> *

Re: [PATCH] rtl-ssa: Fix updates to call clobbers [PR98403]

On 12/21/20 9:32 AM, Richard Sandiford wrote: > In the PR, fwprop was changing a call instruction and tripped > an assert when trying to update a list of call clobbers. > There are two ways we could handle this: remove the call clobber > and then add it back, or assume that the clobber will

Re: [PATCH] store VLA bounds in attribute access as strings (PR 97172)

On 1/4/21 1:53 PM, Martin Sebor wrote: > On 1/4/21 12:23 PM, Jeff Law wrote: >> >> >> On 1/4/21 12:19 PM, Jakub Jelinek wrote: >>> On Mon, Jan 04, 2021 at 12:14:15PM -0700, Jeff Law via Gcc-patches >>> wrote: > Doing the STRING_CST is certainly less fragile since the SSA names > created

Re: cxx status update

On 1/4/21 3:33 PM, Gerald Pfeifer wrote: Hi Nathan, On Mon, 4 Jan 2021, Nathan Sidwell wrote: Here's a patch describing the c++20 modules status. While there I noticed the coroutines project status was out of date (it's done). ok? you don't need extra approval for release note entries in

Re: [PATCH] c++: Fix ICE with __builtin_bit_cast [PR98469]

On 1/4/21 3:48 PM, Jakub Jelinek wrote: On Mon, Jan 04, 2021 at 03:44:46PM -0500, Jason Merrill wrote: This change is OK, but part of the problem is that we're trying to do overload resolution for an S copy/move constructor, which we shouldn't be because bit_cast is a prvalue, so in C++17 and

Re: [PATCH] MIPS: Fix PR target/98491 (ChangeLog)

On Mon, Jan 04, 2021 at 01:51:59PM -0700, Jeff Law via Gcc-patches wrote: > > Sorry, I forgot to include the ChangeLog: > > > > gcc/ChangeLog: > > > > 2020-12-31 Xi Ruoyao > > > > PR target/98491 > > * config/mips/mips.c (mips_symbol_insns): Do not use >

Re: [PATCH] store VLA bounds in attribute access as strings (PR 97172)

On 1/4/21 12:23 PM, Jeff Law wrote: On 1/4/21 12:19 PM, Jakub Jelinek wrote: On Mon, Jan 04, 2021 at 12:14:15PM -0700, Jeff Law via Gcc-patches wrote: Doing the STRING_CST is certainly less fragile since the SSA names created at gimplification time could even be ggc_freed when no longer used

Re: [PATCH] MIPS: Fix PR target/98491 (ChangeLog)

On 12/31/20 4:34 PM, Xi Ruoyao via Gcc-patches wrote: > On 2021-01-01 07:29 +0800, Xi Ruoyao wrote: >> An invalid use of MSA_SUPPORTED_MODE_P is causing ICE on mips64el with -mmsa. >> The detailed analysis is posted on bugzilla: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98491 >> >> The

[PATCH][tree-optimization]Optimize combination of comparisons to dec+compare

Ping. -Original Message- From: Eugene Rozenfeld Sent: Tuesday, December 22, 2020 3:01 PM To: Richard Biener ; gcc-patches@gcc.gnu.org Subject: RE: Optimize combination of comparisons to dec+compare Re-sending my question and re-attaching the patch. Richard, can you please clarify your

Re: [PATCH] c++: Fix ICE with __builtin_bit_cast [PR98469]

On Mon, Jan 04, 2021 at 03:44:46PM -0500, Jason Merrill wrote: > This change is OK, but part of the problem is that we're trying to do > overload resolution for an S copy/move constructor, which we shouldn't be > because bit_cast is a prvalue, so in C++17 and up we should use it to > directly

Re: [C PATCH] [testsuite] bogus warning [P98029]

On Wed, 23 Dec 2020, Uecker, Martin wrote: > With the fix to PR98047 "C: Drop qualifiers of assignment expressions." > also the new incorrect warning for assignment of certain volatile expressions > introduced by dropping qualifiers in lvalue conversion (PR97702) > disappeared [P98029]. This

Re: [PATCH] c++: Fix ICE with __builtin_bit_cast [PR98469]

On 12/30/20 4:13 AM, Jakub Jelinek wrote: Hi! On the following testcase we ICE during constexpr evaluation (for warnings), because the IL has ADDR_EXPR of BIT_CAST_EXPR and ADDR_EXPR case asserts the result is not a CONSTRUCTOR. I've tried to force a temporary for those in call.c next to:

Re: [C PATCH] [testsuite] bogus warning [P98029]

On 12/23/20 1:00 AM, Uecker, Martin wrote: > > With the fix to PR98047 "C: Drop qualifiers of assignment expressions." > also the new incorrect warning for assignment of certain volatile expressions > introduced by dropping qualifiers in lvalue conversion (PR97702) > disappeared [P98029]. This

Re: cxx status update

Hi Nathan, On Mon, 4 Jan 2021, Nathan Sidwell wrote: > Here's a patch describing the c++20 modules status. While there I > noticed the coroutines project status was out of date (it's done). > > ok? you don't need extra approval for release note entries in your areas of

Re: [PATCH] libtool.m4: update GNU/Hurd test from upstream

On 12/23/20 6:12 PM, Samuel Thibault wrote: > In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed > detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink. > This backports it. > > ChangeLog: > > * libtool.m4: Match gnu* along other GNU systems. >

Re: [PATCH v2] C-family : Add attribute 'unavailable'.

On Mon, 21 Dec 2020, Iain Sandoe wrote: > Hi Joseph, > > Nathan has approved this from the C++ perspective (and Martin said that his > comments were "not necessarily to object to the idea behind the attribute but > to draw attention to the fact that it's not suitable for standard APIs.”) > >

Re: [PATCH] build: libcody: Link with -lsocket -lnsl if necessary [PR98316]

On 12/17/20 6:27 AM, Nathan Sidwell wrote: > On 12/17/20 7:21 AM, Rainer Orth wrote: >> With the introduction of C++20 modules and libcody, cc1plus and >> cc1objplus gained a dependency on the socket functions.  Before those >> were merged into libc in Solaris 11.4, one needed to link with >>

[PATCH] Restore input_location after recursive expand_call_inline

Hi, I spotted a place where input_location is clobbered accidentally. That is in a recursive call to expand_call_inline. The input_location is usually restored by goto egress in this function. Additionally the return value of the recursive expand call is thrown away, which does not look like a

[PATCH] Add line debug info for virtual thunks (PR ipa/97937)

Hi, currently there is a problem when debugging a virtual thunk. That is a decl with DECL_IGNORED_P. Currently the line information displayed in gdb is completely bogus, thus the last line of whatever function is immediately before the PC of the thunk. This patch improves the debug experience

[r11-6448 Regression] FAIL: g++.dg/modules/builtin-3_a.C -std=c++2a scan-lang-dump module "Wrote GMF:-[0-9]* type_decl:'::__builtin_va_list'@builtins" on Linux/x86_64

On Linux/x86_64, a5469584f61abeec98ff89347294f9ed72eca280 is the first bad commit commit a5469584f61abeec98ff89347294f9ed72eca280 Author: Nathan Sidwell Date: Mon Jan 4 07:45:36 2021 -0800 c++: Add stdlib module test cases caused FAIL: g++.dg/modules/builtin-3_a.C -std=c++17

Re: Fix testsuite/g++.dg/cpp1y/constexpr-66093.C execution failure...

On Jan 1, 2021, at 6:41 PM, Alexandre Oliva wrote: > > On Jan 1, 2021, Mike Stump wrote: > >> On Jan 1, 2021, at 3:37 PM, Alexandre Oliva wrote: >>> >>> On Dec 29, 2020, Mike Stump wrote: >>> a[i-1] = i; >>> >>> 'fraid that won't pass: >>> >>> for (int i = 0; i < n; i++) { >>>

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

On 12/31/20 7:13 AM, abebeos wrote: > > > On Wed, 30 Dec 2020 at 05:41, Jeff Law > wrote: > > > > On 12/23/20 9:01 AM, abebeos wrote: > > > > > > On Sun, 13 Dec 2020 at 20:14, abebeos > >

Re: [PATCH] store VLA bounds in attribute access as strings (PR 97172)

On 1/4/21 12:19 PM, Jakub Jelinek wrote: > On Mon, Jan 04, 2021 at 12:14:15PM -0700, Jeff Law via Gcc-patches wrote: >>> Doing the STRING_CST is certainly less fragile since the SSA names >>> created at gimplification time could even be ggc_freed when no longer >>> used in the IL. >> Obviously

Re: [PATCH] store VLA bounds in attribute access as strings (PR 97172)

On Mon, Jan 04, 2021 at 12:14:15PM -0700, Jeff Law via Gcc-patches wrote: > > Doing the STRING_CST is certainly less fragile since the SSA names > > created at gimplification time could even be ggc_freed when no longer > > used in the IL. > Obviously we can't use SSA_NAMEs as they're specific to

Re: [PATCH] explow, aarch64: Fix force-Pmode-to-mem for ILP32 [PR97269]

On 1/4/21 4:46 AM, Richard Sandiford via Gcc-patches wrote: > This patch fixes a mode/rtx mismatch for ILP32 targets in: > > mem = force_const_mem (ptr_mode, imm); > > where imm can be Pmode rather than ptr_mode. > > The patch uses convert_memory_address to convert the Pmode address >

Re: [PATCH] store VLA bounds in attribute access as strings (PR 97172)

On 1/4/21 5:59 AM, Richard Biener via Gcc-patches wrote: > On Sun, Dec 20, 2020 at 6:43 PM Martin Sebor wrote: >> On 12/19/20 12:48 AM, Richard Biener via Gcc-patches wrote: >>> On December 19, 2020 1:55:02 AM GMT+01:00, Martin Sebor via Gcc-patches >>> wrote: To keep tree expressions

[PING][PATCH] correct -Wmismatched-new-delete for template instantiations (PR 98305)

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562141.html On 12/16/20 7:10 PM, Martin Sebor wrote: The -Wmismatched-new-delete detection of operator members of class template instantiations is incomplete and overly simplistic, leading to incorrect results and false positives. 

Re: [committed] libgomp: Avoid bad "up" link in libgomp docs

On 12/28/20 6:00 PM, Gerald Pfeifer wrote: A bit ago I asked Sandra for advise on how to get rid of the bad "up" link in our libgomp docs, and she kindly provided the patch below which I now pushed. Is there something I could have done differently so that Author: in Git lists her instead of me?

cxx status update

Here's a patch describing the c++20 modules status. While there I noticed the coroutines project status was out of date (it's done). ok? nathan -- Nathan Sidwell diff --git i/htdocs/gcc-11/changes.html w/htdocs/gcc-11/changes.html index f457b7e7..e044d710 100644 ---

Re: docs: Fix wording describing the hwaddress sanitizer

On 1/4/21 4:15 AM, Matthew Malcomson wrote: The original documentation added to mention the clash between -fsanitize=address and -fsanitize=hwaddress used confusing wording trying to say that -fsanitize=hwaddress is only available on AArch64. It read as if -fsanitize=address were only supported

Re: [PATCH v4] rs6000, vector integer multiply/divide/modulo instructions

Segher, Will: Just wanted to ping you both on this patch. It has been out there for awhile. Carl On Mon, 2020-12-07 at 16:31 -0800, Carl Love wrote: > Will: > > I have addressed you comments with regards to the Change Log > entries. > > The extra define vec_div was

c++: Add stdlib module test cases

The remaining modules tests use the std library. These are those. gcc/testsuite/ * g++.dg/modules/binding-1_a.H: New. * g++.dg/modules/binding-1_b.H: New. * g++.dg/modules/binding-1_c.C: New. * g++.dg/modules/binding-2.H: New. *

Re: [08/23] Add an alternative splay tree implementation

Andreas Schwab writes: > On Jan 04 2021, Richard Sandiford wrote: > >> Andreas Schwab writes: >>> That doesn't build with gcc 4.8: >> >> Which subversion are you using? > > This is 4.8.1. Hmm, OK. I guess that raises the question whether “supporting GCC 4.8” means supporting every patchlevel,

Re: [07/23] Add a class that multiplexes two pointer types

On 12/17/20 8:44 AM, Nathan Sidwell wrote: > On 12/17/20 10:38 AM, Richard Sandiford via Gcc-patches wrote: >> Tom Tromey writes: "Richard" == Richard Sandiford via Gcc-patches writes: >>> >>> Richard> +// A class that stores a choice "A or B", where A has type >>> T1 * and

Re: [20/23] rtlanal: Add simple_regno_set

On 12/16/20 5:47 PM, Richard Sandiford wrote: > Jeff Law writes: >> On 11/13/20 1:21 AM, Richard Sandiford via Gcc-patches wrote: >>> This patch adds a routine for finding a “simple” SET for a register >>> definition. See the comment in the patch for details. >>> >>> gcc/ >>> * rtl.h

Re: [08/23] Add an alternative splay tree implementation

On 12/16/20 5:29 PM, Richard Sandiford wrote: > Jeff Law writes: >> On 11/13/20 1:15 AM, Richard Sandiford via Gcc-patches wrote: >>> We already have two splay tree implementations: the old C one in >>> libiberty and a templated reimplementation of it in typed-splay-tree.h. >>> However, they

Re: [RFC] middle-end: Extend CSE to understand vector extracts.

On 1/4/21 7:13 AM, Richard Biener wrote: > On Mon, 4 Jan 2021, Tamar Christina wrote: > >> Hi Richi, >> >>> -Original Message- >>> From: Richard Biener >>> Sent: Monday, January 4, 2021 1:33 PM >>> To: Tamar Christina >>> Cc: gcc-patches@gcc.gnu.org; nd ; i...@airs.com; >>>

Re: [committed] doc: Remove HSAIL from Language Standards

Hi Gerald, On Tue, Dec 29 2020, Gerald Pfeifer wrote: > On Tue, 29 Dec 2020, Martin Jambor wrote: >>> commit 7e999bd84f47205dc44b0f2dc90b53b3c888ca48 >>> Author: Gerald Pfeifer >>> Date: Mon Dec 28 21:41:55 2020 +0100 >>> >>> doc: Remove HSAIL from Language Standards >>> >>>

[PATCH] PING implement pre-c++20 contracts

Ping. re: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561135.html > OK, I'll start with -alt then, thanks. > > Andrew is exactly correct, contracts-jac-alt is still the current branch > we're focusing our upstreaming efforts on. > > It's trailing upstream master by a fair bit at this

Re: [08/23] Add an alternative splay tree implementation

On Jan 04 2021, Richard Sandiford wrote: > Andreas Schwab writes: >> That doesn't build with gcc 4.8: > > Which subversion are you using? This is 4.8.1. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for

Re: [08/23] Add an alternative splay tree implementation

Andreas Schwab writes: > That doesn't build with gcc 4.8: Which subversion are you using? It works for me with stock gcc 4.8.5, which is what I'd used to test the series for C++ compatiblity. Richard > > In file included from ../../gcc/splay-tree-utils.h:491:0, > from

[libcody] Remove some std::move [PR 98368]

Compiling on clang showed a couple of pessimizations. Fixed thusly. libcody/ * client.cc (Client::ProcessResponse): Remove std::move inside ?: c++tools/ * resolver.cc (module_resolver::cmi_response): Remove std::move of temporary. -- Nathan

RE: [RFC] middle-end: Extend CSE to understand vector extracts.

On Mon, 4 Jan 2021, Tamar Christina wrote: > Hi Richi, > > > -Original Message- > > From: Richard Biener > > Sent: Monday, January 4, 2021 1:33 PM > > To: Tamar Christina > > Cc: gcc-patches@gcc.gnu.org; nd ; i...@airs.com; > > l...@redhat.com > > Subject: Re: [RFC] middle-end: Extend

Re: [PATCH] vect, aarch64: Fix alignment units for IFN_MASK* [PR95401]

On Mon, Jan 4, 2021 at 12:50 PM Richard Sandiford via Gcc-patches wrote: > > The IFN_MASK* functions take two leading arguments: a load or > store pointer and a “cookie”. The type of the cookie is the > type of the access for TBAA purposes (like for MEM_REFs) > while the value of the cookie is

[libcody] Windows absdir fix

An obvious thinko in dirve name check :( libcody/ * resolver.cc (IsAbsDir): Fix string indexing. Signed-off-by: Nathan Sidwell pushed to trunk -- Nathan Sidwell diff --git i/Makefile.def w/Makefile.def index c45be5bff45..d87c2a4bc3c 100644 --- i/Makefile.def +++

RE: [RFC] middle-end: Extend CSE to understand vector extracts.

Hi Richi, > -Original Message- > From: Richard Biener > Sent: Monday, January 4, 2021 1:33 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; i...@airs.com; > l...@redhat.com > Subject: Re: [RFC] middle-end: Extend CSE to understand vector extracts. > > On Mon, 4 Jan 2021,

[PATCH] tree-optimization/98308 - set vector type for mask of masked load

This makes sure to set the vector type on an invariant mask argument for a masked load and SLP. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2021-01-04 Richard Biener PR tree-optimization/98308 * tree-vect-stmts.c (vectorizable_load): Set invariant mask

Re: [RFC] middle-end: Extend CSE to understand vector extracts.

On Mon, 4 Jan 2021, Tamar Christina wrote: > Hi All, > > I am trying to get CSE to re-use constants already inside a vector rather than > re-materializing the constant again. > > Basically consider the following case: > > #include > #include > > uint64_t > test (uint64_t a, uint64x2_t b,

Re: [PR97714] final: accept markers at line 0

On Wed, Dec 23, 2020 at 12:56 AM Alexandre Oliva via Gcc-patches wrote: > > > Back when I introduced debug markers, I seem to have been under the > impression that location line 0 would only ever occur for unknown and > builtin locations. > > Though line 0 never comes up in normal processing of

Re: make FOR_EACH_IMM_USE_STMT safe for early exits (was: Re: move sincos after pre)

On Tue, Dec 22, 2020 at 11:03 PM Alexandre Oliva wrote: > > On Oct 28, 2020, Richard Biener wrote: > > >> BTW, any reason why we are not (yet?) using something like: > >> > >> #define FOR_EACH_IMM_USE_STMT(STMT, ITER, SSAVAR) \ > >> for (auto_end_imm_use_stmt_traverse auto_end

Re: [PATCH] store VLA bounds in attribute access as strings (PR 97172)

On Sun, Dec 20, 2020 at 6:43 PM Martin Sebor wrote: > > On 12/19/20 12:48 AM, Richard Biener via Gcc-patches wrote: > > On December 19, 2020 1:55:02 AM GMT+01:00, Martin Sebor via Gcc-patches > > wrote: > >> To keep tree expressions stored by the front end in attribute > >> access for

RE: [RFC] AArch64: Have RTL patterns recognize DI extracts from vectors at offset 0 as no-op.

Hi Richard, > -Original Message- > From: Richard Sandiford > Sent: Monday, January 4, 2021 12:29 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw > ; Marcus Shawcroft > ; Kyrylo Tkachov > Subject: Re: [RFC] AArch64: Have RTL patterns recognize DI extracts

[PATCH] tree-optimization/98464 - replace loop info with avail at uses

This does VN replacement in loop nb_iterations consistent with the rest of the IL by using availability at the definition site of uses. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2021-01-04 Richard Biener PR tree-optimization/98464 * tree-ssa-sccvn.c

Re: [PATCH] Fix --enable-gather-detailed-mem-stats build.

On Wed, Dec 16, 2020 at 10:52 AM Martin Liška wrote: > > On 12/16/20 10:38 AM, Rainer Orth wrote: > > Hi Jakub, > > > >> On Wed, Dec 16, 2020 at 10:20:09AM +0100, Martin Liška wrote: > >>> So vec_mem_desc is not initialized before a static member in module.cc. > >>> We can fix it by using

Re: [RFC] AArch64: Have RTL patterns recognize DI extracts from vectors at offset 0 as no-op.

Tamar Christina writes: > Hi All, > > I have been looking into a class of problems where GCC is not recognizing that > a subreg of lane 0 (using little-endian as example) of a vector register and > passing that to an instruction. > > As an example consider > > poly64_t > testcase (uint8x16_t

[RFC] middle-end: Extend CSE to understand vector extracts.

Hi All, I am trying to get CSE to re-use constants already inside a vector rather than re-materializing the constant again. Basically consider the following case: #include #include uint64_t test (uint64_t a, uint64x2_t b, uint64x2_t* rt) { uint64_t arr[2] = { 0x0942430810234076UL,

[RFC] AArch64: Have RTL patterns recognize DI extracts from vectors at offset 0 as no-op.

Hi All, I have been looking into a class of problems where GCC is not recognizing that a subreg of lane 0 (using little-endian as example) of a vector register and passing that to an instruction. As an example consider poly64_t testcase (uint8x16_t input, poly64x2_t mask) { poly64_t prodL =

[committed] aarch64: Improve vcombine codegen [PR89057]

This patch fixes a codegen regression in the handling of things like: __temp.val[0] \ = vcombine_##funcsuffix (__b.val[0], \ vcreate_##funcsuffix (__AARCH64_UINT64_C

[PATCH] tree-optimization/98282 - classify V_C_E as nary

This avoids running into memory reference code in compute_avail by properly classifying unfolded reference trees on constants. Bootstrapped & tested on x86_64-unknown-linux-gnu, pushed. 2021-01-04 Richard Biener PR tree-optimization/98282 * tree-ssa-sccvn.c

[committed] aarch64: Use the MUL VL form of SVE PRF[BHWD]

The expansions of the svprf[bhwd] instructions weren't taking advantage of the immediate addressing mode. Tested on aarch64-linux-gnu and aarch64_be-elf. Pushed to trunk so far. Will backport to GCC 10 “soon”. Richard gcc/ * config/aarch64/aarch64.c (offset_6bit_signed_scaled_p): New

Re: docs: Fix wording describing the hwaddress sanitizer

On Mon, 4 Jan 2021, Martin Liška wrote: > I support the suggested patch. Thank you, Martin. Matthew, I would argue that for patches like this you do not need to seek approval (though you are aways welcome to seek review). And thanks for clarifying this wording. For the benefit of the doubt:

[PATCH] vect, aarch64: Fix alignment units for IFN_MASK* [PR95401]

The IFN_MASK* functions take two leading arguments: a load or store pointer and a “cookie”. The type of the cookie is the type of the access for TBAA purposes (like for MEM_REFs) while the value of the cookie is the alignment of the access. This PR was caused by a disagreement about whether the

Re: docs: Fix wording describing the hwaddress sanitizer

On 1/4/21 12:15 PM, Matthew Malcomson wrote: |This patch fixes that wording by being more explicit.| I support the suggested patch. Martin

Re: Patch RFA: Support non-ASCII file names in git-changelog

On 1/4/21 12:01 PM, Martin Liška wrote: Anyway, I'm going to update server hook first and I'll create an issue for  GitPython. So I was not correct about this. Also the server hooks uses now GitPython to identify modified files. I've just created an issue for that:

[PATCH] explow, aarch64: Fix force-Pmode-to-mem for ILP32 [PR97269]

This patch fixes a mode/rtx mismatch for ILP32 targets in: mem = force_const_mem (ptr_mode, imm); where imm can be Pmode rather than ptr_mode. The patch uses convert_memory_address to convert the Pmode address to ptr_mode before the call. However, immediate addresses can in general

Re: [PATCH] loop-niter: Recognize popcount idioms even with char, short and __int128 [PR95771]

On Sun, 3 Jan 2021, Jakub Jelinek wrote: > Hi! > > As the testcase shows, we punt unnecessarily on popcount loop idioms if > the type is smaller than int or larger than long long. > Smaller type than int can be handled by zero-extending the argument to > unsigned int, and types twice as long as

docs: Fix wording describing the hwaddress sanitizer

The original documentation added to mention the clash between -fsanitize=address and -fsanitize=hwaddress used confusing wording trying to say that -fsanitize=hwaddress is only available on AArch64. It read as if -fsanitize=address were only supported on AArch64. This patch fixes that wording by

[PATCH] tree-optimization/98393 - properly init matches when failing SLP

This zeroes matches when failing SLP discovery because of the work limit. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2021-01-04 Richard Biener PR tree-optimization/98393 * tree-vect-slp.c (vect_build_slp_tree): Properly zero matches when hitting the

Re: Patch RFA: Support non-ASCII file names in git-changelog

On 12/24/20 1:16 PM, Joel Brobecker wrote: I have no idea who that is (if it is a single user at all, if it isn't any user with git write permissions). CCing Joel, he should help us how to set a git config that will be used by the server hooks. I am not sure that requiring both the server

RE: [PR66791][ARM] Replace __builtin_vext* with __buitlin_shuffle in vext intrinsics

Hi Prathamesh > -Original Message- > From: Prathamesh Kulkarni > Sent: 04 January 2021 10:27 > To: gcc Patches ; Kyrylo Tkachov > > Subject: [PR66791][ARM] Replace __builtin_vext* with __buitlin_shuffle in > vext intrinsics > > Hi Kyrill, > The attached patch replaces

[PR66791][ARM] Replace __builtin_vext* with __buitlin_shuffle in vext intrinsics

Hi Kyrill, The attached patch replaces __builtin_vextv8qi with __builtin_shuffle for vext_s8. Just wanted to confirm if this is in the correct direction ? If yes, I will send a follow up patch that converts for all vext intrinsics. Thanks, Prathamesh vext-1.diff Description: Binary data

[PATCH] avr.exp: convert Dos newlines to Unix ones

Pushed. gcc/testsuite/ChangeLog: * gcc.target/avr/avr.exp: Run dos2unix on the file. --- gcc/testsuite/gcc.target/avr/avr.exp | 80 ++-- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/gcc/testsuite/gcc.target/avr/avr.exp

  1   2   >