libgo patch committed: Fix syscall tests that call Ioctl on AIX

This libgo patch by Clément Chigot fixes the syscall package tests that call Ioctl on AIX, by calling raw_ioctl_ptr rather than syscall. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian e884ced05231a04b1a3c70ece7237d0b1eeebf19 diff --git

Re: [PATCH] vect: Fix epilogue loop handling of partial vectors

Hi Richard, on 2020/9/22 下午10:34, Richard Sandiford wrote: > Richard Sandiford writes: >> I'll try to have a patch ready tomorrow morning European time. > > Well, I totally failed to hit that deadline. When testing on Power, > I saw a couple of extra failures, but I now think they're

libgo patch committed: Remove ptrace for ppc64 AIX

This libgo patch by Clément Chigot removes the ptrace syscall on ppc64 AIX. ptrace is available only for 32 bits programs. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian bbc644a3e0d9da37d0987918be5764d17a6069c4 diff --git a/gcc/go/gofrontend/MERGE

Re: [PATCH] c: Fix -Wduplicated-branches ICE [PR97125]

On 9/20/20 5:08 PM, Marek Polacek via Gcc-patches wrote: We crash here because since r11-3302 the C FE uses codes like SWITCH_STMT in the else branches in the attached test, and inchash::add_expr in do_warn_duplicated_branches doesn't handle these front-end codes. In the C++ FE this works

[committed] analyzer: use switch in exploded_node::on_stmt

This patch replaces a sequence of dyn_cast to different gimple stmt types in exploded_node::on_stmt with a switch on the gimple_code. This makes clearer which kinds of stmt are currently treated as no-ops, as a precursor to handling them properly. No functional change intended. Successfully

Re: [PATCH] Add $(ZLIBINC) to CFLAGS-analyzer/engine.o

On Tue, 2020-09-22 at 17:47 -0400, David Malcolm wrote: > On Tue, 2020-09-22 at 22:55 +0200, Tobias Burnus wrote: > > This patch breaks the cross build here: > > ...gcc/analyzer/engine.cc:65:10: fatal error: zlib.h: No such file > > or > > directory > > > > I think you need to do something

Re: PR97107, libgo fails to build for power10

