Re: [PATCH] Remove arc profile histogram in non-LTO mode.

On Thu, Sep 20, 2018 at 6:43 PM Jan Hubicka wrote: > > > On Thu, Sep 20, 2018 at 5:26 PM Jan Hubicka wrote: > > > > > > > On Thu, Sep 20, 2018 at 2:11 AM Martin Liška wrote: > > > > > > > > > > Hello. > > > > > > > > > > I've been working for some time on a patch that simplifies how we set > > >

C++ PATCH for c++/87372, __func__ constexpr evaluation

The patch for P0595R1 - is_constant_evaluated had this hunk: @@ -5279,7 +5315,9 @@ maybe_constant_init_1 (tree t, tree decl, bool allow_non_constant) else if (CONSTANT_CLASS_P (t) && allow_non_constant) /* No evaluation needed. */; else -t = cxx_eval_outermost_constant_expr (t, al

Re: [PATCH, OpenACC] Fortran "declare create"/allocate support for OpenACC

[Please Cc the fortran list on fortran patches] On Thu, 20 Sep 2018 19:59:08 -0400 Julian Brown wrote: > From b63d0329fb73679b07f6318b8dd092113d5c8505 Mon Sep 17 00:00:00 2001 > From: Julian Brown > Date: Wed, 12 Sep 2018 20:15:08 -0700 > Subject: [PATCH 2/2] Fortran "declare create"/allocate s

Re: [PATCH] PR libstdc++/78179 run long double tests separately

> Date: Thu, 20 Sep 2018 15:22:23 +0100 > From: Jonathan Wakely > On 20/09/18 15:36 +0200, Christophe Lyon wrote: > >On Wed, 19 Sep 2018 at 23:13, Rainer Orth > >wrote: > >> > >> Hi Christophe, > >> > >> > I have noticed failures on hypot-long-double.cc on arm, so I suggest we > >> > add: > >>

[PATCH, OpenACC] Fortran "declare create"/allocate support for OpenACC

This patch (a combination of several previous patches by Cesar) adds support for OpenACC 2.5's "declare create" directive with Fortran allocatable variables (2.13.2. create clause). Allocate and deallocate statements now allocate/deallocate memory on the target device as well as on the host. This

[PATCH, OpenACC] Enable GOMP_MAP_FIRSTPRIVATE_INT for OpenACC

This patch (by Cesar) changes the way that mapping of firstprivate scalars works for OpenACC. For scalars whose type has a size equal to or smaller than the size of a pointer, rather than copying the value of the scalar to the target device and having a separate mapping for a pointer to the copied

Re: [PATCH] Optimize sin(atan(x)), take 2

Pinging match.pd and real.c maintainers, as suggested in IRC. Sorry if it is inappropriate On Mon, Sep 17, 2018 at 9:46 AM Giuliano Augusto Faulin Belinassi wrote: > > Ping. > > On Mon, Sep 3, 2018 at 4:11 PM, Giuliano Augusto Faulin Belinassi > wrote: > > Fixed the issues pointed by the previous

Re: C++ PATCH to refine c++/87109 patch

OK. On Thu, Sep 20, 2018 at 4:49 PM, Marek Polacek wrote: > On Thu, Sep 20, 2018 at 12:20:08PM -0400, Jason Merrill wrote: >> On Thu, Sep 20, 2018 at 11:53 AM, Marek Polacek wrote: >> > On Thu, Sep 20, 2018 at 11:25:38AM -0400, Jason Merrill wrote: >> >> On Wed, Sep 19, 2018 at 9:50 PM, Marek Po

[PATCH,FORTRAN] Tweak locations around CAF simplify

addresses: FIXME: gfc_current_locus is wrong. by using the locus of the current intrinsic. Regtests clean, ok for trunk? gcc/fortran/ChangeLog: 2018-09-20 Bernhard Reutner-Fischer * simplify.c (gfc_simplify_failed_or_stopped_images): Use current intrinsic where locus.

Re: [PATCH 2/2] [ARC] Avoid specific constants to end in limm field.

* Claudiu Zissulescu [2018-09-17 15:50:27 +0300]: > The 3-operand instructions accepts to place an immediate into the > second operand. However, this immediate will end up in the long > immediate field. This patch avoids constants to end up in the limm > field for particular instructions when com

Re: [PATCH 1/2] [ARC] Check for odd-even register when emitting double mac ops.

* Claudiu Zissulescu [2018-09-17 15:50:26 +0300]: > Avoid generate dmac instructions when the register is not odd-even, > use instead the equivalent mac instruction. > > gcc/ > Claudiu Zissulescu > > * config/arc/arc.md (maddsidi4_split): Don't use dmac if the > destination

Re: [PATCH 08/25] Fix co-array allocation

On Thu, Sep 20, 2018 at 1:01 PM Thomas Koenig wrote: > > We addressed integrating OpenCoarray into the gcc source tree at the > recent Gcc summit during the gfortran BoF session. > I agree with keeping it as a separate code base, but comments from some gfortran developers on the gfortran mailing

Re: C++ PATCH to refine c++/87109 patch

On Thu, Sep 20, 2018 at 12:20:08PM -0400, Jason Merrill wrote: > On Thu, Sep 20, 2018 at 11:53 AM, Marek Polacek wrote: > > On Thu, Sep 20, 2018 at 11:25:38AM -0400, Jason Merrill wrote: > >> On Wed, Sep 19, 2018 at 9:50 PM, Marek Polacek wrote: > >> > Aaaand this addresses > >> >

Re: [PATCH 08/25] Fix co-array allocation

Hi Damian, On a related note, two Sourcery Institute developers have attempted to edit the GCC build system to make the downloading and building of OpenCoarrays automatically part of the gfortran build process. Neither developer succeeded. We addressed integrating OpenCoarray into the gcc sou

Re: [Patch][GCC] Document and fix -r (partial linking)

On Sat, 1 Sep 2018, Allan Sandfeld Jensen wrote: > On Montag, 27. August 2018 15:37:15 CEST Joseph Myers wrote: > > On Sun, 26 Aug 2018, Allan Sandfeld Jensen wrote: > > > Patch updated. I specifically edited a number of the existing tests that > > > used both -r and -nostdlib and removed -nostdli

Re: [Patch, Fortran, OOP] PR 46313: OOP-ABI issue, ALLOCATE issue, CLASS renaming issue

Am Mi., 19. Sep. 2018 um 16:50 Uhr schrieb Bernhard Reutner-Fischer : > > On Mon, 17 Sep 2018 at 22:25, Janus Weil wrote: > > > The regtest was successful. I don't think the off-by-two error for the > > vtab/vtype comparisons is a big problem in practice, since the number > > of internal symbols w

[patch, rfc] Clobber scalar intent(out) variables on entry

Hi, the patch below tries to clobber scalar intent(out) arguments on procedure entry. Index: trans-decl.c === --- trans-decl.c(Revision 264423) +++ trans-decl.c(Arbeitskopie) @@ -4143,6 +4143,19 @@ init_intent_out_dt

[PATCH] rs6000: Remove -misel={yes,no}

These options have been deprecated for many years, supplanted by -misel and -mno-isel. This patch finally removes them. Committing to trunk. 2018-09-20 Segher Boessenkool * config/rs6000/rs6000.opt (misel=no, misel=yes): Delete. * doc/invoke.texi (RS/6000 and PowerPC Options

Re: [patch,openacc] Generate sequential loop for OpenACC loop directive inside kernels

On 09/20/2018 10:14 AM, Cesar Philippidis wrote: > As Chung-Lin noted here > : > > This patch adjusts omp-low.c:expand_omp_for_generic() to expand to a > "sequential" loop form (without the OMP runtime calls), used for loop > directiv

[PATCH, rs6000] Update vec_splat references in testcases for validity.

Hi, This updates those powerpc testsuite tests that are using the vec_splat() builtin with an invalid arg1. Per discussions during the review of gimple-folding for vec_splat(), it was clarified that arg1 for vec_splat() should be a valid index into the referenced vector (no modulo). OK fo

Re: [patch,openacc] handle missing OMP_LIST_ clauses in fortran's parse tree debugger

On 09/20/2018 11:22 AM, Paul Richard Thomas wrote: > Hi Cesar, > > It looks OK to me. > > Thanks for the patch. > > Paul Thanks! Committed in r264446. Cesar > On 20 September 2018 at 18:21, Cesar Philippidis > wrote: >> This patch updates Fortran's parse tree printer to print the names of >

[patch,openacc] Update _OPENACC value and documentation for OpenACC 2.5

This patch formally introduces OpenACC 2.5 functionality in various GCC documentation sources along with with updated the _OPENACC value in the various offloading header files. As of right now, GCC trunk already supports the updated OpenACC 2.5 data clause semantics. Julian, Chung-Lin and I have b

[patch,openacc] Set safelen to INT_MAX for oacc independent pragma

This is another old gomp4 OpenACC patch which impacts targets that use simd vectorization, such as the host and AMD GCN, rather than nvptx. Basically, as the subject states, it sets safelen to INT_MAX for independent acc loops, which I believe is already being done for OpenMP in certain situations.

[patch,openacc] Propagate independent clause for OpenACC kernels pass

This is another old patch teaches the omp expansion pass how to propagate the acc loop independent clause to the later stages throughout compilation. Unfortunately, it didn't include any test cases. I'm not sure how effective this will be with the existing kernel parloops pass. But as I noted in my

[patch,openacc] Fix PR71959: lto dump of callee counts

This is another old gomp4 patch that demotes an ICE in PR71959 to a linker warning. One problem here is that it is not clear if OpenACC allows individual member functions in C++ classes to be marked as acc routines. There's another issue accessing member data inside offloaded regions. We'll add som

[patch,openacc] Fix hang when running oacc exec with CUDA 9.0 nvprof

While tuning the performance of nvptx OpenACC offloading earlier this year, Tom fixed a bug in og7 that prevented Nvidia's nvprof profiling tool from working with CUDA 9. Tom posted more details on the patch here , which is still relevant he

[patch,openacc] handle missing OMP_LIST_ clauses in fortran's parse tree debugger

This patch updates Fortran's parse tree printer to print the names of new OpenACC data clauses. I'm not if this functionality is widely used or not, but from a standpoint of correctness, this patch would probably be nice to have. It this patch OK for trunk? I bootstrapped and regtested it for x86_

[PATCH] rs6000: Delete VECTOR_OTHER

It's never used. Committing to trunk. 2018-09-20 Segher Boessenkool * config/rs6000/rs6000-opts.h (enum rs6000_vector): Delete VECTOR_OTHER. * config/rs6000/rs6000.c (rs6000_debug_vector_unit): Delete case VECTOR_OTHER. --- gcc/config/rs6000/rs6000-opts.h |

[patch,openacc] Generate sequential loop for OpenACC loop directive inside kernels

As Chung-Lin noted here : This patch adjusts omp-low.c:expand_omp_for_generic() to expand to a "sequential" loop form (without the OMP runtime calls), used for loop directives inside OpenACC kernels constructs. Tom mentions that this

Re: [PATCH] PR libstdc++/78179 run long double tests separately

On Thu, 20 Sep 2018 at 16:22, Jonathan Wakely wrote: > > On 20/09/18 15:36 +0200, Christophe Lyon wrote: > >On Wed, 19 Sep 2018 at 23:13, Rainer Orth > >wrote: > >> > >> Hi Christophe, > >> > >> > I have noticed failures on hypot-long-double.cc on arm, so I suggest we > >> > add: > >> > > >> >

[patch,openacc] Fix infinite recursion in OMP clause pretty-printing, default label

Apparently, Tom ran into an ICE when we were adding support for new clauses back in the gomp-4_0-branch days. This patch shouldn't be necessary because all of the clauses are fully implemented now, but it may prevent similar bugs from occurring in the future at least during development. Is this p

[C++ PATCH] PR c++/87075 - ICE with constexpr array initialization.

My patch of 2016-08-26 to avoid calling a trivial default constructor introduced TARGET_EXPRs initialized with void_node to express trivial initialization. But when this shows up in a VEC_INIT_EXPR, we weren't prepared to handle it. Fixed by handling it explicitly in cxx_eval_vec_init_1. Tested

[patch,openacc] Fix acc_shutdown issue

Attached is an old gomp4 patch that allegedly fixes an shutdown runtime issue involving OpenACC accelerators. Unfortunately, the original patch didn't include a test case, nor did it generate any regressions in the libgomp testsuite when I reverted it in og8. With that said, I like how this patch

[patch,opencc] Don't mark OpenACC auto loops as independent inside acc parallel regions

OpenACC as a concept of loop independence, in which independent loops may be executed in parallel across gangs, workers and vectors. Inside acc parallel regions, if a loop isn't explicitly marked seq or auto, it is predetermined to be independent. This patch corrects a bug where acc loops marked a

[patch,openacc] Better distinguish OpenACC and OpenMP sections in libgomp.texi

This patch updates the libgomp documentation to more clearly identify OpenMP-specific sections. Specifically, the sections "Runtime Library Routine" and "Environment Variables" are now prefixed by OpenMP, because those sections are applicable to OpenACC. Is this OK for trunk? I verified that libgo

Re: [GCC][PATCH v2][Aarch64] Exploiting BFXIL when OR-ing two AND-operations with appropriate bitmasks

On Wed, 19 Sep 2018 at 11:31, Kyrill Tkachov wrote: > > Hi Christophe, > > On 18/09/18 23:00, Christophe Lyon wrote: > > On Thu, 13 Sep 2018 at 11:49, Kyrill Tkachov > > wrote: > >> > >> On 13/09/18 10:25, Sam Tebbs wrote: > >>> On 09/11/2018 04:20 PM, James Greenhalgh wrote: > On Tue, Sep 0

Re: [PATCH 08/25] Fix co-array allocation

On 20/09/18 16:56, Janne Blomqvist wrote: Ok, looks good. Thanks. There are some other remaining incorrect uses of integer_type_node (at least one visible in the diff), but that can be done as a separate patch (not saying you must do it as a precondition for anything, though it would of cou

Re: C++ PATCH to refine c++/87109 patch

On Thu, Sep 20, 2018 at 11:53 AM, Marek Polacek wrote: > On Thu, Sep 20, 2018 at 11:25:38AM -0400, Jason Merrill wrote: >> On Wed, Sep 19, 2018 at 9:50 PM, Marek Polacek wrote: >> > Aaaand this addresses >> > , >> > as I promised earlier.

Re: [openacc] Teach gfortran to lower OpenACC routine dims

On Thu, 20 Sep 2018 07:41:08 -0700 Cesar Philippidis wrote: > On 09/19/2018 03:27 PM, Bernhard Reutner-Fischer wrote: > > On Wed, 5 Sep 2018 12:52:03 -0700 > > Cesar Philippidis wrote: > >> diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c > >> index eea6b81ebfa..eed868f475b 1006

Re: [PATCH 22/25] Add dg-require-effective-target exceptions

On 17/09/18 18:51, Mike Stump wrote: On Sep 5, 2018, at 4:52 AM, a...@codesourcery.com wrote: There are a number of tests that fail because they assume that exceptions are available, but GCN does not support them, yet. So, generally we don't goop up the testsuite with the day to day port stuff

Re: [PATCH 08/25] Fix co-array allocation

On Wed, Sep 19, 2018 at 7:24 PM Andrew Stubbs wrote: > On 05/09/18 19:07, Janne Blomqvist wrote: > > The argument must be of type size_type_node, not sizetype. Please instead > > use > > > > size = build_zero_cst (size_type_node); > > > > > >> * trans-intrinsic.c (conv_intrinsic_event_qu

Re: C++ PATCH to refine c++/87109 patch

On Thu, Sep 20, 2018 at 11:25:38AM -0400, Jason Merrill wrote: > On Wed, Sep 19, 2018 at 9:50 PM, Marek Polacek wrote: > > Aaaand this addresses > > , > > as I promised earlier. I hope I got it right. > > > > Bootstrapped/regtested on x86_6

Re: [patch] prepend vxworks-dummy.h to tm_file for powerpc

Hi Segher, > On 20 Sep 2018, at 17:44, Segher Boessenkool > wrote: > > Looks fine to me (for all branches). Thanks, Great :-) Thanks for your prompt feedabck !

Re: [patch] prepend vxworks-dummy.h to tm_file for powerp

Hi Olivier, On Thu, Sep 20, 2018 at 04:04:51PM +0200, Olivier Hainque wrote: > vxworks-dummy.h is intended to be included in the list of > target header files for every CPU for which we have at least > one VxWorks port. > > It essentially provides default values for common VxWorks > markers (typi

Re: [PATCH 11/25] Simplify vec_merge according to the mask.

On 17/09/18 10:05, Richard Sandiford wrote: Would be good to have self-tests for the new transforms. [...] known_eq, since we require equality for correctness. Same for the other tests. How about the attached? I've made the edits you requested and written some self-tests. Doesn't simplif

Re: C++ PATCH to refine c++/87109 patch

On Wed, Sep 19, 2018 at 9:50 PM, Marek Polacek wrote: > Aaaand this addresses > , > as I promised earlier. I hope I got it right. > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > 2018-09-19 Marek Polacek > > PR c++/8

[patch] leverage cacheTextUpdate for __clear_cache on VxWorks

Hello, Proper synchronization of instruction and data caches for trampolines is always tricky. As we we considering various options to achieve this on ARM for VxWorks, Alex found out about the cacheTextUpdate entry point. The function is expected to always be available and to perform whatever ne

[Patch 3/3][Aarch64] Implement Aarch64 SIMD ABI

This is the third of three patches for Aarch64 SIMD ABI support.  This patch is not fully tested yet but I want to post it to get comments. This is the only patch of the three that touches non-aarch64 specific code.  The changes here are made to allow GCC to have better information about what regi

[Patch 2/3][Aarch64] Implement Aarch64 SIMD ABI

This is the second of three Aarch64 patch for SIMD ABI support.  It defines the TARGET_SIMD_CLONE_* macros so that GCC will recognize and vectorize loops containing SIMD functions.  It requires that patch one of the Aarch64 SIMD ABI get checked in first. This patch has not been fully regression te

[Patch 1/3][Aarch64] Implement Aarch64 SIMD ABI

Here is a new version of my patch to support the Aarch64 SIMD ABI in GCC. There is no functional change, I just removed the definition of V23_REGNUM from aarch64.md.  This is no longer needed because another patch that was checked in has added it.  I am following up this patch with two more, one to

Re: [PATCH v4] [aarch64] Add HiSilicon tsv110 CPU support

Hi James, On 2018/9/20 22:22, James Greenhalgh wrote: > On Wed, Sep 19, 2018 at 04:53:52AM -0500, Shaokun Zhang wrote: >> This patch adds HiSilicon's an mcpu: tsv110, which supports v8_4A. >> It has been tested on aarch64 and no regressions from this patch. > > This patch is OK for Trunk. > > Do

[patch] cleanup handling of libgcc and libc_internal for VxWorks

Hello, For static RTPs, libc_internal is included in link closures through LIB_SPEC and LIBGCC_SPEC, which makes it hard to conditionally remove with command line options such as -nolibc. This change arranges to have libc_internal dragged in from LIB_SPEC only and reworks the ordering of libs

Re: [RFA] Minor cleanup to VRP/EVRP handling of deferred edge/switch optimization

On 9/20/18 6:51 AM, Richard Biener wrote: > On Mon, Sep 17, 2018 at 4:50 PM Jeff Law wrote: >> >> This is a relatively minor cleanup that I should have caught last cycle, >> but somehow missed. >> >> We have two structures TO_REMOVE_EDGES and TO_UPDATE_SWITCH_STMTS which >> are used by the VRP/EVR

[patch] leverage STARTFILE_PREFIX_SPEC for vxworks7

Hello, To help locate crt0.o with -l:crt0.o on VxWorks7, we currently stick an ad-hoc -L in LIB_SPEC. This gets removed by -nodefaultlibs, which then affects more that just default libs. This patch fixes this by replacing the ad-hoc -L by a STARTFILE_PREFIX_SPEC, which makes sense anyway for som

Re: [openacc] Teach gfortran to lower OpenACC routine dims

On 09/19/2018 03:27 PM, Bernhard Reutner-Fischer wrote: > On Wed, 5 Sep 2018 12:52:03 -0700 > Cesar Philippidis wrote: > >> At present, gfortran does not encode the gang, worker or vector >> parallelism clauses when it creates acc routines dim attribute for >> subroutines and functions. While sup

[patch] account for 64bit case in type size defaults for vxworks

This is a second preliminary patch for 64bit vxworks on some CPUs. Checked on a gcc-8 based source tree that I can still build functional compilers passing Ada ACATS for VxWorks 6.9 and 7.0. Bootstrapped and reg tested on mainline for x86_64-linux. With Kind Regards, Olivier 2018-09-20 Olivi

Re: [PATCH] PR libstdc++/78179 run long double tests separately

On 20/09/18 15:36 +0200, Christophe Lyon wrote: On Wed, 19 Sep 2018 at 23:13, Rainer Orth wrote: Hi Christophe, > I have noticed failures on hypot-long-double.cc on arm, so I suggest we add: > > diff --git > a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc > b/libstdc++

Re: [PATCH v4] [aarch64] Add HiSilicon tsv110 CPU support

On Wed, Sep 19, 2018 at 04:53:52AM -0500, Shaokun Zhang wrote: > This patch adds HiSilicon's an mcpu: tsv110, which supports v8_4A. > It has been tested on aarch64 and no regressions from this patch. This patch is OK for Trunk. Do you need someone to commit it on your behalf? Thanks, James > >

Re: [PATCH 14/25] Disable inefficient vectorization of elementwise loads/stores.

Richard Biener writes: > On Thu, Sep 20, 2018 at 3:40 PM Richard Sandiford > wrote: >> >> Richard Biener writes: >> > On Mon, Sep 17, 2018 at 2:40 PM Andrew Stubbs >> > wrote: >> >> On 17/09/18 12:43, Richard Sandiford wrote: >> >> > OK, sounds like the cost of vec_construct is too low then.

[patch] introduce a TARGET_VXWORKS64 marker

Hello, This is a preliminary patch before the addition of support for 64bit VxWorks on some CPUs, which incurs sometimes subtle ABI variations. Checked on a gcc-8 based source tree that I can still build functional compilers passing Ada ACATS for VxWorks 6.9 and 7.0. Bootstrapped and reg tested

Re: Fold more boolean expressions

On Thu, Sep 20, 2018 at 4:00 PM Marc Glisse wrote: > > On Thu, 20 Sep 2018, Richard Biener wrote: > > > On Sat, Sep 15, 2018 at 8:01 AM MCC CS wrote: > >> > >> Sorry for doing the same mistake twice. Is this OK, and do > >> I need to test it again after the first version of this > >> patch? > >>

Re: [PATCH 14/25] Disable inefficient vectorization of elementwise loads/stores.

On Thu, Sep 20, 2018 at 3:40 PM Richard Sandiford wrote: > > Richard Biener writes: > > On Mon, Sep 17, 2018 at 2:40 PM Andrew Stubbs wrote: > >> On 17/09/18 12:43, Richard Sandiford wrote: > >> > OK, sounds like the cost of vec_construct is too low then. But looking > >> > at the port, I see y

[patch] move default #define for TARGET_VXWORKS7 to vxworks-dummy.h

Where it belongs, together with the original TARGET_VXWORKS marker. Checked on a gcc-8 based source tree that I can still build functional compilers passing Ada ACATS for VxWorks 6.9 and 7.0. Bootstrapped and reg tested on mainline for x86_64-linux. With Kind Regards, Olivier 2018-09-20 Olivi

Re: [patch] Fix PR tree-optimization/86990

On Mon, Sep 17, 2018 at 9:12 AM Eric Botcazou wrote: > > Hi, > > this is a regression present on the mainline only: now that the GIMPLE store > merging pass is able to mix constants and SSA_NAMEs on the RHS of stores to > bit-fields, we need to check that the entire merged store group is made of >

PING [PATCH] Add new warning flag "warn_prio_ctor_dtor"

Hi Joseph, Please consider this mail as a reminder to review the patch posted at: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00132.html Please review the patch and let me know if any modifications are required. Thanks, Vinay -Original Message- From: Joseph Myers Sent: 03 September

[patch] prepend vxworks-dummy.h to tm_file for powerp

Hello, vxworks-dummy.h is intended to be included in the list of target header files for every CPU for which we have at least one VxWorks port. It essentially provides default values for common VxWorks markers (typically, macros conveying if we are configured for such or such VxWorks variant), s

Re: Fold more boolean expressions

On Thu, 20 Sep 2018, Richard Biener wrote: On Sat, Sep 15, 2018 at 8:01 AM MCC CS wrote: Sorry for doing the same mistake twice. Is this OK, and do I need to test it again after the first version of this patch? 2018-09-15 MCC CS gcc/ PR tree-optimization/87261 * mat

PATCH to add -Wno-init-list-lifetime to C++ Language Options

Applying as obvious. 2018-09-20 Marek Polacek * doc/invoke.texi: Add -Wno-init-list-lifetime to C++ Language Options. diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi index aab5fcec35a..cfa9c143784 100644 --- gcc/doc/invoke.texi +++ gcc/doc/invoke.texi @@ -229,7 +229,7 @@ in the fol

Re: [PATCH 14/25] Disable inefficient vectorization of elementwise loads/stores.

Richard Biener writes: > On Mon, Sep 17, 2018 at 2:40 PM Andrew Stubbs wrote: >> On 17/09/18 12:43, Richard Sandiford wrote: >> > OK, sounds like the cost of vec_construct is too low then. But looking >> > at the port, I see you have: >> > >> > /* Implement TARGET_VECTORIZE_BUILTIN_VECTORIZATION

Re: [PATCH] PR libstdc++/78179 run long double tests separately

On Wed, 19 Sep 2018 at 23:13, Rainer Orth wrote: > > Hi Christophe, > > > I have noticed failures on hypot-long-double.cc on arm, so I suggest we add: > > > > diff --git > > a/libstdc++-v3/testsuite/26_numerics/headers/cmath/hypot-long-double.cc > > b/libstdc++-v3/testsuite/26_numerics/headers/cma

Re: [PATCH 16/25] Fix IRA ICE.

On 20/09/18 13:46, Richard Sandiford wrote: Andrew Stubbs writes: In the case of move_unallocated_pseudos it's because the table pseudo_replaced_reg only has entries for the new pseudos directly created by find_moveable_pseudos, not the ones created indirectly. What I more meant was: where do

Re: Fold more boolean expressions

On Sat, Sep 15, 2018 at 8:01 AM MCC CS wrote: > > Sorry for doing the same mistake twice. Is this OK, and do > I need to test it again after the first version of this > patch? > > 2018-09-15 MCC CS > > gcc/ > PR tree-optimization/87261 > * match.pd: Add boolean optimizatio

Re: [PATCH 02/25] Propagate address spaces to builtins.

On Wed, Sep 5, 2018 at 1:50 PM wrote: > > > At present, pointers passed to builtin functions, including atomic operators, > are stripped of their address space properties. This doesn't seem to be > deliberate, it just omits to copy them. > > Not only that, but it forces pointer sizes to Pmode, wh

Re: [PATCH 14/25] Disable inefficient vectorization of elementwise loads/stores.

On Mon, Sep 17, 2018 at 2:40 PM Andrew Stubbs wrote: > > On 17/09/18 12:43, Richard Sandiford wrote: > > OK, sounds like the cost of vec_construct is too low then. But looking > > at the port, I see you have: > > > > /* Implement TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST. */ > > > > int > > gc

Re: [RFA] Minor cleanup to VRP/EVRP handling of deferred edge/switch optimization

On Mon, Sep 17, 2018 at 4:50 PM Jeff Law wrote: > > This is a relatively minor cleanup that I should have caught last cycle, > but somehow missed. > > We have two structures TO_REMOVE_EDGES and TO_UPDATE_SWITCH_STMTS which > are used by the VRP/EVRP code to record edges to remove and switch > stat

Re: Fix PEELING_FOR_NITERS calculation (PR 87288)

On Thu, Sep 20, 2018 at 1:44 PM Richard Sandiford wrote: > > PEELING_FOR_GAPS now means "peel one iteration for the epilogue", > in much the same way that PEELING_FOR_ALIGNMENT > 0 means > "peel that number of iterations for the prologue". We weren't > taking this into account when deciding wheth

Re: [PATCH 16/25] Fix IRA ICE.

Andrew Stubbs writes: > On 17/09/18 10:22, Richard Sandiford wrote: >> writes: >>> The IRA pass makes an assumption that any pseudos created after the >>> pass begins >>> were created explicitly by the pass itself and therefore will have >>> corresponding entries in its other tables. >>> >>> The

Re: Add missing alignment checks in epilogue loop vectorisation (PR 86877)

On Thu, Sep 20, 2018 at 1:42 PM Richard Sandiford wrote: > > Epilogue loop vectorisation skips vect_enhance_data_refs_alignment > since it doesn't make sense to version or peel the epilogue loop > (that will already have happened for the main loop). But this means > that it also fails to check wh

Re: [PATCH 03/25] Improve TARGET_MANGLE_DECL_ASSEMBLER_NAME.

On Wed, Sep 19, 2018 at 5:11 PM Julian Brown wrote: > > On Fri, 14 Sep 2018 22:49:35 -0400 > Julian Brown wrote: > > > > > On 12/09/18 16:16, Richard Biener wrote: > > > > It may well be that there's a better way to solve the problem, or > > > > at least to do the lookups. > > > > > > > > It may

[PATCH] i386: Don't peephole test to and on CPUs that don't like it

Some AMD CPUs fuse "test" followed by a conditional branch into a single uop, but don't fuse "and" followed by a conditional branch. This patch makes the test-to-and peephole rules depend on not tuning for BDVER. This is a slight improvement in many cases, but it becomes more significant when combi

Re: [PATCH][RFC] Fix PR63155 (some more)

On Wed, 19 Sep 2018, Richard Biener wrote: > > The second testcase in the above PR runs into our O(N) bitmap element > search limitation and spends 8s (60%) of the compile-time in the SSA > propagator > engine (when optimizing). The patch improves that to 0.9s (15%). For the > first testcase

Fix PEELING_FOR_NITERS calculation (PR 87288)

PEELING_FOR_GAPS now means "peel one iteration for the epilogue", in much the same way that PEELING_FOR_ALIGNMENT > 0 means "peel that number of iterations for the prologue". We weren't taking this into account when deciding whether we needed to peel further scalar iterations beyond the iterations

Add missing alignment checks in epilogue loop vectorisation (PR 86877)

Epilogue loop vectorisation skips vect_enhance_data_refs_alignment since it doesn't make sense to version or peel the epilogue loop (that will already have happened for the main loop). But this means that it also fails to check whether the accesses are suitably aligned for the new vector subarch.

Re: [PATCH 09/25] Elide repeated RTL elements.

On 19/09/18 17:38, Andrew Stubbs wrote: Here's an updated patch incorporating the RTL front-end changes. I had to change from "repeated 2x" to "repeated x2" because the former is not a valid C token, and apparently that's important. Here's a patch with self tests added, for both reading and wr

Re: [PATCH] Remove arc profile histogram in non-LTO mode.

> On Thu, Sep 20, 2018 at 5:26 PM Jan Hubicka wrote: > > > > > On Thu, Sep 20, 2018 at 2:11 AM Martin Liška wrote: > > > > > > > > Hello. > > > > > > > > I've been working for some time on a patch that simplifies how we set > > > > the hotness threshold of basic blocks. Currently, we calculate so

Re: [PATCH] Remove arc profile histogram in non-LTO mode.

On Thu, Sep 20, 2018 at 5:26 PM Jan Hubicka wrote: > > > On Thu, Sep 20, 2018 at 2:11 AM Martin Liška wrote: > > > > > > Hello. > > > > > > I've been working for some time on a patch that simplifies how we set > > > the hotness threshold of basic blocks. Currently, we calculate so called > > > ar

Re: [PATCH] Remove arc profile histogram in non-LTO mode.

> On Thu, Sep 20, 2018 at 2:11 AM Martin Liška wrote: > > > > Hello. > > > > I've been working for some time on a patch that simplifies how we set > > the hotness threshold of basic blocks. Currently, we calculate so called > > arc profile histograms that should identify edges that cover 99.9% of

Re: [PATCH][GCC][AArch64] Add support for SVE stack clash probing [patch (2/7)]

Hi Richard, The 09/11/2018 16:20, Richard Sandiford wrote: > Tamar Christina writes: > >> > + > >> > + /* No probe leave. */ > >> > + ASM_OUTPUT_INTERNAL_LABEL (asm_out_file, loop_end_lab); > >> > + return ""; > >> > >> With the CFA stuff and constant load, I think this works out as: > >> >

Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions (v4)

On Thu, Sep 20, 2018 at 09:12:53AM +0200, Andreas Schwab wrote: > On Sep 19 2018, Jason Merrill wrote: > > > Andreas, do the new testcases pass? That would surprise me, but OK if so. > > No, they don't. > > /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp

Re: [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)

On Wed, Sep 19, 2018 at 4:19 PM Martin Sebor wrote: > > On 09/18/2018 10:23 PM, Jeff Law wrote: > > On 9/18/18 1:46 PM, Martin Sebor wrote: > >> On 09/18/2018 12:58 PM, Jeff Law wrote: > >>> On 9/18/18 11:12 AM, Martin Sebor wrote: > >>> > > My bad. Sigh. CCP doesn't track copies, just consta

[PATCH v2] Change EQ_ATTR_ALT to support up to 64 alternatives

Bootstrapped and regtested on x86_64-redhat-linux and s390x-redhat-linux. Changes since v1: * Use alternative_mask and HOST_WIDE_INT in attr_alt_intersection, attr_alt_union and attr_alt_complement. On S/390 there is a need to support more than 32 instruction alternatives per define_insn. Cur

Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions (v4)

On Sep 19 2018, Jason Merrill wrote: > Andreas, do the new testcases pass? That would surprise me, but OK if so. No, they don't. /usr/local/gcc/gcc-20180920/gcc/testsuite/g++.dg/cpp2a/constexpr-virtual2.C:29:26: error: non-constant condition for static assertion /usr/local/gcc/gcc-

Re: [Ada] Fix comment typo in exp_ch9.adb

OK, thanks. > Index: gcc/ada/ChangeLog > === > > --- gcc/ada/ChangeLog (revision 264438) > +++ gcc/ada/ChangeLog (working copy) > @@ -1,3 +1,7 @@ > +2018-09-20 Oliver Kellogg > + > + * exp_ch9.adb: Fix typo 'geenrated' t

Re: [PATCH][RFC] Fix PR63155 (some more)

On Wed, 19 Sep 2018, Steven Bosscher wrote: > On Wed, Sep 19, 2018 at 3:06 PM Richard Biener wrote: > > If we'd only had a O(log n) search sparse bitmap implementation ... > > (Steven posted patches to switch bitmap from/to such one but IIRC > > that at least lacked bitmap_first_set_bit). > > But