Re: [PATCH] ix86: Improve __builtin_c[lt]z followed by extension [PR95535]

On Fri, Jun 5, 2020 at 8:45 AM Jakub Jelinek wrote: > > Hi! > > In January I've added patterns to optimize SImode -> DImode sign or zero > extension of __builtin_popcount, this patch does the same for > __builtin_c[lt]z. Like most other instructions, the [tl]zcntl instructions > clear the upper 3

[PATCH] ix86: Improve __builtin_c[lt]z followed by extension [PR95535]

Hi! In January I've added patterns to optimize SImode -> DImode sign or zero extension of __builtin_popcount, this patch does the same for __builtin_c[lt]z. Like most other instructions, the [tl]zcntl instructions clear the upper 32 bits of the destination register and as the instructions only re

Re: [PATCH] Do not copy NULL string with memcpy.

On June 4, 2020 10:22:55 PM GMT+02:00, Alexandre Oliva wrote: >On Jun 3, 2020, Martin Liška wrote: > >> On 6/3/20 5:58 AM, Alexandre Oliva wrote: >>> Please let me know if you'd prefer me to take this PR over. > >> Yes, please take a look. > >Here's what I've regstrapped on x86_64-linux-gnu. I

[PATCH] Optimize multiplication for V8QI,V16QI,V32QI under TARGET_AVX512BW [target/95488]

