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

2020-06-04 Thread Hongtao Liu via Gcc-patches
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

2020-06-04 Thread Michael Meissner via Gcc-patches
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

2020-06-04 Thread Joseph Myers
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 >

[PATCH V2] Practical Improvement to Double Precision Complex Divide

2020-06-04 Thread Patrick McGehearty via Gcc-patches
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

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

2020-06-04 Thread Jonathan Wakely via Gcc-patches
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

2020-06-04 Thread Mark Wielaard
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

[committed] d: Merge upstream dmd 48d704f08

2020-06-04 Thread Iain Buclaw via Gcc-patches
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

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

2020-06-04 Thread Alexandre Oliva
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

[committed] d: Merge upstream dmd 47ed0330f

2020-06-04 Thread Iain Buclaw via Gcc-patches
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 +-

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

2020-06-04 Thread Jason Merrill via Gcc-patches
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

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

2020-06-04 Thread Harald Anlauf
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

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

2020-06-04 Thread Jason Merrill via Gcc-patches
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

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

2020-06-04 Thread Thomas Schwinge
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

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

2020-06-04 Thread Harald Anlauf
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

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)

2020-06-04 Thread Thomas Schwinge
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 > +{ > +

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

2020-06-04 Thread Thomas Schwinge
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

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

2020-06-04 Thread Thomas Schwinge
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 (_dev->lock); >gomp_fatal ("cannot unmap target block"); > } > - else if (tgt->refcount >

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

2020-06-04 Thread Thomas Schwinge
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

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

2020-06-04 Thread Thomas Schwinge
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

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

2020-06-04 Thread Thomas Schwinge
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

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

2020-06-04 Thread Thomas Schwinge
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

2020-06-04 Thread Thomas Schwinge
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

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

2020-06-04 Thread Segher Boessenkool
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

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

2020-06-04 Thread Thomas Schwinge
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:

[COMMITED] testcase for PR95464

2020-06-04 Thread Vladimir Makarov via Gcc-patches
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

2020-06-04 Thread Richard Sandiford
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

Re: [COMMITTED] patch for PR95464

2020-06-04 Thread Vladimir Makarov via Gcc-patches
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

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

2020-06-04 Thread Michael Meissner via Gcc-patches
[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

2020-06-04 Thread Michael Meissner via Gcc-patches
[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

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

2020-06-04 Thread Jeff Law via Gcc-patches
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

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

2020-06-04 Thread Srinath Parvathaneni
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]

Re: [COMMITTED] patch for PR95464

2020-06-04 Thread H.J. Lu via Gcc-patches
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

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

2020-06-04 Thread Richard Biener via Gcc-patches
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

Re: [COMMITTED] patch for PR95464

2020-06-04 Thread Vladimir Makarov via Gcc-patches
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.

2020-06-04 Thread Iain Buclaw via Gcc-patches
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

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

2020-06-04 Thread Eric Botcazou
> 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 >

Re: [COMMITTED] patch for PR95464

2020-06-04 Thread Jakub Jelinek via Gcc-patches
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

[COMMITTED] patch for PR95464

2020-06-04 Thread Vladimir Makarov via Gcc-patches
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

aarch64: PR target/95526: Fix gimplification of varargs

2020-06-04 Thread Alex Coplan
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

[PATCH] avr: Add atmega324pb MCU

2020-06-04 Thread Matwey V. Kornilov via Gcc-patches
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)

2020-06-04 Thread Naveen Hurugalawadi via Gcc-patches
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

RE: arm: Fix vfp_operand_register for VFP HI regs

2020-06-04 Thread Kyrylo Tkachov
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).

2020-06-04 Thread Kyrylo Tkachov
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

2020-06-04 Thread Richard Biener
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.

2020-06-04 Thread Kyrylo Tkachov
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

2020-06-04 Thread Julian Brown
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

Re: std::optional defaut constructor

2020-06-04 Thread Jonathan Wakely via Gcc-patches
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

Re: std::optional defaut constructor

2020-06-04 Thread Jonathan Wakely via Gcc-patches
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

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

2020-06-04 Thread Julian Brown
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

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

2020-06-04 Thread Julian Brown
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

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

2020-06-04 Thread Julian Brown
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

2020-06-04 Thread Julian Brown
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/ *

Re: std::optional defaut constructor

2020-06-04 Thread Jonathan Wakely via Gcc-patches
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: > >>

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

2020-06-04 Thread Yangfei (Felix)
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

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

2020-06-04 Thread Jonathan Wakely via Gcc-patches
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

[PATCH 2/2] add vect_get_slp_vect_def

2020-06-04 Thread Richard Biener
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

[PATCH 1/2] Add explicit SLP_TREE_LANES