On Wed, Sep 23, 2020 at 10:00:01AM +0930, Alan Modra wrote: > Hi Segher, > > On Tue, Sep 22, 2020 at 06:59:42PM -0500, Segher Boessenkool wrote: > > On Tue, Sep 22, 2020 at 09:55:12AM +0930, Alan Modra wrote: > > >if (!info->push_p) > > > -return; > > > +{ > > > + /* We need the

libgo patch committed: Fix build errors on AIX

This libgo patch by Clément Chigot fixes build errors on AIX. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian 63cd53d2f5da07856340bbea11ee09ab1125e8c0 diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE index a8ba5a35e44..d17d39702c8 100644 ---

Re: PR97107, libgo fails to build for power10

Hi Segher, On Tue, Sep 22, 2020 at 06:59:42PM -0500, Segher Boessenkool wrote: > On Tue, Sep 22, 2020 at 09:55:12AM +0930, Alan Modra wrote: > >if (!info->push_p) > > -return; > > +{ > > + /* We need the -fsplit-stack prologue for functions that make > > +tail calls. Tail

Re: libbacktrace patch committed: Avoid ambiguous binary search

On Tue, Sep 8, 2020 at 6:22 PM Ian Lance Taylor wrote: > > This patch to libbacktrace avoids ambiguous binary searches. > Searching for a range match can cause the search order to not match > the sort order, which can cause libbacktrace to miss matching entries. > This patch allocates an extra

Re: [RS6000] Power10 libffi fixes

Hi! On Tue, Sep 22, 2020 at 10:00:11AM +0930, Alan Modra wrote: > Power10 pc-relative code doesn't use or preserve r2 as a TOC pointer. > That means calling between pc-relative and TOC using code can't be > done without intervening linker stubs, and a call from TOC code to > pc-relative code must

Re: PR97107, libgo fails to build for power10

Hi! On Tue, Sep 22, 2020 at 09:55:12AM +0930, Alan Modra wrote: > Calls from split-stack code to non-split-stack code need to expand > mapped stack memory via __morestack. Even tail calls. > > __morestack is quite a surprising function on powerpc in that it calls > back to its caller, and a

Re: Go patch committed: Finalize methods for type aliases of struct types

On Mon, Sep 21, 2020 at 3:54 PM Ian Lance Taylor wrote: > > This patch to the Go frontend finalizes methods for type aliases of > struct types. Previously we would finalize the methods of the alias > type itself, but since its a type alias we really need to finalize the > methods of the aliased

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi! On Tue, Sep 22, 2020 at 06:06:30PM +0100, Richard Sandiford wrote: > Qing Zhao writes: > > Okay, thanks for the info. > > then, what’s the current definition of UNSPEC_VOLATILE? > > I'm not sure it's written down anywhere TBH. rtl.texi just says: > > @code{unspec_volatile} is used for

[PATCH] Add $(ZLIBINC) to CFLAGS-analyzer/engine.o

On Tue, 2020-09-22 at 22:55 +0200, Tobias Burnus wrote: > This patch breaks the cross build here: > ...gcc/analyzer/engine.cc:65:10: fatal error: zlib.h: No such file or > directory > > I think you need to do something similar in Makefile.in as lto- > compress has: > > # lto-compress.o needs

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 22, 2020, at 12:06 PM, Richard Sandiford > wrote: The following is what I see from i386.md: (I didn’t look at how “UNSPEC_volatile” is used in data flow analysis in GCC yet) ;; UNSPEC_VOLATILE is considered to use and clobber all hard registers and ;;

Re: New modref/ipa_modref optimization passes

On Tue, 2020-09-22 at 22:23 +0200, Jan Hubicka wrote: > > On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote: > > > David, > > > with jit I get the following: > > > /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed: > > > nonrepresentable section on output > > > collect2: error: ld

Re: [committed] analyzer: add -fdump-analyzer-json

This patch breaks the cross build here: ...gcc/analyzer/engine.cc:65:10: fatal error: zlib.h: No such file or directory I think you need to do something similar in Makefile.in as lto-compress has: # lto-compress.o needs $(ZLIBINC) added to the include flags. CFLAGS-lto-compress.o += $(ZLIBINC)

Issue with ggc_delete and finalizers (was Re: New modref/ipa_modref optimization passes)

On Tue, 2020-09-22 at 22:24 +0200, Jan Hubicka wrote: > > On Tue, 2020-09-22 at 16:13 -0400, David Malcolm wrote: > > > On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote: > > > > David, > > > > with jit I get the following: > > > > /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed: > > >

[COMMITTED] c++: Add test for PR96652

Fixed by r11-3361. gcc/testsuite/ChangeLog: PR c++/96652 * g++.dg/cpp0x/decltype-96652.C: New test. --- gcc/testsuite/g++.dg/cpp0x/decltype-96652.C | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype-96652.C diff --git

Re: New modref/ipa_modref optimization passes

> On Tue, 2020-09-22 at 16:13 -0400, David Malcolm wrote: > > On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote: > > > David, > > > with jit I get the following: > > > /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed: > > > nonrepresentable section on output > > > collect2: error: ld

Re: New modref/ipa_modref optimization passes

> On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote: > > David, > > with jit I get the following: > > /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed: > > nonrepresentable section on output > > collect2: error: ld returned 1 exit status > > make[3]: *** [../../gcc/jit/Make-lang.in:121:

Re: New modref/ipa_modref optimization passes

On Tue, 2020-09-22 at 16:13 -0400, David Malcolm wrote: > On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote: > > David, > > with jit I get the following: > > /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed: > > nonrepresentable section on output > > collect2: error: ld returned 1 exit

Re: New modref/ipa_modref optimization passes

Hello, this patch fixes the selftests and destructor issue noticed by David (Malcolm). According to David jit still crashes at different but I am hitting different build failure in libjit that I will need to analyze tomorrow. Bootstrapped/regtested x86_64-linux, comitted. *

Re: New modref/ipa_modref optimization passes

On Tue, 2020-09-22 at 20:39 +0200, Jan Hubicka wrote: > David, > with jit I get the following: > /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed: > nonrepresentable section on output > collect2: error: ld returned 1 exit status > make[3]: *** [../../gcc/jit/Make-lang.in:121:

Re: [PATCH v3] c, c++: Implement -Wsizeof-array-div [PR91741]

On 9/22/20 1:29 PM, Marek Polacek wrote: Ping. The C++ change is OK. On Tue, Sep 15, 2020 at 04:33:05PM -0400, Marek Polacek via Gcc-patches wrote: On Tue, Sep 15, 2020 at 09:04:41AM +0200, Jakub Jelinek via Gcc-patches wrote: On Mon, Sep 14, 2020 at 09:30:44PM -0400, Marek Polacek via

Re: [PATCH] c++: Return only in-scope tparms in keep_template_parm [PR95310]

On 9/22/20 2:41 PM, Patrick Palka wrote: On Tue, 22 Sep 2020, Patrick Palka wrote: On Mon, 21 Sep 2020, Jason Merrill wrote: On 9/19/20 3:49 PM, Patrick Palka wrote: In the testcase below, the dependent specializations iter_reference_t and iter_reference_t share the same tree due to

Re: [PING][PATCH] correct handling of indices into arrays with elements larger than 1 (PR c++/96511)

The rebased and retested patches are attached. On 9/21/20 3:17 PM, Martin Sebor wrote: Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553906.html (I'm working on rebasing the patch on top of the latest trunk which has changed some of the same code but it'd be helpful to get a

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 22, 2020, at 1:35 PM, H.J. Lu wrote: > > On Tue, Sep 22, 2020 at 11:25 AM Qing Zhao > wrote: >> >> Hi, Hongjiu, >> >> >>> On Sep 22, 2020, at 11:31 AM, Richard Sandiford >>> wrote: >>> >>> Qing Zhao writes: > On Sep 21, 2020, at 2:22 PM, Qing

c++: Remove a broken error-recovery path

The remaining use of xref_tag_from_type was also suspicious. It turns out to be an error path. At parse time we diagnose that a class definition cannot appear, but we swallow the definition. This code was attempting to push it into the global scope (or find a conflict). This seems needless,

[committed] libstdc++: Fix out-of-bounds string_view access in filesystem::path [PR 97167]

libstdc++-v3/ChangeLog: PR libstdc++/97167 * src/c++17/fs_path.cc (path::_Parser::root_path()): Check for empty string before inspecting the first character. * testsuite/27_io/filesystem/path/append/source.cc: Append empty string_view to path. Tested

[committed] analyzer: add -fdump-analyzer-json

I've found this useful for debugging state explosions in the analyzer. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to master as 809192e77e6e112a0fe32dee7fada7a49fbf25cd. gcc/analyzer/ChangeLog: * analysis-plan.cc: Include "json.h". * analyzer.opt

Re: New modref/ipa_modref optimization passes

> On Sun, 2020-09-20 at 19:30 +0200, Jan Hubicka wrote: > > > > > [...] > > > > Should new C++ source files have a .cc suffix, rather than .c? > > > > > > [...] > > > > > > > + $(srcdir)/ipa-modref.h $(srcdir)/ipa-modref.c \ > > > > > > ...which would affect this^ >

Re: [PATCH] c++: Return only in-scope tparms in keep_template_parm [PR95310]

On Tue, 22 Sep 2020, Patrick Palka wrote: > On Mon, 21 Sep 2020, Jason Merrill wrote: > > > On 9/19/20 3:49 PM, Patrick Palka wrote: > > > In the testcase below, the dependent specializations iter_reference_t > > > and iter_reference_t share the same tree due to specialization > > > caching. So

Re: New modref/ipa_modref optimization passes

David, with jit I get the following: /usr/local/x86_64-pc-linux-gnu/bin/ld: final link failed: nonrepresentable section on output collect2: error: ld returned 1 exit status make[3]: *** [../../gcc/jit/Make-lang.in:121: libgccjit.so.0.0.1] Error Is there a fix/workaround? Patch I am trying to

Re: [PATCH] bpf: use xBPF signed div, mod insns when available

The 'mod' and 'div' operators in eBPF are unsigned, with no signed counterpart. xBPF adds two new ALU operations, sdiv and smod, for signed division and modulus, respectively. Update bpf.md with 'define_insn' blocks for signed div and mod to use them when targetting

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

On Tue, Sep 22, 2020 at 11:25 AM Qing Zhao wrote: > > Hi, Hongjiu, > > > > On Sep 22, 2020, at 11:31 AM, Richard Sandiford > > wrote: > > > > Qing Zhao writes: > >>> On Sep 21, 2020, at 2:22 PM, Qing Zhao via Gcc-patches > >>> wrote: > >>> > >>> > >>> > On Sep 21, 2020, at 2:11 PM,

Re: [PATCH] c++: Return only in-scope tparms in keep_template_parm [PR95310]

On Mon, 21 Sep 2020, Jason Merrill wrote: > On 9/19/20 3:49 PM, Patrick Palka wrote: > > In the testcase below, the dependent specializations iter_reference_t > > and iter_reference_t share the same tree due to specialization > > caching. So when find_template_parameters walks through the > >

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Hongjiu, > On Sep 22, 2020, at 11:31 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>> On Sep 21, 2020, at 2:22 PM, Qing Zhao via Gcc-patches >>> wrote: >>> >>> >>> On Sep 21, 2020, at 2:11 PM, Richard Sandiford wrote: Qing Zhao writes: >> But in

Re: [PATCH] bpf: use xBPF signed div, mod insns when available

Hi Segher! > On Thu, Sep 17, 2020 at 10:15:30AM -0700, David Faust via Gcc-patches wrote: >> The 'mod' and 'div' operators in eBPF are unsigned, with no signed >> counterpart. xBPF adds two new ALU operations, sdiv and smod, for >> signed division and modulus, respectively. Update bpf.md with

PING [GCC 10] [PATCH] IRA: Don't make a global register eliminable

On Fri, Sep 18, 2020 at 10:21 AM H.J. Lu wrote: > > On Thu, Sep 17, 2020 at 3:52 PM Jeff Law wrote: > > > > > > On 9/16/20 8:46 AM, Richard Sandiford wrote: > > > > "H.J. Lu" writes: > > > > On Tue, Sep 15, 2020 at 7:44 AM Richard Sandiford > > wrote: > > > > Thanks for looking at this. > > >

Re: [PATCH v3] c, c++: Implement -Wsizeof-array-div [PR91741]

Ping. On Tue, Sep 15, 2020 at 04:33:05PM -0400, Marek Polacek via Gcc-patches wrote: > On Tue, Sep 15, 2020 at 09:04:41AM +0200, Jakub Jelinek via Gcc-patches wrote: > > On Mon, Sep 14, 2020 at 09:30:44PM -0400, Marek Polacek via Gcc-patches > > wrote: > > > --- a/gcc/c/c-tree.h > > > +++

Go patch committed: Use runtime.eqtype for type switches on AIX

This patch by Clément Chigot changes the Go frontend to call runtime.eqtype for non-interface type switches on AIX. All type switch clauses must call runtime.eqtype if the linker isn't able to merge type descriptors pointers. Previously, only interface-type clauses were doing it. This is for

Re: [PATCH] Fix overflow handling in std::align

On 21/09/20 15:50 +0100, Jonathan Wakely wrote: On 21/09/20 10:42 -0400, Glen Fernandes via Libstdc++ wrote: On Mon, Sep 14, 2020 at 5:44 PM Thomas Rodgers wrote: On Sep 14, 2020, at 7:30 AM, Ville Voutilainen wrote: On Mon, 14 Sep 2020 at 15:49, Glen Fernandes wrote: Sounds like a good

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Qing Zhao writes: >> On Sep 17, 2020, at 11:27 AM, Richard Sandiford >> wrote: >> >> Qing Zhao mailto:qing.z...@oracle.com>> writes: On Sep 17, 2020, at 1:17 AM, Richard Sandiford wrote: Qing Zhao writes: > Segher and Richard, > > Now there are two major

[PATCH][omp, ftracer] Don't duplicate blocks in SIMT region

[ was: Re: [Patch] [middle-end & nvptx] gcc/tracer.c: Don't split BB with SIMT LANE [PR95654] ] On 9/16/20 8:20 PM, Alexander Monakov wrote: > > > On Wed, 16 Sep 2020, Tom de Vries wrote: > >> [ cc-ing author omp support for nvptx. ] > > The issue looks familiar. I recognized it back in 2017

Re: [Patch] [middle-end & nvptx] gcc/tracer.c: Don't split BB with SIMT LANE [PR95654]

On 9/16/20 12:39 PM, Tobias Burnus wrote: > Hi Tom, hi Richard, hello all, > > @Richard: does it look okay from the ME side? > @Tom: Can you check which IFN_GOMP_SIMT should be > excluded with -ftracer? > > Pre-remark, I do not know much about SIMT – except that they > only appear with nvptx and

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Qing Zhao writes: >> On Sep 21, 2020, at 2:22 PM, Qing Zhao via Gcc-patches >> wrote: >> >> >> >>> On Sep 21, 2020, at 2:11 PM, Richard Sandiford >>> wrote: >>> >>> Qing Zhao writes: > But in cases where there is no underlying concept that can sensibly > be extracted out, it's OK

Re: [PATCH] arm: Add new vector mode macros

Kyrylo Tkachov writes: > Hi Richard, > >> -Original Message- >> From: Richard Sandiford >> Sent: 16 September 2020 11:15 >> To: gcc-patches@gcc.gnu.org >> Cc: ni...@redhat.com; Richard Earnshaw ; >> Ramana Radhakrishnan ; Kyrylo >> Tkachov ; Dennis Zhang >> >> Subject: Re: [PATCH] arm:

Re: [PATCH] aarch64: Add extend-as-extract-with-shift pattern [PR96998]

Segher Boessenkool writes: > Hi Alex, > > On Tue, Sep 22, 2020 at 08:40:07AM +0100, Alex Coplan wrote: >> On 21/09/2020 18:35, Segher Boessenkool wrote: >> Thanks for doing this testing. The results look good, then: no code size >> changes and no build regressions. > > No *code* changes. I

c++: fix injected friend of template class

In working on fixing hiddenness, I discovered some suspicious code in template instantiation. I suspect it dates from when we didn't do the hidden friend injection thing at all. The xreftag finds the same class, but makes it visible to name lookup. Which is wrong. hurrah, fixing a bug by

Re: [RFC] update COUNTs of BB in loop.

Hi! (Just some random things; the change itself looks fine afaics.) On Tue, Sep 22, 2020 at 01:37:47PM +0800, guojiufu wrote: > While after pcom: > >COUNT:268435456 pre-header > | > | .. >

Re: [Patch] OpenMP: Handle cpp_implicit_alias in declare-target discovery (PR96390)

On 9/22/20 4:24 PM, Jakub Jelinek wrote: On Tue, Sep 22, 2020 at 04:11:19PM +0200, Tobias Burnus wrote: + while (node->alias_target) +{ + node = node->ultimate_alias_target (); At least in theory, ultimate_alias_target can look through multiple aliases. Granted. But we

Re: [PATCH] aarch64: Add extend-as-extract-with-shift pattern [PR96998]

Hi Alex, On Tue, Sep 22, 2020 at 08:40:07AM +0100, Alex Coplan wrote: > On 21/09/2020 18:35, Segher Boessenkool wrote: > Thanks for doing this testing. The results look good, then: no code size > changes and no build regressions. No *code* changes. I cannot test aarch64 likme this. > > So,

[PATCH] aarch64: Add HF routines to libgcc_s.so

The libgcc HF support routines were being linked into libgcc_s.so, but weren't being exported. Tested on aarch64-linux-gnu and aarch64_be-elf. Any thoughts? I'll apply Monday next week if there are no objections by then. I guess there's the question whether we should backport this to release

[committed] libstdc++: Introduce new headers for C++20 ranges components

This introduces two new headers: defines the minimal components needed for using C++20 ranges (customization point objects such as std::ranges::begin, concepts such as std::ranges::range, etc.) includes and additionally defines subrange, which is needed by . Most of the content of was

[PATCH] vect: Fix epilogue loop handling of partial vectors

Richard Sandiford writes: > I'll try to have a patch ready tomorrow morning European time. Well, I totally failed to hit that deadline. When testing on Power, I saw a couple of extra failures, but I now think they're improvements rather than regressions. See the point about single-iteration

Re: [Patch] OpenMP: Handle cpp_implicit_alias in declare-target discovery (PR96390)

On Tue, Sep 22, 2020 at 04:11:19PM +0200, Tobias Burnus wrote: > + while (node->alias_target) > + { > + node = node->ultimate_alias_target (); At least in theory, ultimate_alias_target can look through multiple aliases. While it might not do that most of the time because

[committed, OG10] dwarf: Multi-register CFI address support

On 03/09/2020 16:29, Andrew Stubbs wrote: OK to commit? (Although, I'll hold off until AMD release the compatible GDB.) The ROCm 3.8 ROCGDB is now released. I'm committing the attached patches to devel/omp/gcc-10 while I wait for review. The first patch is the multi-register CFI support,

Re: [Patch] OpenMP: Handle cpp_implicit_alias in declare-target discovery (PR96390)

On 9/22/20 9:36 AM, Jakub Jelinek wrote: On Tue, Sep 22, 2020 at 09:11:48AM +0200, Tobias Burnus wrote: Okay – or do we find more issues? I'm afraid so. We will slowly converge, hopefully ;-) Consider: int v; #pragma omp declare target to (v) void foo (void) { v++; } void bar (void)

Re: [PATCH] c++: Ignore __sanitizer_ptr_{sub,cmp} builtin calls during constant expression evaluation [PR97145]

On 9/22/20 3:48 AM, Jakub Jelinek wrote: Hi! These two builtin calls are added already during parsing before pointer subtractions or comparisons, normally they perform runtime verification of whether the pointers point to the same object or different objects, but during constant expressione

Re: [PATCH 2/3] Use MiB unit when displaying memory allocation.

On Tue, Sep 22, 2020 at 09:02:08AM -0400, Marek Polacek via Gcc-patches wrote: > On Tue, Sep 22, 2020 at 10:30:00AM +0200, Martin Liška wrote: > > On 9/22/20 9:47 AM, Christophe Lyon wrote: > > > On Wed, 2 Sep 2020 at 15:29, Martin Liška wrote: > > > > > > > > On 9/1/20 4:04 PM, Jan Hubicka

Re: [PATCH 2/3] Use MiB unit when displaying memory allocation.

On Tue, Sep 22, 2020 at 10:30:00AM +0200, Martin Liška wrote: > On 9/22/20 9:47 AM, Christophe Lyon wrote: > > On Wed, 2 Sep 2020 at 15:29, Martin Liška wrote: > > > > > > On 9/1/20 4:04 PM, Jan Hubicka wrote: > > > > > The patch is about usage of MiB in memory allocation reports. > > > > > I

Re: [r11-3315 Regression] FAIL: g++.dg/ext/timevar2.C -std=gnu++98 (test for excess errors) on Linux/x86_64 (-m64 -march=cascadelake)

On Tue, Sep 22, 2020 at 09:07:36AM +0200, Martin Liška wrote: > On 9/21/20 9:43 PM, Marek Polacek wrote: > > Ok for trunk? Tested by running timevar2.C a couple of dozen times. > > Thank you for the fix. It seems to me obvious, I would install it. Ok, I've pushed the patch. Marek

Re: [PATCH] S/390: Do not turn maybe-uninitialized warnings into errors

On 15.09.20 17:02, Stefan Schulze Frielinghaus wrote: > Over the last couple of months quite a few warnings about uninitialized > variables were raised while building GCC. A reason why these warnings > show up on S/390 only is due to the aggressive inlining settings here. > Some of these warnings

Re: [PATCH] switch lowering: limit number of cluster attemps

On 9/22/20 2:19 PM, Richard Biener wrote: OK. Though the default limit looks high? Yep, I'm going to install it with the param default value equal to 1. Thanks, Martin

Re: New modref/ipa_modref optimization passes

> > Thanks; with that it survives the first in-process iteration, but then > dies inside the 3rd in-process iteration, on a different finalizer. > I'm beginning to suspect a pre-existing bad interaction between > finalizers and jit which perhaps this patch has exposed. > > I'll continue to

Re: [PATCH] switch lowering: limit number of cluster attemps

On September 22, 2020 1:22:12 PM GMT+02:00, "Martin Liška" wrote: >Hi. > >The patch is about a bail out limit that needs to be added to switch >lowering. >Currently the algorithm is quadratic and needs some bail out. I've >tested value >of 100K which corresponds to about 0.2s in the problematic

Re: [PATCH] IBM Z: Try to make use of load-and-test instructions

On Mon, Sep 21, 2020 at 06:51:00PM +0200, Andreas Krebbel wrote: > On 18.09.20 13:10, Stefan Schulze Frielinghaus wrote: > > This patch enables a peephole2 optimization which transforms a load of > > constant zero into a temporary register which is then finally used to > > compare against a

[committed][libgomp, nvptx] Print error log for link error

Hi, By running libgomp test-case libgomp.c/target-28.c with GOMP_NVPTX_PTXRW=w (using a maintenance patch that adds support for this env var), we dump the ptx in target-28.exe to file. By editing one ptx file to rename gomp_nvptx_main to gomp_nvptx_main2 in both declaration and call, and running

Re: [PATCH] VEC_COND_EXPR: fix ICE in gimple_expand_vec_cond_expr

@Richi: May I please ping this? On 9/1/20 4:27 PM, Martin Liška wrote: On 8/31/20 10:01 AM, Richard Biener wrote: On Fri, Aug 28, 2020 at 4:18 PM Martin Liška wrote: Hey. The patch is about VEC_COND_EXP comparison of a SSA_NAME with a constant that is artifact of -fno-tree-ccp. Patch can

[PATCH][GCC 8] AArch64: Implement new intrinsics vabsd_s64 and vnegd_s64.

Hi all, I'd like to backport this patch from Vlad implementing the missing vabsd_s64 and vnegd_s64 intrinsics to the GCC 8 branch. They should have been implemented from the start and they don't require any surgery/new builtins. Bootstrapped and tested on aarch64-none-linux-gnu. Committing to

[PATCH] switch lowering: limit number of cluster attemps

Hi. The patch is about a bail out limit that needs to be added to switch lowering. Currently the algorithm is quadratic and needs some bail out. I've tested value of 100K which corresponds to about 0.2s in the problematic test-case before it's reached. Patch can bootstrap on x86_64-linux-gnu

Re: New modref/ipa_modref optimization passes

On Tue, 2020-09-22 at 09:07 +0200, Jan Hubicka wrote: > > > (gdb) p summaries > > > $3 = (fast_function_summary *) 0x0 > > > > > > I'm still investigating (but may have to call halt for the > > > night), but > > > this could be an underlying issue with the new passes; the jit > > > testsuite runs

[PATCH] aix: retrieve AR for configure for FAT library construction

Description: "ar" was changed to use AR value coming from configure, as several "ar" might be available. But all the -X flags must first be removed if the -r option is used. Otherwize, it might replace the wrong object files. libgcc/Changelog: 2020-09-22 Clement Chigot  *

[PATCH] AArch64: Implement missing vcls intrinsics on unsigned types

Hi all, This patch implements some missing intrinsics that perform a CLS on unsigned SIMD types. Bootstrapped and tested on aarch64-none-linux-gnu. Committing to trunk and to active branches after testing. Thanks, Kyrill 2020-09-22 Kyrylo Tkachov PR target/71233 *

[PATCH] AArch64: Implement poly-type vadd intrinsics

Hi all, This implements the vadd[p]_p* intrinsics. In terms of functionality they are aliases of veor operations on the relevant unsigned types. Bootstrapped and tested on aarch64-none-linux-gnu. Committing to trunk. Will backport it to the active branches after some time too. Thanks, Kyrill

[PATCH] AArch64: Implement missing vceq*_p* intrinsics

Hi all, This patch implements some missing vceq* intrinsics on poly types. The behaviour is to produce the appropriate CMEQ instruction as for the unsigned types. Bootstrapped and tested on aarch64-none-linux-gnu. Committing to trunk and backporting to the branches after testing. Thanks,

Re: New modref/ipa_modref optimization passes

On 9/21/20 10:10 AM, Richard Biener wrote: I see, so you would expect call to alsize to initialize things in array15_unkonwn type? That would work too. Yes, that's my expectation. But let's see what fortran folks say. RFC patch attached; I think the following should work, but I am not sure

Re: [PATCH] libstdc++: Pretty printers for std::_Bit_reference, std::_Bit_iterator and std::_Bit_const_iterator

On 14/09/20 16:49 +0200, Michael Weghorn via Libstdc++ wrote: Hi, the attached patch implements pretty printers relevant for iteration over std::vector, thus handling the TODO added in commit 36d0dada6773d7fd7c5ace64c90e723930a3b81e ("Have std::vector printer's iterator return bool for vector",

Re: [PATH 3/3] libstdc++: Add std::advance ostreambuf_iterator overload

On 14/09/20 22:36 +0200, François Dumont via Libstdc++ wrote: On 10/09/20 5:19 pm, Jonathan Wakely wrote: On 09/09/20 22:12 +0200, François Dumont via Libstdc++ wrote: libstdc++: Add std::advance overload for ostreambuf_iterator Implement std::advance overload for ostreambuf_iterator

[PATCH] aarch64: Do not alter force_reg returned rtx expanding pauth builtins

Hi all, having a look for force_reg returned rtx later on modified I've found this other case in `aarch64_general_expand_builtin` while expanding pointer authentication builtins. Regtested and bootsraped on aarch64-linux-gnu. Okay for trunk? Andrea >From

Re: [PATCH] libstdc++: use a link test to test for -Wl,-z,relro

On 22/09/20 09:40 +, JonY via Libstdc++ wrote: On 9/22/20 8:50 AM, Jonathan Wakely wrote: I don't see a patch, or any previous email to the libstdc++ list. Please resend with the patch, CCing libstdc++@ Thanks. Resent for the record. Thanks. I've been told it might not be

Re: [PATCH] libstdc++: use a link test to test for -Wl,-z,relro

On 9/22/20 8:50 AM, Jonathan Wakely wrote: > > I don't see a patch, or any previous email to the libstdc++ list. > > Please resend with the patch, CCing libstdc++@ > > Thanks. > > > Resent for the record. I've been told it might not be appropriate because some targets cannot link yet and

Re: [committed] ipa: Fix up ipa modref option help texts

> On Tue, Sep 22, 2020 at 10:13:46AM +0200, Jakub Jelinek via Gcc-patches wrote: > > --- gcc/params.opt.jj 2020-09-21 11:15:53.816516949 +0200 > > +++ gcc/params.opt 2020-09-22 09:59:37.121115589 +0200 > > @@ -882,7 +882,7 @@ Maximum number of refs stored in each mo > > > >

Re: [PATCH] libstdc++: use a link test to test for -Wl,-z,relro

On 16/09/20 12:11 +, JonY via Libstdc++ wrote: On 9/13/20 3:37 PM, JonY wrote: On 9/10/20 2:23 PM, JonY wrote: Do a link test instead of just a grep. The linker can support multiple targets, but not all targets can use it. Cygwin/MinGW ld can support ELF but the PE format for Windows

Re: [committed] ipa: Fix up ipa modref option help texts

On Tue, Sep 22, 2020 at 10:13:46AM +0200, Jakub Jelinek via Gcc-patches wrote: > --- gcc/params.opt.jj 2020-09-21 11:15:53.816516949 +0200 > +++ gcc/params.opt2020-09-22 09:59:37.121115589 +0200 > @@ -882,7 +882,7 @@ Maximum number of refs stored in each mo > > -param=modref-max-tests= >

Re: [PATCH 2/3] Use MiB unit when displaying memory allocation.

On 9/22/20 9:47 AM, Christophe Lyon wrote: On Wed, 2 Sep 2020 at 15:29, Martin Liška wrote: On 9/1/20 4:04 PM, Jan Hubicka wrote: The patch is about usage of MiB in memory allocation reports. I see it much better readable than values displayed in KiB: Reading object files: tramp3d-v4.o {GC

Re: Do we need to do a loop invariant motion after loop interchange ?

On Tue, Sep 22, 2020 at 10:30 AM HAO CHEN GUI wrote: > > Bin, > > I just tested your patch on current trunk. Here is my summary. > > 1. About some iv aren't moved out of inner loop (Lijia mentioned in his > last email) > >[local count: 955630226]: ># l_32 = PHI <1(12), l_54(21)> >#

[committed] ipa: Fix up ipa modref option help texts

Hi! This fixes FAIL: compiler driver --help=common option(s): "^ +-.*[^:.]$" absent from output: " --param=modref-max-tests= Maximum number of tests perofmed

Re: [RFC] update COUNTs of BB in loop.

On 9/22/20 7:37 AM, guojiufu wrote: Thanks for comments!! Thanks for the patch. I can confirm it is NO-OP for SPEC2006 benchmarks. Martin

[PATCH] c++: Ignore __sanitizer_ptr_{sub,cmp} builtin calls during constant expression evaluation [PR97145]

Hi! These two builtin calls are added already during parsing before pointer subtractions or comparisons, normally they perform runtime verification of whether the pointers point to the same object or different objects, but during constant expressione valuation we don't really need those builtins

Re: [PATCH 2/3] Use MiB unit when displaying memory allocation.

On Wed, 2 Sep 2020 at 15:29, Martin Liška wrote: > > On 9/1/20 4:04 PM, Jan Hubicka wrote: > >> The patch is about usage of MiB in memory allocation reports. > >> I see it much better readable than values displayed in KiB: > >> > >> Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19

Re: [committed] libstdc++: Use correct argument type for __use_alloc [PR 96803]

On 26/08/20 19:34 +0100, Jonathan Wakely wrote: The _Tuple_impl constructor for allocator-extended construction from a different tuple type uses the _Tuple_impl's own _Head type in the __use_alloc test. That is incorrect, because the argument tuple could have a different type. Using the wrong

Re: [PATCH] aarch64: Add extend-as-extract-with-shift pattern [PR96998]

Hi Segher, On 21/09/2020 18:35, Segher Boessenkool wrote: > Hi! > > So, I tested this patch. The test builds Linux for all targets, and the > number reported here is just binary size (usually a good indicator for > combine effectiveness). C0 is the unmodified compiler, C1 is with your > patch.

Re: [Patch] OpenMP: Handle cpp_implicit_alias in declare-target discovery (PR96390)

On Tue, Sep 22, 2020 at 09:11:48AM +0200, Tobias Burnus wrote: > > Okay – or do we find more issues? I'm afraid so. > + if (omp_declare_target_fn_p (decl) > + || lookup_attribute ("omp declare target host", > +DECL_ATTRIBUTES (decl))) > +

[PATCH] gcov: fix streaming corruption

As mentioned in the PR, line number equal to 0 is a bogus. Moreover, it messes up GCNO file format where we use 0 as a separator. I'm thus suggesting to start lines with at least 1. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I'll install the patch if there are no

Re: [PATCH] gcov: fix TOPN streaming from shared libraries

On 9/22/20 1:13 AM, Sergei Trofimovich wrote: On Mon, 21 Sep 2020 20:38:07 +0300 (MSK) Alexander Monakov wrote: On Mon, 21 Sep 2020, Martin Liška wrote: On 9/6/20 1:24 PM, Sergei Trofimovich wrote: From: Sergei Trofimovich Before the change gcc did not stream correctly TOPN counters if

Re: Do we need to do a loop invariant motion after loop interchange ?

On Tue, Sep 22, 2020 at 4:31 AM HAO CHEN GUI via Gcc-patches wrote: > > Bin, > > I just tested your patch on current trunk. Here is my summary. > > 1. About some iv aren't moved out of inner loop (Lijia mentioned in his > last email) > >[local count: 955630226]: ># l_32 = PHI <1(12),

Re: [Patch] OpenMP: Handle cpp_implicit_alias in declare-target discovery (PR96390)

Hi Honza & Jakub, @Honza: please look at the decl alias handling of the actual patch. a minor update – testing only on gcn did turn out to be insufficient: nvptx does not support alias, cf. PR 97102 + 97106; hence xfailed. I also had a typo in one 'dg-do run' but as -O0 is set explicitly,

  1   2   >