Hi: +/* Optimize vector MUL generation for V8QI, V16QI and V32QI + under TARGET_AVX512BW. i.e. for v16qi a * b, it has + + vpmovzxbw ymm2, xmm0 + vpmovzxbw ymm3, xmm1 + vpmullw ymm4, ymm2, ymm3 + vpmovwb xmm0, ymm4 + + it would take less instructions than ix86_expand_vecop_qihi. +

[PATCH] PowerPC: Add future hwcap2 bits

This patch adds support for the two new HWCAP2 fields used by the __builtin_cpu_supports function. It adds support in the target_clones attribute for -mcpu=future. The two new __builtin_cpu_supports tests are: __builtin_cpu_supports ("isa_3_1") __builtin_cpu_supports ("mma") The

Re: [PATCH V2] Practical Improvement to Double Precision Complex Divide

On Fri, 5 Jun 2020, Patrick McGehearty wrote: > diff --git a/libgcc/libgcc2.c b/libgcc/libgcc2.c > index e0a9fd7..2a1d3dc 100644 > --- a/libgcc/libgcc2.c > +++ b/libgcc/libgcc2.c > @@ -2036,26 +2036,77 @@ CONCAT3(__mul,MODE,3) (MTYPE a, MTYPE b, MTYPE c, > MTYPE d) > CTYPE > CONCAT3(__div,MODE,

[PATCH V2] Practical Improvement to Double Precision Complex Divide

The following patch to libgcc/libgcc2.c __divdc3 provides an opportunity to gain important improvements to the quality of answers for the default double precision complex divide routine when dealing with very large or very small exponents. The current code correctly implements Smith's method (1962

[committed] libstdc++: Remove workarounds for constrained nested class templates

With PR c++/92078 and PR c++/92103 both fixed, nested class templates can now be constrained. That means a number of namespace-scope helpers can be moved to the class scope, so they're only visible where they're needed. * include/bits/iterator_concepts.h (__detail::__ptr, __detail::__ref)

Re: [PATCH] diagnostics: Consistently add fixit hint for implicit builtin declaration

Hi, On Fri, 2020-05-29 at 09:13 -0600, Martin Sebor wrote: > On 5/28/20 7:13 PM, Mark Wielaard wrote: > > On Thu, May 28, 2020 at 06:21:39PM -0600, Martin Sebor wrote: > > > Although few tests bother with it, since you add an option for > > > the existing warning where there was none before, an ev

[committed] d: Merge upstream dmd 48d704f08

Hi, This patch merges the D front-end implementation with upstream dmd 47ed0330f. Updates the Array interface in dmd/root/array to use a DArray internally. Splits out BitArray into a separate header. Bootstrapped and regression tested on x86_64-linux-gnu, and committed to mainline. Regards Iai

Re: [PATCH] Do not copy NULL string with memcpy.

On Jun 3, 2020, Martin Liška wrote: > On 6/3/20 5:58 AM, Alexandre Oliva wrote: >> Please let me know if you'd prefer me to take this PR over. > Yes, please take a look. Here's what I've regstrapped on x86_64-linux-gnu. It makes both memcpy calls conditional, and reorders the length computati

[committed] d: Merge upstream dmd 47ed0330f

Hi, This parch merges the D front-end implementation with upstream dmd 47ed0330f. Updating the copyright years of the front-end sources. Committed to mainline. Regards Iain gcc/d/ChangeLog: * dmd/MERGE: Merge upstream dmd 47ed0330f. --- gcc/d/dmd/MERGE | 2 +- gcc/d/dmd

[pushed] c++: Fix complex constexpr virtual cases [PR93310].

The code in constexpr for looking up the actual type of the object and then getting the virtual function from there broke for both of these tests: for 16, it assumed incorrectly that the DECL_VINDEX would apply to the most derived type's vtable; for 17, it failed to consider that during constructio

[PATCH, committed] PR fortran/95500 - Segfault compiling extra interface on intrinsic

Committed as obvious. Regtests cleanly on x86_64-pc-linux-gnu. Thanks to Steve Kargl for the patch. This is an ICE-on-valid due to a NULL pointer dereference; it looks safe and could be backported to 9/10. Thanks, Harald PR fortran/95500 - Segfault compiling extra interface on intrinsic Conv

[pushed] c++: Fix FE devirt with diamond inheritance [PR95158]

This started breaking in GCC 8 because of the fix for PR15272; after that change, we (correctly) remember the lookup from template parsing time that found Base::foo through the non-dependent MiddleB base, and so we overlook the overrider in MiddleA. But given that, the devirtualization condition f

Re: [PATCH 07/13] OpenACC 2.6 deep copy: libgomp parts

Hi! On 2019-12-17T22:03:47-0800, Julian Brown wrote: > This part contains the libgomp runtime support for the GOMP_MAP_ATTACH and > GOMP_MAP_DETACH mapping kinds (etc.) > --- a/libgomp/oacc-mem.c > +++ b/libgomp/oacc-mem.c > @@ -1075,6 +1119,39 @@ goacc_exit_data_internal (struct gomp_device_de

[PATCH, PR fortran/95503] [9/10/11 Regression] ICE in gfc_is_simply_contiguous, at fortran/expr.c:5844

The following patch fixes an almost obvious ICE in invalid. Regtested on x86_64-pc-linux-gnu. OK for master, and backports to 9/10? Thanks, Harald PR fortran/95503 - ICE in gfc_is_simply_contiguous, at fortran/expr.c:5844 The check for assigning a pointer that cannot be determined to be simpl

Fix 'sizeof' usage in 'libgomp.oacc-c-c++-common/deep-copy-{7, 8}.c' (was: [PATCH 11/13] OpenACC 2.6 deep copy: C and C++ execution tests)

Hi! On 2019-12-17T22:04:54-0800, Julian Brown wrote: > This part adds C and C++ execution tests to libgomp. Spotted the following while looking into/for something else: > --- /dev/null > +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/deep-copy-7.c > @@ -0,0 +1,45 @@ > +struct dc > +{ > + i

[OpenACC] Repair/restore 'is_tgt_unmapped' checking (was: [PATCH 07/13] OpenACC 2.6 deep copy: libgomp parts)

Hi! On 2020-05-20T20:11:00+0100, Julian Brown wrote: > On Wed, 20 May 2020 16:52:02 +0200 > Thomas Schwinge wrote: >> On 2019-12-17T22:03:47-0800, Julian Brown >> wrote: >> > --- a/libgomp/oacc-mem.c >> > +++ b/libgomp/oacc-mem.c >> >> > static int >> > -find_group_last (int pos, size_t mapnum

[OpenACC] Don't open-code 'gomp_remove_var' in 'acc_unmap_data' (was: [PATCH 2/7] [OpenACC] Adjust dynamic reference count semantics)

Hi Julian! On 2020-05-22T15:16:05-0700, Julian Brown wrote: > --- a/libgomp/oacc-mem.c > +++ b/libgomp/oacc-mem.c > @@ -475,14 +475,19 @@ acc_unmap_data (void *h) >gomp_mutex_unlock (&acc_dev->lock); >gomp_fatal ("cannot unmap target block"); > } > - else if (tgt->refcount

[OpenACC] Remove 'tgt' reference counting from 'acc_unmap_data' [PR92854]

Hi! Per the discussion/conclusion in PR92854, I've now pushed "[OpenACC] Remove 'tgt' reference counting from 'acc_unmap_data' [PR92854]" to master branch in commit 4662f7fe7863b19fcc20ba58c22880f8d6661f3a, and releases/gcc-10 branch in commit 0c59837c89bd62e2addf4b34704a1ebe7e3bffab, see attached

Extend 'libgomp.oacc-c-c++-common/pr92854-1.c' some more [PR92854] (was: [PR92854] Add 'libgomp.oacc-c-c++-common/pr92854-1.c')

Hi! On 2019-12-09T12:52:02+0100, I wrote: > See attached "[PR92854] Add 'libgomp.oacc-c-c++-common/pr92854-1.c'", > committed to trunk in r279120, "to document the status quo", which does > match my understanding of the OpenACC 2.6 semantics. I've now pushed "Extend 'libgomp.oacc-c-c++-common/pr9

[OpenACC] Use 'tgt' returned from 'gomp_map_vars' (was: [PATCH 02/13] OpenACC reference count overhaul)

Hi! On 2020-05-19T17:42:22+0200, I wrote: > On 2019-12-17T22:02:27-0800, Julian Brown wrote: >> --- a/libgomp/oacc-mem.c >> +++ b/libgomp/oacc-mem.c > >> @@ -571,14 +570,16 @@ present_create_copy (unsigned f, void *h, size_t s, >> int async) >> >>goacc_aq aq = get_goacc_asyncqueue (async

[OpenACC] XFAIL behavior of over-eager 'finalize' clause (was: [PATCH 00/13] OpenACC 2.6 manual deep copy support)

Hi! On 2019-12-17T22:02:25-0800, Julian Brown wrote: > This patch series provides support for OpenACC 2.6's manual deep copy > (attach/detach) feature. As I should find, there is a problem with the OpenACC 'finalize' clause: unmapping stuff it isn't supposed to (to be fixed later on), which can

Re: [PATCH 1/7] [OpenACC] Missing unlocking on error paths in attach/detach code

Hi! On 2020-05-22T15:16:04-0700, Julian Brown wrote: > This patch adds some missing unlocking from error paths in the OpenACC > attach/detach code, noticed during development of other patches in > this series. Thanks, pushed "[OpenACC] Missing unlocking on error paths in attach/detach code" to m

Re: [PATCH V2 1/2] Introduce flag_cunroll_grow_size for cunroll

On Thu, Jun 04, 2020 at 08:46:23AM +0200, Richard Biener wrote: > On Thu, Jun 4, 2020 at 5:34 AM Jiufu Guo wrote: > > Patch is updated a little according to comments. > > Please see if this is ok to commit. > > OK with a proper ChangeLog after bootstrap / testing. > > It's also OK to backport th

'libgomp.oacc-fortran/{error_, }stop-{1, 2, 3}.f': initialize before the checkpoint

Hi! On 2018-04-19T11:06:18+0200, I wrote: > [...] I have applied the following in trunk > r259491 [...] > libgomp/ > PR libgomp/85463 > * testsuite/libgomp.oacc-fortran/error_stop-1.f: New file. > * testsuite/libgomp.oacc-fortran/error_stop-2.f: Lik

[COMMITED] testcase for PR95464

I've added the testcase for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464 diff --git a/gcc/testsuite/gcc.target/i386/pr95464.c b/gcc/testsuite/gcc.target/i386/pr95464.c new file mode 100644 index 000..33a8290e0cf --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/pr95464.c @@ -0,0 +

Re: [PATCH 1/2] [aarch64] Rework fpcr fpsr getter/setter builtins

Andrea Corallo writes: > Hi all, > > I'd like to submit this patch introducing the following 64bit builtins > variants as FPCR and FPSR registers getter/setter: > > unsigned long long __builtin_aarch64_get_fpcr64 () > void __builtin_aarch64_set_fpcr64 (unsigned long long) > unsigned long long __bu

Re: [COMMITTED] patch for PR95464

On 2020-06-04 12:55 p.m., H.J. Lu wrote: On Thu, Jun 4, 2020 at 9:17 AM Jakub Jelinek via Gcc-patches wrote: The testcase from the PR was a dg-do run testcase that FAILed without your patch, can't we just use that testcase (in gcc.target/i386/, restricted to lp64 and possibly linux only to m

[PATCH 6/7, V2] PowerPC tests: Add PC-relative tests.

[PATCH 6/7, V2] PowerPC tests: Add PC-relative tests. These tests make sure that PC-relative variant is generated for -mcpu=future on systems that support PC-relative addressing. The only difference is I reworded the comments, based on a suggestion by Will Schmidt. 2020-06-03 Michael Meissner

[PATCH 5/7, V2] PowerPC tests: Prefixed insn with large offsets

[PATCH 5/7, V2] PowerPC tests: Prefixed insn with large offsets Add tests to make sure for -mcpu=future that prefixed load/store instructions are generated if the offset is larger than 16 bits. The only difference is I reworded the comments, based on a suggestion by Will Schmidt. 2020-06-04 Mic

Re: [PATCH] warn on uninitialized accesses by function calls (PR 10138)

On Fri, 2020-05-15 at 17:31 -0600, Martin Sebor via Gcc-patches wrote: > Besides better buffer overflow checking, the new GCC 10 attribute > access also provides an opportunity to detect other kinds of bugs, > including uninitialized accesses by user-defined functions. > The attached patch implemen

[PATCH][GCC] arm: Fix the MVE ACLE vaddq_m polymorphic variants.

Hello, This patch fixes the MVE ACLE vaddq_m polymorphic variants by modifying the corresponding intrinsic parameters and vaddq_m polymorphic variant's _Generic case entries in "arm_mve.h" header file. Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more details. [1] https

Re: [COMMITTED] patch for PR95464

On Thu, Jun 4, 2020 at 9:17 AM Jakub Jelinek via Gcc-patches wrote: > > On Thu, Jun 04, 2020 at 12:13:51PM -0400, Vladimir Makarov via Gcc-patches > wrote: > > The following patch fixes > > > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464 > > > > The patch was successfully bootst

Re: [PATCH] middle-end/95493 - bogus MEM_ATTRS for variable array access

On June 4, 2020 6:20:36 PM GMT+02:00, Eric Botcazou wrote: >> I'll go with this variant since it is more obvious unless I hear >> otherwise. > >Yes, at least this one doesn't appear to further confuse an already >confusing >implementation. ;-) > >> Thanks, >> Richard. >> >> >> The following pa

Re: [COMMITTED] patch for PR95464

On 2020-06-04 12:17 p.m., Jakub Jelinek wrote: On Thu, Jun 04, 2020 at 12:13:51PM -0400, Vladimir Makarov via Gcc-patches wrote: The following patch fixes    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464 The patch was successfully bootstrapped and tested on x86-64.  I did not

[committed] d: Split up d-frontend.cc into multiple parts.

In preparation for possibly switching the front-end implementation from C++ to D, a lot of changes in the "glue" layer are just noise from lots of small, but invasive API changes in the DMD front-end headers. This will be the first of about a dozen or so. This change splits up the few implementat

Re: [PATCH] middle-end/95493 - bogus MEM_ATTRS for variable array access

> I'll go with this variant since it is more obvious unless I hear > otherwise. Yes, at least this one doesn't appear to further confuse an already confusing implementation. ;-) > Thanks, > Richard. > > > The following patch avoids keeping the inherited MEM_ATTRS when > set_mem_attributes_minu

Re: [COMMITTED] patch for PR95464

On Thu, Jun 04, 2020 at 12:13:51PM -0400, Vladimir Makarov via Gcc-patches wrote: > The following patch fixes > >            https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464 > > The patch was successfully bootstrapped and tested on x86-64.  I did not > test it on other major targets

[COMMITTED] patch for PR95464

The following patch fixes    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95464 The patch was successfully bootstrapped and tested on x86-64.  I did not test it on other major targets as they do not deal with STRICT_LOW_PART. There is also no test case for this PR as it is hard to che

aarch64: PR target/95526: Fix gimplification of varargs

This patch fixes a latent bug exposed by eb72dc663e9070b281be83a80f6f838a3a878822 in the aarch64 backend that was causing wrong codegen and several testsuite failures. See the discussion on the bug for details. Bootstrapped and regtested on aarch64-linux-gnu. Cleaned up several failing tests and n

[PATCH] avr: Add atmega324pb MCU

Reference: https://www.microchip.com/wwwproducts/en/ATMEGA324PB --- gcc/config/avr/avr-mcus.def | 1 + gcc/doc/avr-mmcu.texi | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/config/avr/avr-mcus.def b/gcc/config/avr/avr-mcus.def index 24046c367a7..ac80f9e63ff 100644 -

RE: [EXT] Re: [PATCH] Optimize and+or+sub into xor+not (PR94882)

Hi, Thanks for reviewing the patch and sharing your comments. >> nop_convert4 cannot happen, constants will have been constant folded here. Removed. >> So I think it should be and the other patterns adjusted accordingly. Modified the remaining patterns accordingly. Please find attached the modi

RE: arm: Fix vfp_operand_register for VFP HI regs

Hi Christophe, > -Original Message- > From: Christophe Lyon > Sent: 03 June 2020 14:30 > To: Kyrylo Tkachov > Cc: gcc-patches@gcc.gnu.org > Subject: Re: arm: Fix vfp_operand_register for VFP HI regs > > Hi, > > > On Thu, 14 May 2020 at 17:08, Christophe Lyon > wrote: > > > > On Fri,

RE: [GCC][PATCH][ARM]: Correct the grouping of operands in MVE vector scatter store intrinsics (PR94735).

Hi Srinath, > -Original Message- > From: Srinath Parvathaneni > Sent: 02 June 2020 15:00 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [GCC][PATCH][ARM]: Correct the grouping of operands in MVE > vector scatter store intrinsics (PR94735). > > Hello, > > The operands in

[PATCH] Add new/delete to struct occurence

I'm testing the following patch from Jonathan (I asked for an example how to retrofit an alloc-pool user to new/delete style operation). It also introduces NSDMI for member init. Bootstrap / regtest ongoing on x86_64-unknown-linux-gnu with a GCC 4.8.5 host compiler (just to make sure...) I'll

RE: [PATCH][GCC] arm: Fix the MVE ACLE vbicq intrinsics.

Hi Srinath, > -Original Message- > From: Srinath Parvathaneni > Sent: 28 May 2020 12:08 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH][GCC] arm: Fix the MVE ACLE vbicq intrinsics. > > Hello, > > Following MVE intrinsic testcases are failing in GCC testsuite. > >

Re: [PATCH] Fix component mappings with derived types for OpenACC

On Tue, 19 May 2020 14:23:34 +0200 Thomas Schwinge wrote: > Hi! > > On 2020-01-28T13:41:00+, Julian Brown > wrote: > > On Fri, 24 Jan 2020 10:58:49 +0100 > > Tobias Burnus wrote: > >> the gfortran part is rather obvious and it and the test case look > >> fine to me → OK. > >> The oacc-me

Re: std::optional defaut constructor

On 04/06/20 00:50 +0200, Marc Glisse wrote: (I don't currently have a setup that would enable me to commit anything. I'll try to fix it eventually, but likely not so soon) Ah, I missed this bit. I'll take care of it for you. If it's due to the Git conversion let me know if it's something I can

Re: std::optional defaut constructor

On 04/06/20 10:34 +0300, Ville Voutilainen via Libstdc++ wrote: On Thu, 4 Jun 2020 at 10:22, Marc Glisse wrote: > So the change is correct. Can we test the change somehow? It passes the testsuite, and libc++ has been doing it this way for years. What I feared was some regression where it woul

[PATCH 2/3] Strip GOMP_MAP_STRUCT from OpenACC exit data mappings

As flagged by Thomas, the GOMP_MAP_STRUCT mapping is not itself necessary for OpenACC "exit data" directives, and is skipped over (now) in libgomp. We might as well not emit it to start with, in line with the equivalent OpenMP directive. We can keep the "no-op" handling in libgomp for the reason of

[PATCH 0/3] OpenACC "exit data" copyout, and Fortran derived-type members

This is a split version of the patch previously posted here: https://gcc.gnu.org/legacy-ml/gcc-patches/2020-01/msg00512.html There were actually a couple of different issues addressed by that patch, and Thomas raised another (or so). This separated-out version should be more-obviously safe (in

[PATCH 1/3] OpenACC "exit data" copyout for struct members

This patch removes unnecessary special-case code in oacc-mem.c which prevented copy-back of structure members on OpenACC "exit data" directives. I've added a couple of new testcases to verify the behaviour (which fail without the patch). (On editing this mail, I notice I omitted to add a comment

[PATCH 3/3] Fortran derived-type mapping fix

This patch provides the same fix for Fortran derived type component mappings with derived types as the patch posted previously: https://gcc.gnu.org/legacy-ml/gcc-patches/2020-01/msg00512.html IIUC this part was previously approved by Tobias. OK? Julian gcc/fortran/ * trans-op

Re: std::optional defaut constructor

On 04/06/20 13:41 +0200, Richard Biener via Libstdc++ wrote: On Thu, Jun 4, 2020 at 11:34 AM Ville Voutilainen via Gcc-patches wrote: On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote: > > On Thu, 4 Jun 2020, Ville Voutilainen wrote: > > > On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote: > >> Ma

RE: [PATCH PR95254] aarch64: gcc generate inefficient code with fixed sve vector length

Hi, > -Original Message- > From: Richard Sandiford [mailto:richard.sandif...@arm.com] > Sent: Tuesday, June 2, 2020 7:17 PM > To: Yangfei (Felix) > Cc: gcc-patches@gcc.gnu.org; Uros Bizjak ; Jakub > Jelinek ; Hongtao Liu ; H.J. Lu > > Subject: Re: [PATCH PR95254] aarch64: gcc generate in

[committed] libstdc++: Make std::copy_n work with negative and non-integral sizes

Since it was added in C++11, std::copy_n and std::ranges::copy_n should do nothing given a negative size, but for random access iterators we add the size to the iterator, possibly resulting in undefined behaviour. Also, C++20 clarified that std::copy_n requires the Size type to be convertible to a

[PATCH 2/2] add vect_get_slp_vect_def

Bootstrap / regtest running on x86_64-unknown-linux-gnu. Richard. This adds vect_get_slp_vect_def to get at a SLP nodes vectorized def, abstracting away the details. It also fixes one stray failure to use SLP_TREE_REPRESENTATIVE. 2020-05-04 Richard Biener * tree-vectorizer.h (vec

[PATCH 1/2] Add explicit SLP_TREE_LANES

Bootstrap / regtest running on x86_64-unknown-linux-gnu. Richard. This adds an explicit number of scalar lanes to the SLP node avoiding to dispatch between stmts/ops and eventually not require those vectors at all. 2020-05-27 Richard Biener * tree-vectorizer.h (_slp_tree::lanes):

Re: [EXT] Re: [PATCH] Optimize and+or+sub into xor+not (PR94882)

On Thu, Jun 4, 2020 at 2:09 PM Marc Glisse wrote: > > On Thu, 4 Jun 2020, Richard Biener via Gcc-patches wrote: > > > (if (!TYPE_OVERFLOW_SANITIZED (type) && !TYPE_OVERFLOW_TRAPS (type) > > && !TYPE_SATURATING (type) > > Would the positive form > TYPE_OVERFLOW_WRAPS (type) || TYPE_OVERFLOW_UND

[PATCH] Simplify SLP code wrt SLP_TREE_DEF_TYPE

The following removes the ugly pushing of SLP_TREE_DEF_TYPE to stmt_infos and instead makes sure to handle invariants fully in vect_is_simple_use plus adjusting a few places I refrained from touching when enforcing vector types for them. It also simplifies building SLP nodes with all external op

Re: [EXT] Re: [PATCH] Optimize and+or+sub into xor+not (PR94882)

On Thu, 4 Jun 2020, Richard Biener via Gcc-patches wrote: (if (!TYPE_OVERFLOW_SANITIZED (type) && !TYPE_OVERFLOW_TRAPS (type) && !TYPE_SATURATING (type) Would the positive form TYPE_OVERFLOW_WRAPS (type) || TYPE_OVERFLOW_UNDEFINED (type) be roughly equivalent and shorter? Or am I missing s

[PATCH] middle-end/95493 - bogus MEM_ATTRS for variable array access

So this is a variant cleaning up set_mem_attributes_minus_bitpos instead. Bootstrapped and tested on x86_64-unknown-linux-gnu. I'll go with this variant since it is more obvious unless I hear otherwise. Thanks, Richard. The following patch avoids keeping the inherited MEM_ATTRS when set_mem_

Re: std::optional defaut constructor

On Thu, 4 Jun 2020, Richard Biener wrote: On Thu, Jun 4, 2020 at 11:34 AM Ville Voutilainen via Gcc-patches wrote: On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote: On Thu, 4 Jun 2020, Ville Voutilainen wrote: On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote: Maybe create a buffer, fill it

Re: std::optional defaut constructor

On Thu, 4 Jun 2020, Ville Voutilainen wrote: On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote: On Thu, 4 Jun 2020, Ville Voutilainen wrote: On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote: Maybe create a buffer, fill it with some non-zero values (-1?), then call placement new, and read some

Re: std::optional defaut constructor

On Thu, 4 Jun 2020 at 14:41, Richard Biener wrote: > Doesn't the placement new make the memory state of anything > not explicitely initialized indeterminate? That is, isn't the > testcase broken anyways since GCC can elide the memset > when seeing the placement new? Hmm, yes it does, and the tes

Re: std::optional defaut constructor

On Thu, Jun 4, 2020 at 11:34 AM Ville Voutilainen via Gcc-patches wrote: > > On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote: > > > > On Thu, 4 Jun 2020, Ville Voutilainen wrote: > > > > > On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote: > > >> Maybe create a buffer, fill it with some non-zero val

Re: [PATCH] fix bitmask conflict between PTA_AVX512VP2INTERSECT and PTA_WAITPKG

On Thu, Jun 4, 2020 at 1:15 PM H.J. Lu wrote: > > On Thu, Jun 4, 2020 at 2:55 AM Uros Bizjak wrote: > > > > On Thu, Jun 4, 2020 at 11:50 AM Cui, Lili wrote: > > > > > > Hi Uros, > > > > > > This patch is to fix bitmask conflict between PTA_AVX512VP2INTERSECT and > > > PTA_WAITPKG > > > in gcc

Re: [PATCH] fix bitmask conflict between PTA_AVX512VP2INTERSECT and PTA_WAITPKG

On Thu, Jun 4, 2020 at 2:55 AM Uros Bizjak wrote: > > On Thu, Jun 4, 2020 at 11:50 AM Cui, Lili wrote: > > > > Hi Uros, > > > > This patch is to fix bitmask conflict between PTA_AVX512VP2INTERSECT and > > PTA_WAITPKG > > in gcc/config/i386/i386.h > > > > Bootstrap is ok, make-check ok for i386

Re: [PATCH] fix bitmask conflict between PTA_AVX512VP2INTERSECT and PTA_WAITPKG

On Thu, Jun 4, 2020 at 11:50 AM Cui, Lili wrote: > > Hi Uros, > > This patch is to fix bitmask conflict between PTA_AVX512VP2INTERSECT and > PTA_WAITPKG > in gcc/config/i386/i386.h > > Bootstrap is ok, make-check ok for i386 target. Ok for trunk? > > > gcc/ChangeLog: > * config/i386

[PATCH] fix bitmask conflict between PTA_AVX512VP2INTERSECT and PTA_WAITPKG

Hi Uros, This patch is to fix bitmask conflict between PTA_AVX512VP2INTERSECT and PTA_WAITPKG in gcc/config/i386/i386.h Bootstrap is ok, make-check ok for i386 target. Ok for trunk? gcc/ChangeLog: * config/i386/i386.h (PTA_WAITPKG): Change bitmask value. --- gcc/config/i386/i386

RE: [PATCH][RFC] extend DECL_GIMPLE_REG_P to all types

> -Original Message- > From: Gcc-patches On Behalf Of Richard > Biener > Sent: 07 May 2020 14:40 > To: Richard Sandiford > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH][RFC] extend DECL_GIMPLE_REG_P to all types > > On Thu, 23 Apr 2020, Richard Biener wrote: > > > On Wed, 22 Apr 20

Re: std::optional defaut constructor

On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote: > > On Thu, 4 Jun 2020, Ville Voutilainen wrote: > > > On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote: > >> Maybe create a buffer, fill it with some non-zero values (-1?), then call > >> placement new, and read some value in the middle of the buffer

[Ada] Ada_2020: contracts for formal subprograms

AI12-0272 specifies that pre- and postconditions can be given for formal subprograms. In the presence of these contracts the formal subprogram cannot be treated simply as a renaming of the actual, but instead we must create a subgprogram wrapper that carries the specified contracts and calls the ac

[Ada] New package Ada.Task_Initialization

This package provides a way to set up a global initialization handler when tasks start. Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Arnaud Charlet gcc/ada/ * Makefile.rtl: add a-tasini object * impunit.adb (Non_Imp_File_Names_95): Add s-tasini. * libg

[Ada] Import Adafinal as convention Ada

This is in general harmless but can cause inconsistencies on some targets. Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Arnaud Charlet gcc/ada/ * bindgen.adb (Gen_Adafinal): Adafinal is convention Ada, not C.--- gcc/ada/bindgen.adb +++ gcc/ada/bindgen.adb @@ -457,7 +4

[Ada] Wrong walk order in Walk_Library_Items

We need to process the main spec later in Walk_Library_Items in order to avoid forward references in e.g. CCG. Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Arnaud Charlet gcc/ada/ * sem.adb (Walk_Library_Items): Defer processing of main spec after all other sp

[Ada] Update the documentation in checks.ads about range checks

This documents that range checks are now entirely generated by the front-end of the compiler. Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Eric Botcazou gcc/ada/ * checks.ads: Update documentation about range checks and fix minor other things.--- gcc/ada/check

[Ada] Remove OpenACC support

Remove the experimental support for OpenACC in GNAT which has never been really used and is no longer maintained. Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Arnaud Charlet gcc/ada/ * back_end.adb, opt.ads, par-prag.adb, sem_ch5.adb, sem_prag.adb, sinfo.adb,

[Ada] Put_Image attribute

First cut at implementation of the Put_Image attribute. Work in progress. Support for Put_Image is currently disabled (see Enable_Put_Image in exp_put_image.adb). Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Bob Duff gcc/ada/ * libgnat/a-stobbu.adb, libgnat/a-stobbu.

[Ada] Fix a couple of oversights in previous change

This adds a missing guard in Make_Final_Call for illegal cases and make sure Build_Derived_Private_Type does a full derivation in the new handled cases. Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Eric Botcazou gcc/ada/ * exp_ch7.adb (Make_Final_Call): Add missing gu

[Ada] Revamp dump and aux output names

This change accepts the new -dumpbase-ext and the preexisting -dumpdir options as internal GCC options. It also marks the obsolete -auxbase and -auxbase-strip options for future removal. Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Alexandre Oliva gcc/ada/ * switch.a

[Ada] Fix glitch for N_Delta_Aggregate/N_Case_Expression/N_Quantified_Expression

The Etype of the first 2 nodes is set during type resolution by procedure Resolve_Delta_Aggregate and Resolve_Case_Expression, whereas the Etype of the last one is not. Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Eric Botcazou gcc/ada/ * sinfo.ads (N_Delta_Aggregate)

[Ada] Fix Is_Absolute_Path on Windows

The Windows filename D:dir\name mean the path relative to drive D current directory. Windows has current directory on each drive separately. The D:dir\name was treated absolute before this fix. Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Dmitriy Anisimkov gcc/ada/ *

[Ada] Alignment clause ignored on completion derived from private type

This fixes the discrepancy visible between an alignment clause put on a type derived from a private type and an alignment clause put on a completion derived from the same private type, for example: with System.OS_Interface; package P is type T is limited private; type V is new System.OS_Inter

[Ada] Missing accessibility check on access discriminant in extended return

This patch fixes an issue whereby the compiler may fail to issue static accessibility errors on access discriminants within subtype indications within extended return statements. Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Justin Squirek gcc/ada/ * sem_ch6.adb (Check

[Ada] Add missing conversion in call to Finalize primitive

This makes sure that Convert_View adds the unchecked conversion from actual to formal type in the case where the type of the actual is derived from a private formal type and for the Finalize primitive; the same trick is already used for the call to the Adjust primitive. That's necessary since Unde

[Ada] Implement AI12-0275 (Make subtype_mark optional in object renamings)

This set of changes implements the Ada 202X shorthand feature of object renamings that don't specify an explicit subtype (they have neither a subtype_mark nor an access_definition), taking their subtype from the renamed object (which must be denoted by an unambiguous name). Tested on x86_64-pc-lin

[Ada] Add another ad-hoc case to the Has_Private_View mechanism

This adds another ad-hoc treatment to Copy_Generic_Node for the case of type conversions involving access types designing private types, when the Designated_Type is not referenced in the generic tree. Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Eric Botcazou gcc/ada/

[Ada] New procedure Register_Global_Unhandled_Action

Provided to enhance the GNAT.Exception_Actions API and allowing registration of an action on unhandled exceptions (e.g. Core_Dump). Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Arnaud Charlet gcc/ada/ * libgnat/a-exextr.adb (Global_Unhandled_Action): New global

[Ada] Remove System.Parameters.Single_Lock

This setting has never been used in practice and isn't tested, so remove it. Tested on x86_64-pc-linux-gnu, committed on trunk 2020-06-04 Arnaud Charlet gcc/ada/ * libgnarl/a-dynpri.adb, libgnarl/a-taside.adb, libgnarl/a-taster.adb, libgnarl/s-interr.adb, libgnarl/s-i

[Ada] Set convention and inlined flag on default null procedure

This slightly tweaks the null procedure generated for a subprogram default in a generic instantiation: as per RM 12.6 (16 2/2), the convention is explicitly set to Intrinsic, and the procedure is also marked inlined. This has two main effects: first, to help the algorithm computing the setting of

[Ada] Small tweak to special handling of private index types

This both extends the special handling applied to private index types in array type declarations to generic packages and restricts it to the index types defined in the same scope as the array type, which is the original intent of the code. This fixes the discrepancy between the direct compilation

[Ada] Fix fallout of cleanup to Has_Private_View mechanism

The Has_Private_View mechanism is also applied to actuals of the instantiations and there is the same issue for array type actuals whose component type is the actual of a preceding formal as for global types whose component type is not referenced in the tree. This can happen for nested instantiati

[Ada] Avoid buffer overflow in Long_Long_Float_Text_IO

The internal packages used to implement Ada.Text_IO.Float_IO declare some String variables that need to be large enough to hold the longest possible images computed by Float_IO. If Exp is specified to be zero and Aft is specified to be Text_IO.Field'Last then the computed image of Long_Long_Float'L

Re: [Patch] Inline optimization for tanh(x)/sinh(x) -> 1.0/cosh(x)

Hi, On Thu, 4 Jun 2020 at 01:03, Jeff Law via Gcc-patches wrote: > > On Fri, 2020-01-31 at 15:50 -0300, Vitor Guidi wrote: > > I took the required steps. The patch is attached to this email, I hope > > I got it right this time. I did not forward the patch to gcc-patches > > the first time, sorry

Re: std::optional defaut constructor

On Thu, 4 Jun 2020, Ville Voutilainen wrote: On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote: Maybe create a buffer, fill it with some non-zero values (-1?), then call placement new, and read some value in the middle of the buffer, possibly with some protection against optimizations? Ah, no, ac

Re: [PATCH] Add pattern for pointer-diff on addresses with same base/offset (PR 94234)

On Wed, Jun 3, 2020 at 4:33 PM Marc Glisse wrote: > > On Wed, 3 Jun 2020, Feng Xue OS via Gcc-patches wrote: > > >> Ah, looking at the PR, you decided to perform the operation as unsigned > >> because that has fewer NOP conversions, which, in that particular testcase > >> where the offsets are ori

Re: std::optional defaut constructor

On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote: > Maybe create a buffer, fill it with some non-zero values (-1?), then call > placement new, and read some value in the middle of the buffer, possibly > with some protection against optimizations? Ah, no, actual constructors > are fine, it is only th

  1   2   >