Re: [PATCH v3] c++: Further tweaks for new-expression and paren-init [PR77841]

On Tue, Sep 08, 2020 at 04:19:42PM -0400, Jason Merrill wrote: > On 9/8/20 4:06 PM, Marek Polacek wrote: > > On Mon, Sep 07, 2020 at 11:19:47PM -0400, Jason Merrill wrote: > > > On 9/6/20 11:34 AM, Marek Polacek wrote: > > > > @@ -3944,9 +3935,9 @@ build_new (location_t loc, vec > > > >

Re: [PATCH] Implement __builtin_thread_pointer for x86 TLS

On Tue, Sep 8, 2020 at 4:52 PM Jakub Jelinek wrote: > > On Tue, Sep 08, 2020 at 04:14:52PM +0800, Hongtao Liu wrote: > > Hi: > > We have "*load_tp_" in i386.md for load of thread pointer in > > i386.md, so this patch merely adds the expander for > > __builtin_thread_pointer. > > > > Bootstrap

libbacktrace patch committed: Don't strip underscore on 64-bit PE

This patch to libbacktrace avoids stripping a leading underscore from symbol names on 64-bit PE COFF. Bootstrapped and ran Go tests on x86_64-pc-linux-gnu. Committed to mainline. Ian * pecoff.c (coff_initialize_syminfo): Add is_64 parameter. (coff_add): Determine and pass is_64. diff --git

libbacktrace patch committed: Get executable name on macOS

This patch to libbacktrace gets the executable name on macOS using _NSGetExecutablePath. This is another aspect of PR 96973. Tested basic functionality on macOS. Bootstrapped and ran libbacktrace tests on x86_64-pc-linux-gnu. Committed to mainline. Ian * fileline.c

Re: [PATCH v2] rs6000: Expand vec_insert in expander instead of gimple [PR79251]

On 2020/9/8 16:26, Richard Biener wrote: >> Seems not only pseudo, for example "v = vec_insert (i, v, n);" >> the vector variable will be store to stack first, then [r112:DI] is a >> memory here to be processed. So the patch loads it from stack(insn #10) to >> temp vector register first, and

libbacktrace patch committed: Avoid ambiguous binary search

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 entry at the end of function_addrs and unit_addrs vectors, so that

[PATCH] Cygwin/MinGW: Do not version lto plugins

Hello, The lto plugis are tied to the built GCC anyway, so there isn't much point to versioning them. * gcc/config.host: Remove version string * lto-plugin/Makefile.am: Use libtool -avoid-version * lto-plugin/Makefile.in: Regenerate This patch has been in use with Cygwin gcc for a long time and

libbacktrace patch committed: Correct tipo in comment

This patch suggested by Ondřej Čertík fixes a typpo in a comment. Bootstrapped and ran libbacktrace tests on x86_64-pc-linux-gnu. Committed to mainline. Ian * simple.c (simple_unwind): Correct comment spelling. diff --git a/libbacktrace/simple.c b/libbacktrace/simple.c index

Re: [PATCH] arm: Fix up arm_override_options_after_change [PR96939]

On Tue, 2020-09-08 at 10:45 +0200, Jakub Jelinek via Gcc-patches wrote: > Hi! > > As mentioned in the PR, the testcase fails to link, because when set_cfun is > being called on the crc function, arm_override_options_after_change is > called from set_cfun -> invoke_set_current_function_hook: >

libbacktrace patch committed: Correct Mach-O memory allocation

This libbacktrace patch corrects the amount of memory allocated when looking for the Mach-O dsym file. We weren't allocating space for the backslash. Thanks to Alex Crichton for noticing this. This also fixes the amount of space released when freeing diralc in the same function. Thanks to

Re: [PATCH] libphobos: libdruntime doesn't support shadow stack (PR95680)

Hi Iain, >>> --- >>> libphobos/ChangeLog: >>> >>> PR d/95680 >>> * Makefile.in: Regenerate. >>> * configure: Regenerate. >>> * configure.ac (DCFG_ENABLE_CET): Substitute. >>> * libdruntime/Makefile.in: Regenerate. >>> *

libbacktrace patch committed: Correctly swap Mach-O fat 32-bit file offset

This libbacktrace patch correctly swaps the 32-bit file offset in a Mach-O fat file. This is based on a patch by Francois-Xavier Coudert , who analyzed the problem. This is for PR 96973. Bootstrapped and ran libbacktrace tests on x86_64-pc-linux-gnu. Committed to mainline. Ian PR

Re: [PATCH] c++: Fix resolving the address of overloaded pmf [PR96647]

On 9/8/20 9:17 AM, Patrick Palka wrote: On Mon, 31 Aug 2020, Jason Merrill wrote: On 8/28/20 12:45 PM, Patrick Palka wrote: (Removing libstd...@gcc.gnu.org from CC list) On Fri, 28 Aug 2020, Patrick Palka wrote: In resolve_address_of_overloaded_function, currently only the second pass over

Re: [PATCH v2] c++: Further tweaks for new-expression and paren-init [PR77841]

On 9/8/20 4:06 PM, Marek Polacek wrote: On Mon, Sep 07, 2020 at 11:19:47PM -0400, Jason Merrill wrote: On 9/6/20 11:34 AM, Marek Polacek wrote: @@ -3944,9 +3935,9 @@ build_new (location_t loc, vec **placement, tree type, } /* P1009: Array size deduction in new-expressions. */ -

[PATCH] openacc: Fix atomic_capture-2.c iteration-ordering issues

The test case was written with assumptions about loop iteration ordering that are not guaranteed by OpenACC and do not apply on all targets, in particular AMD GCN. This patch removes those assumptions. Tested with offloading to AMD GCN. I will apply shortly. Julian 2020-09-08 Julian Brown

[PATCH] openacc: Fix mkoffload SGPR/VGPR count parsing for HSACO v3

If an offload kernel uses a large number of VGPRs, AMD GCN hardware may need to limit the number of threads/workers launched for that kernel. The number of SGPRs/VGPRs in use is detected by mkoffload and recorded in the processed output. The patterns emitted detailing SGPR/VGPR occupancy changed

[PATCH] amdgcn: Add waitcnt after LDS write instructions

Data-share write (ds_write) instructions do not necessarily complete the write to LDS immediately. When a write completes, LGKM_CNT is decremented. For now, we wait until LGKM_CNT reaches zero after each ds_write instruction. This fixes a race condition in the case where LDS is read immediately

[PATCH] openacc: Fix race condition in Fortran loop collapse tests

The gangs participating in a gang-partitioned loop are not all guaranteed to complete before some given gang continues to execute beyond that loop. This means that two existing test cases contain a race condition, because a loop that may be gang-partitioned is followed immediately by another loop.

Re: [PATCH v2] c++: Further tweaks for new-expression and paren-init [PR77841]

On Mon, Sep 07, 2020 at 11:19:47PM -0400, Jason Merrill wrote: > On 9/6/20 11:34 AM, Marek Polacek wrote: > > @@ -3944,9 +3935,9 @@ build_new (location_t loc, vec > > **placement, tree type, > > } > > /* P1009: Array size deduction in new-expressions. */ > > - if (TREE_CODE (type) ==

libbacktrace patch committed: Only match magic number at start of file

This patch fixes the libbacktrace file type detection, which is run at configure time, to only look for a magic number at the very start of the file. Otherwise we can get confused if the bytes happen to appear elsewhere on the first "line". This is for PR 96971. Bootstrapped and ran

Re: Patch for 96948

Hi, On Tue, 8 Sep 2020, Kirill Müller wrote: I haven't actually tested if the cfa value (ms_context.Rsp) is valid, I also see no reason why it shouldn't be. What does it take for your patch to be accepted? What's the minimum gcc version where it will be available? I'm not a maintainer nor a

[PATCH] Practical Improvement to libgcc Complex Divide

(Version 4) (Added in version 4) Fixed Changelog entry to include __divsc3, __divdc3, __divxc3, __divtc3. Revised description to avoid incorrect use of "ulp (units last place)". Modified float precison case to use double precision when double precision hardware is available. Otherwise float uses

[PATCH] Add support for atomic_flag::wait/notify_one/notify_all

* include/bits/atomic_base.h (__atomic_flag::wait): Define. (__atomic_flag::notify_one): Likewise. (__atomic_flag::notify_all): Likewise. * testsuite/29_atomics/atomic_flag/wait_notify/1.cc: New test. --- libstdc++-v3/include/bits/atomic_base.h | 23 +++

Re: [PATCH] bb-reorder: Remove a misfiring micro-optimization (PR96475)

Hi! Sorry this took so long to come back to... On Tue, Aug 25, 2020 at 02:39:56PM -0600, Jeff Law wrote: > On Fri, 2020-08-07 at 21:51 +, Segher Boessenkool wrote: > > When the compgotos pass copies the tail of blocks ending in an indirect > > jump, there is a micro-optimization to not copy

RE: [PING] floatformat.h: Add bfloat16 support.

On Tue, 8 Sep 2020, Willgerodt, Felix via Gcc-patches wrote: > Thanks for your review. It seems like the format issue was introduced by > my email client when hitting reply. Sorry for that! The original patch > is formatted correctly, as I used git send-email: >

Re: [PATCH] Add support for putting jump table into relocation read-only section

Hi! On Mon, Aug 24, 2020 at 03:53:44PM +0800, HAO CHEN GUI wrote: >   abs_jump_table = (!CASE_VECTOR_PC_RELATIVE >                                     && > !targetm.asm_out.generate_pic_addr_diff_vec ()) ? 1 : 0; x = y ? 1 : 0; is the same as x = y; if y is already only 0 or 1, and

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

> On Sep 7, 2020, at 10:58 AM, H.J. Lu wrote: > > On Mon, Sep 7, 2020 at 7:06 AM Segher Boessenkool > mailto:seg...@kernel.crashing.org>> wrote: >> >> On Fri, Sep 04, 2020 at 11:52:13AM -0700, H.J. Lu wrote: >>> On Fri, Sep 4, 2020 at 11:09 AM Segher Boessenkool >>> wrote: On Fri, Sep

Re: [committed] analyzer: fix another ICE in constructor-handling [PR96949]

Hi David, I'm taking the liberty of adding the reproducer for this to gfortran.dg/analyzer as a regression test; hope that's OK. Sure. Adding a passing test case like that certainly falls under the "obvious and simple" rule. Best regards Thomas

Re: [RFC Patch] mklog.py: Parse first 10 lines for PR/DR number

On 9/8/20 5:50 PM, Martin Sebor wrote: On 9/8/20 3:47 AM, Tobias Burnus wrote: currently, mklog searches for "PR" (and "DR") only in the first line of a new 'testsuite' file. I think in many cases, the PR is listed a bit later than the first line – although, it is usually in the first few

Re: Patch for 96948

Hi Thanks for the explanation, this makes sense now. I haven't actually tested if the cfa value (ms_context.Rsp) is valid, I also see no reason why it shouldn't be. What does it take for your patch to be accepted? What's the minimum gcc version where it will be available? Best regards

Re: [RFC Patch] mklog.py: Parse first 10 lines for PR/DR number

On 9/8/20 3:47 AM, Tobias Burnus wrote: Hi Martin, hi all, currently, mklog searches for "PR" (and "DR") only in the first line of a new 'testsuite' file. I think in many cases, the PR is listed a bit later than the first line – although, it is usually in the first few lines; in my example, it

RE: [PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

Hi Christophe, > -Original Message- > From: Christophe Lyon > Sent: 08 September 2020 09:15 > To: Alex Coplan > Cc: gcc Patches ; Richard Earnshaw > ; Marcus Shawcroft > Subject: Re: [PATCH] aarch64: Don't generate invalid zero/sign-extend > syntax > > > gcc/ChangeLog: > > > >

Re: Patch for 96948

Hi, On Tue, 8 Sep 2020, Kirill Müller wrote: Thanks for the heads up. The coincidence is funny -- a file that hasn't been touched for years. I think we both may originally be triggered from the same guy asking around in different places about implementations of _Unwind_Backtrace for

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

My understanding is this feature/flag is not intended to be "default on". It is intended to be used in security sensitive environments such as the Linux kernel where it was requested by kernel security experts. I'm not understanding the objection here if the feature is requested by security teams

Re: [PATCH][libatomic] Add nvptx support

On 9/8/20 8:51 AM, Tom de Vries wrote: Add nvptx support to libatomic. I tried it on powerpc64le-none-linux-gnu and that solves the __sync_val_compare_and_swap_16 issue, I reported at https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553070.html However, when trying Jakub's example

[committed] analyzer: fix another ICE in constructor-handling [PR96949]

PR analyzer/96949 reports an ICE within -fanalyzer on a Fortran test case with --param analyzer-max-svalue-depth=0, where that param value leads to INTEGER_CST values in a RANGE_EXPR being treated as unknown symbolic values. This patch replaces implicit assumptions that these values are concrete

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

> On Sep 7, 2020, at 8:06 AM, Rodriguez Bahena, Victor > wrote: > > > > From: Qing Zhao mailto:qing.z...@oracle.com>> > Date: Friday, September 4, 2020 at 9:19 AM > To: "Rodriguez Bahena, Victor" >, Kees Cook > >

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

> On Sep 7, 2020, at 9:36 AM, Segher Boessenkool > wrote: > > On Fri, Sep 04, 2020 at 02:00:41PM -0500, Qing Zhao wrote: However, if we only clear USED registers, the worst case is 1.72% on average. This overhead is very reasonable. >>> >>> No, that is the number I meant. 2%

[committed] analyzer: fix ICE on RANGE_EXPR with CONSTRUCTOR value [PR96950]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to master as r11-3051-gaf656c401e97f9de2a8478f18278e8efb2a6cf23. gcc/analyzer/ChangeLog: PR analyzer/96950 * store.cc (binding_map::apply_ctor_to_region): Handle RANGE_EXPR where min_index == max_index.

[committed] analyzer: fix ICE on machine-specific builtins [PR96962]

In g:ee7bfbe5eb70a23bbf3a2cedfdcbd2ea1a20c3f2 I added a switch (DECL_UNCHECKED_FUNCTION_CODE (callee_fndecl)) to region_model::on_call_pre guarded by fndecl_built_in_p (callee_fndecl). I meant to handle only normal built-ins, whereas this single-argument overload of fndecl_built_in_p returns

Re: [RFC] enable flags-unchanging asms, add_overflow/expand/combine woes

On Thu, 3 Sep 2020, Alexandre Oliva wrote: > On Sep 3, 2020, Segher Boessenkool wrote: > > For instructions that inherently set a condition code register, the > > @code{compare} operator is always written as the first RTL expression of > > the @code{parallel} instruction pattern. > >

Re: [PATCH] tree-optimization/96043 - BB vectorization costing improvement

On Tue, 8 Sep 2020, Richard Biener wrote: > > This makes the BB vectorizer cost independent SLP subgraphs > separately. While on pristine trunk and for x86_64 I failed to > distill a testcase where the vectorizer would think _any_ > basic-block vectorization opportunity is not profitable I do >

RE: [PATCH] ipa-inline: Improve growth accumulation for recursive calls

Hi, On Fri, Aug 21 2020, Tamar Christina wrote: >> >> Honza's changes have been motivated to big extent as an enabler for IPA-CP >> heuristics changes to actually speed up 548.exchange2_r. >> >> On my AMD Zen2 machine, the run-time of exchange2 was 358 seconds two >> weeks ago, this week it is

[PATCH] arm: Add new vector mode macros

[ This is related to Dennis's subtraction patch https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553339.html and the discussion about how the patterns were written. I wanted to see whether there was a way that we could simplify the current addition handling that might perhaps make

Re: Patch for 96948

Hi Thanks for the heads up. The coincidence is funny -- a file that hasn't been touched for years. I do believe that we need the logic around the `first` flag for consistency with the other unwind-*.c implementations. This can be verified by running the tests in the included libbacktrace

Re: [PATCH] c++: Fix resolving the address of overloaded pmf [PR96647]

On Mon, 31 Aug 2020, Jason Merrill wrote: > On 8/28/20 12:45 PM, Patrick Palka wrote: > > (Removing libstd...@gcc.gnu.org from CC list) > > > > On Fri, 28 Aug 2020, Patrick Palka wrote: > > > In resolve_address_of_overloaded_function, currently only the second > > > pass over the overload set

[PATCH] tree-optimization/96043 - BB vectorization costing improvement

This makes the BB vectorizer cost independent SLP subgraphs separately. While on pristine trunk and for x86_64 I failed to distill a testcase where the vectorizer would think _any_ basic-block vectorization opportunity is not profitable I do have pending work that would make the cost savings of

[PATCH v2] --enable-link-serialization support

On Mon, Sep 07, 2020 at 05:58:04PM -0400, Jason Merrill via Gcc-patches wrote: > On Thu, Sep 3, 2020 at 10:49 AM Jakub Jelinek via Gcc-patches > wrote: > > > > On Thu, Sep 03, 2020 at 03:53:35PM +0200, Richard Biener wrote: > > > On Thu, 3 Sep 2020, Jakub Jelinek wrote: > > > But is that an issue

Re: [PATCH] code generate live lanes in basic-block vectorization

On Tue, 8 Sep 2020 at 14:15, Richard Biener wrote: > > On Tue, 8 Sep 2020, Christophe Lyon wrote: > > > Hi Richard, > > > > On Fri, 4 Sep 2020 at 15:42, Richard Biener wrote: > > > > > > The following adds the capability to code-generate live lanes in > > > basic-block vectorization using lane

[PATCH v2] libgcc: Expose the instruction pointer and stack pointer in SEH _Unwind_Backtrace

Previously, the SEH version of _Unwind_Backtrace did unwind the stack and call the provided callback function as intended, but there was little the caller could do within the callback to actually get any info about that particular level in the unwind. Set the ra and cfa pointers, which are used

Re: [PATCH] code generate live lanes in basic-block vectorization

On Tue, 8 Sep 2020, Christophe Lyon wrote: > Hi Richard, > > On Fri, 4 Sep 2020 at 15:42, Richard Biener wrote: > > > > The following adds the capability to code-generate live lanes in > > basic-block vectorization using lane extracts from vector stmts > > rather than keeping the original

Re: Patch for 96948

Hi, On Mon, 7 Sep 2020, Kirill Müller via Gcc-patches wrote: As requested, attaching a patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948. This solves a problem with _Unwind_Backtrace() on mingw64 + SEH. What a coincidence - I actually sent a patch for the exact same thing last

Re: [PATCH] code generate live lanes in basic-block vectorization

Hi Richard, On Fri, 4 Sep 2020 at 15:42, Richard Biener wrote: > > The following adds the capability to code-generate live lanes in > basic-block vectorization using lane extracts from vector stmts > rather than keeping the original scalar code around for those. > This eventually makes

Re: [PATCH] gcc: Make strchr return value pointers const

On Tue, 8 Sep 2020, Jakub Jelinek wrote: On Tue, Sep 08, 2020 at 12:16:08PM +0100, Richard Sandiford wrote: Are platform maintainers allowed to push general changes like these? If so I can push soon. Yeah, anyone with commit access can push an approved patch. I've pushed this one yesterday

Re: [PATCH] gcc: Make strchr return value pointers const

On Tue, Sep 08, 2020 at 12:16:08PM +0100, Richard Sandiford wrote: > > Are platform maintainers allowed to push general changes like these? If > > so I can push soon. > > Yeah, anyone with commit access can push an approved patch. I've pushed this one yesterday already:

[PUSHED] PR tree-optimization/96967 - cast label range to type of switch operand

This is the same issue as PR96818. It's another intersect that's missing a cast in the same function. I missed it in the previous PR. Pushed as obvious. PR tree-optimization/96967 * tree-vrp.c (find_case_label_range): Cast label range to type of switch operand. ---

Re: [PATCH] gcc: Make strchr return value pointers const

JonY via Gcc-patches writes: > On 9/4/20 12:47 PM, Martin Storsjö wrote: >> Hi, >> >> On Fri, 4 Sep 2020, Jakub Jelinek wrote: >> >>> On Tue, Sep 01, 2020 at 04:01:42PM +0300, Martin Storsjö wrote: This fixes compilation of codepaths for dos-like filesystems with Clang. When built

[committed] MSP430: Fix detection of assembler support for .mspabi_attribute

The assembly code ".mspabi_attribute 4,1" uses the object attribute mechanism to indicate that the 430 ISA is in use. However, the default ISA is 430X, so GAS fails to assemble this since the ISA wasn't also set to 430 on the command line. Successfully regtested msp430.exp. This fixes the object

[Patch] Fortran: Fixes for OpenMP loop-iter privatization (PRs 95109 + 94690)

This patch fixes all known issues related to loop-iter privatization. This patch removes the code added to gfc_resolve_do_iterator in commit r11-349-gf884bef2105d748fd7869cd641cbb4f6b6bb. I added it to fix some issues in testsuite/libgomp.fortran/pr66199-*.f90 but it turned out that

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

On Mon, Sep 7, 2020 at 5:42 PM HAO CHEN GUI wrote: > > Hi, > > I want to follow Lijia's work as I gained the performance benefit on > some SPEC workloads by adding a im pass after loop interchange. Could > you send me the latest patches? I could do further testing. Thanks a lot. Hi, Hmm, not

RE: [PATCH v2] doc: add 'cd' command before 'make check-gcc' command in install.texi

Hi, H-P > > > On Sat, 29 Aug 2020, Hu Jiangping wrote: > > > > > > > This patch add 'cd' command before 'make check-gcc' command > > > > when run the testsuite on selected tests. > > > > > > No, don't do that; those targets work fine from the toplevel > > > too, and then include the language

Re: [PATCH] libphobos: libdruntime doesn't support shadow stack (PR95680)

Excerpts from H.J. Lu's message of September 8, 2020 4:09 am: > On Mon, Sep 7, 2020 at 2:35 PM Iain Buclaw wrote: >> >> Hi, >> >> This patch removes whatever CET support was in the switchContext routine >> for x86 D runtime, and instead uses the ucontext fallback, which propely >> handles shadow

[RFC Patch] mklog.py: Parse first 10 lines for PR/DR number

Hi Martin, hi all, currently, mklog searches for "PR" (and "DR") only in the first line of a new 'testsuite' file. I think in many cases, the PR is listed a bit later than the first line – although, it is usually in the first few lines; in my example, it is in line 3 and 4. Admittedly, I do

[PATCH] Makefile.tpl: Add check-g++

This patch add a new check-g++ target to the Makefile under toplevel, as synonym of the check-c++ target. It is to be consistent with the check-g++ target under the gcc subdirectory. And because check-gcc can be performed under toplevel, it is very possible that check-g++ may be performed

[COMMITTED] config: Sync largefile.m4 from binutils-gdb

The following patch improves handling of largefile support with procfs on 32-bit Solaris. It has already been approved and installed for binutils-gdb in the thread starting at [PATCH] Unify Solaris procfs and largefile handling

[committed] MSP430: Use enums to handle -mcpu= values

The -mcpu= option accepts only a handful of string values. Using enums instead of strings to handle the accepted values removes the need to have specific processing of the strings in the backend, and simplifies any comparisons that need to be performed on the value. It also allows the default

Re: [PATCH] Implement __builtin_thread_pointer for x86 TLS

On Tue, Sep 08, 2020 at 04:14:52PM +0800, Hongtao Liu wrote: > Hi: > We have "*load_tp_" in i386.md for load of thread pointer in > i386.md, so this patch merely adds the expander for > __builtin_thread_pointer. > > Bootstrap is ok, regression test is ok for i386/x86-64 backend. > Ok for

[PATCH] arm: Fix up arm_override_options_after_change [PR96939]

Hi! As mentioned in the PR, the testcase fails to link, because when set_cfun is being called on the crc function, arm_override_options_after_change is called from set_cfun -> invoke_set_current_function_hook: /* Change optimization options if needed. */ if (optimization_current_node

Re: [PATCH v2] rs6000: Expand vec_insert in expander instead of gimple [PR79251]

On Tue, Sep 8, 2020 at 10:11 AM luoxhu wrote: > > Hi Richi, > > On 2020/9/7 19:57, Richard Biener wrote: > > + if (TREE_CODE (to) == ARRAY_REF) > > + { > > + tree op0 = TREE_OPERAND (to, 0); > > + if (TREE_CODE (op0) == VIEW_CONVERT_EXPR > > + &&

Re: [PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

On Mon, 17 Aug 2020 at 11:00, Alex Coplan wrote: > > Hello, > > Given the following C function: > > double *f(double *p, unsigned x) > { > return p + x; > } > > prior to this patch, GCC at -O2 would generate: > > f: > add x0, x0, x1, uxtw 3 > ret > > but this add

[PATCH] Implement __builtin_thread_pointer for x86 TLS

Hi: We have "*load_tp_" in i386.md for load of thread pointer in i386.md, so this patch merely adds the expander for __builtin_thread_pointer. Bootstrap is ok, regression test is ok for i386/x86-64 backend. Ok for trunk? gcc/ChangeLog: PR target/96955 * config/i386/i386.md

Re: [PATCH v2] rs6000: Expand vec_insert in expander instead of gimple [PR79251]

Hi Richi, On 2020/9/7 19:57, Richard Biener wrote: > + if (TREE_CODE (to) == ARRAY_REF) > + { > + tree op0 = TREE_OPERAND (to, 0); > + if (TREE_CODE (op0) == VIEW_CONVERT_EXPR > + && expand_view_convert_to_vec_set (to, from, to_rtx)) > + { > +

[PATCH] rs6000: Use direct move for char/short vector CTOR [PR96933]

Hi, This patch is to make vector CTOR with char/short leverage direct move instructions when they are available. With one constructed test case, it can speed up 145% for char and 190% for short on P9. Tested SPEC2017 x264_r at -Ofast on P9, it gets 1.61% speedup (but based on unexpected SLP see

RE: [PING] floatformat.h: Add bfloat16 support.

Thanks for your review. It seems like the format issue was introduced by my email client when hitting reply. Sorry for that! The original patch is formatted correctly, as I used git send-email: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552079.html Could you double-check and push the

[PATCH][libatomic] Add nvptx support

Hi, Add nvptx support to libatomic. Given that atomic_test_and_set is not implemented for nvptx (PR96964), the compiler translates __atomic_test_and_set falling back onto the "Failing all else, assume a single threaded environment and simply perform the operation" case in

Re: Bug in FINDLOC documentation at https://gcc.gnu.org/onlinedocs/gfortran/FINDLOC.html

Hello Kay, The above website reads: "9.108 FINDLOC — Search an array for a value Description: Determines the location of the element in the array with the value given in the VALUE argument, or, if the DIM argument is supplied, determines the locations of the maximum element along each row of