2020-06-04 Thread Richard Biener
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)

2020-06-04 Thread Richard Biener via Gcc-patches
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) ||

[PATCH] Simplify SLP code wrt SLP_TREE_DEF_TYPE

2020-06-04 Thread Richard Biener
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

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

2020-06-04 Thread Marc Glisse
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

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

2020-06-04 Thread Richard Biener
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

Re: std::optional defaut constructor

2020-06-04 Thread Marc Glisse
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

Re: std::optional defaut constructor

2020-06-04 Thread Marc Glisse
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

2020-06-04 Thread Ville Voutilainen via Gcc-patches
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

Re: std::optional defaut constructor

2020-06-04 Thread Richard Biener via Gcc-patches
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

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

2020-06-04 Thread Uros Bizjak via Gcc-patches
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

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

2020-06-04 Thread H.J. Lu via Gcc-patches
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

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

2020-06-04 Thread Uros Bizjak via Gcc-patches
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: > *

[PATCH] fix bitmask conflict between PTA_AVX512VP2INTERSECT and PTA_WAITPKG

2020-06-04 Thread Cui, Lili via Gcc-patches
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. ---

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

2020-06-04 Thread Alex Coplan
> -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

Re: std::optional defaut constructor

2020-06-04 Thread Ville Voutilainen via Gcc-patches
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

[Ada] Ada_2020: contracts for formal subprograms

2020-06-04 Thread Pierre-Marie de Rodat
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

[Ada] New package Ada.Task_Initialization

2020-06-04 Thread Pierre-Marie de Rodat
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. *

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

2020-06-04 Thread Pierre-Marie de Rodat
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.---

[Ada] Remove OpenACC support

2020-06-04 Thread Pierre-Marie de Rodat
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

2020-06-04 Thread Pierre-Marie de Rodat
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,

[Ada] Import Adafinal as convention Ada

2020-06-04 Thread Pierre-Marie de Rodat
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

[Ada] Wrong walk order in Walk_Library_Items

2020-06-04 Thread Pierre-Marie de Rodat
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

[Ada] Fix a couple of oversights in previous change

2020-06-04 Thread Pierre-Marie de Rodat
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

[Ada] Revamp dump and aux output names

2020-06-04 Thread Pierre-Marie de Rodat
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/ *

[Ada] Fix glitch for N_Delta_Aggregate/N_Case_Expression/N_Quantified_Expression

2020-06-04 Thread Pierre-Marie de Rodat
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

[Ada] Fix Is_Absolute_Path on Windows

2020-06-04 Thread Pierre-Marie de Rodat
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

2020-06-04 Thread Pierre-Marie de Rodat
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

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

2020-06-04 Thread Pierre-Marie de Rodat
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

[Ada] Add missing conversion in call to Finalize primitive

2020-06-04 Thread Pierre-Marie de Rodat
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

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

2020-06-04 Thread Pierre-Marie de Rodat
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

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

2020-06-04 Thread Pierre-Marie de Rodat
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

2020-06-04 Thread Pierre-Marie de Rodat
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

2020-06-04 Thread Pierre-Marie de Rodat
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,

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

2020-06-04 Thread Pierre-Marie de Rodat
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

2020-06-04 Thread Pierre-Marie de Rodat
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

2020-06-04 Thread Pierre-Marie de Rodat
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

[Ada] Avoid buffer overflow in Long_Long_Float_Text_IO

2020-06-04 Thread Pierre-Marie de Rodat
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

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

2020-06-04 Thread Christophe Lyon via Gcc-patches
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

2020-06-04 Thread Marc Glisse
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,

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

2020-06-04 Thread Richard Biener via Gcc-patches
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

Re: std::optional defaut constructor

2020-06-04 Thread Ville Voutilainen via Gcc-patches
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

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

2020-06-04 Thread Richard Biener via Gcc-patches
On Wed, Jun 3, 2020 at 12:36 PM Naveen Hurugalawadi wrote: > > Hi Richard, > > Thanks for reviewing the patch and sharing your comments. > > >> pattern should be guarded with !TYPE_OVERFLOW_SANITIZED > >> and/or !TYPE_OVERFLOW_TRAPS > Done. > > >> can you add some cases with unsigned types and

Re: std::optional defaut constructor

2020-06-04 Thread Marc Glisse
On Thu, 4 Jun 2020, Ville Voutilainen wrote: Right, I was just wondering whether we can reasonably verify in a test that the whole shebang is not zeroed. That may need a tree-dump scan in the test, and probably should go into PR86173 anyway, so I'm not saying such a thing needs to be a part

Re: std::optional defaut constructor

2020-06-04 Thread Ville Voutilainen via Gcc-patches
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 would yield worse code in some > cases, or lose some property

  1   2   >