Re: [RFC,PATCH] Introduce -msdata=explicit for powerpc

On Aug 7, 2018, Segher Boessenkool wrote: > Hi! Hi! > On Tue, Aug 07, 2018 at 02:18:59AM -0300, Alexandre Oliva wrote: >> I saw comments, docs and init code that suggested the possibility of >> using r2/.sdata2 for small data, but I couldn't get code to be generated >> for such access, even

Re: [PATCH] Make strlen range computations more conservative

On 08/07/2018 11:44 AM, Richard Biener wrote: On August 7, 2018 4:37:00 PM GMT+02:00, Martin Sebor wrote: On 08/07/2018 02:51 AM, Richard Biener wrote: On August 7, 2018 4:24:42 AM GMT+02:00, Martin Sebor wrote: On 07/26/2018 02:55 AM, Richard Biener wrote: On Wed, 25 Jul 2018, Martin

Re: [PATCH, rs6000] Correct descriptions of __builtin_bcdadd* and _builtin_bcdsub* functions

Hi Kelvin, On Tue, Aug 07, 2018 at 05:42:48PM -0500, Kelvin Nilsen wrote: > > My "consistency" check was against the implementation. > > On 8/2/18 11:38 AM, Segher Boessenkool wrote: > > On Wed, Aug 01, 2018 at 02:55:22PM -0500, Kelvin Nilsen wrote: > >> Several errors were discovered in the

Re: [PATCH] convert braced initializers to strings (PR 71625)

On 08/07/2018 05:31 AM, Joseph Myers wrote: On Tue, 7 Aug 2018, Martin Sebor wrote: 2) skipping embedded nuls made it possible to create a string with fewer elements than the initializer array, which caused arrays with unspecified bound to be smaller than they would have been otherwise I

Re: [PATCH] convert braced initializers to strings (PR 71625)

On 08/07/2018 02:57 AM, Jason Merrill wrote: On Wed, Aug 1, 2018 at 12:49 AM, Martin Sebor wrote: On 07/31/2018 07:38 AM, Jason Merrill wrote: On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor wrote: The middle-end contains code to determine the lengths of constant character arrays

Re: [PATCH, rs6000] Early gimple folding of vec_mergeh and vec_mergel for float

Hi! On Tue, Aug 07, 2018 at 02:24:58PM -0500, Will Schmidt wrote: >This adds support for gimple folding of vec_mergeh and vec_mergel > for float and double types. Support for the integral types is already > in-tree. > + /* The permute_type will match the lhs for integral types. For

Re: [PATCH v2 01/10] Initial TI PRU GCC port

On 07/28/2018 07:44 AM, Dimitar Dimitrov wrote: ChangeLog: 2018-07-27 Dimitar Dimitrov * configure: Regenerate. * configure.ac: Add PRU target. gcc/ChangeLog: 2018-07-27 Dimitar Dimitrov * common/config/pru/pru-common.c: New file. * config.gcc: Add PRU

Re: [PATCH, rs6000] Correct descriptions of __builtin_bcdadd* and _builtin_bcdsub* functions

My "consistency" check was against the implementation. On 8/2/18 11:38 AM, Segher Boessenkool wrote: > Hi Kelvin, > > On Wed, Aug 01, 2018 at 02:55:22PM -0500, Kelvin Nilsen wrote: >> Several errors were discovered in the descriptions of the __builtin_bcdadd, >> __builtin_bcdadd_lt,

Re: PR libstdc++/68222 Hide safe iterator operators

On 07/08/18 14:47 +0100, Jonathan Wakely wrote: On 02/08/18 22:16 +0200, François Dumont wrote: Hi     Here is a patch to avoid definition of invalid operators on the Debug mode safe iterator type depending on its category.     Even if it is limited to the Debug mode code I would like to

Re: PR libstdc++/68222 Hide safe iterator operators

On 02/08/18 22:16 +0200, François Dumont wrote: +#if __cplusplus >= 201103L + /** @brief Copy assignment. */ + _Safe_tagged_iterator& + operator=(const _Safe_tagged_iterator&) = default; + + /** @brief Move assignment. */ + _Safe_tagged_iterator& +

[PATCH][OpenACC] Update deviceptr handling during gimplification

I had previously posted this patch as part of a monster deviceptr patch here . This patch breaks out the generic gimplifier changes. Essentially, with this patch, the gimplifier will now transfer deviceptr data clauses using

[PATCH][OpenACC] Don't error on implicitly private induction variables in gfortran

At present, the fortran FE reports an error if the user adds an explicit private clause to an induction variable used by an acc loop. This patch teaches the fortran acc block resolver how to cope with "duplicate" private clauses, so that it doesn't error anymore. Is this patch OK for trunk? I

[PATCH][OpenACC] Add support for firstprivate Fortran allocatable scalars

This patch updates the way that lower_omp_target uses firstprivate pointers in OpenACC offloaded regions. On host side, when preparing firstprivate data mapping for pointer type objects, not to be confused with GOMP_MAP_FIRSTPRIVATE_POINTER, the compiler passes passes the address of the value

Re: [PATCH, rs6000] testcases for GIMPLE folding of vec_splat builtin.

Hi! On Tue, Aug 07, 2018 at 02:25:06PM -0500, Will Schmidt wrote: > Some testcases to exercise the vec_splat() built-in. > In building and updating these tests I consciously violated the > 80 char per line rule, as I was doing experimentation with the > assorted values and making lots of local

[PATCH][OpenACC] update gfortran's tile clause error handling

This patch updates how the OpenACC tile clause is handled in the Fortran FE to match it's behavior in C/C++. Specifically, the tile clause now errors on negative integer arguments, instead of emitting a warning. Is this OK for trunk? Thanks, Cesar >From af39a6d65cfb46397fa62c88521189002fb3d705

[PATCH][OpenACC] cleanup trans-stmt.h

This patch removes a stale reference to trans-openacc.c in gcc/fortran/trans-statement.h. I'll apply it to trunk as obvious shortly. Cesar >From a08fe168c3f3ca4d446915ad26027786cda58394 Mon Sep 17 00:00:00 2001 From: Cesar Philippidis Date: Tue, 14 Mar 2017 22:33:00 + Subject: [PATCH]

Re: [PATCH] Line map table allocation

On 08/07/2018 03:43 PM, David Malcolm wrote: OK for trunk, with the nits noted above fixed. Committing this, thanks nathan -- Nathan Sidwell 2018-08-07 Nathan Sidwell * line-map.c: (linemap_init): Set default allocator here. (new_linemap): Rather than here. Refactor allocation logic.

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

That is a good question because I didn't know that such targets exists. Any suggestion? On Tue, Aug 7, 2018 at 5:29 PM, Paul Koning wrote: > > >> On Aug 7, 2018, at 4:00 PM, Giuliano Augusto Faulin Belinassi >> wrote: >> >> Related with bug 86829, but for hyperbolic trigonometric functions.

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

> On Aug 7, 2018, at 4:00 PM, Giuliano Augusto Faulin Belinassi > wrote: > > Related with bug 86829, but for hyperbolic trigonometric functions. > This patch adds substitution rules to both sinh(tanh(x)) -> x / sqrt(1 > - x*x) and cosh(tanh(x)) -> 1 / sqrt(1 - x*x). Notice that the both >

Re: [RFC][PATCH][mid-end] Optimize immediate choice in comparisons.

Hi Vlad, Thanks for the patch. Vlad Lazar writes: > Hi. > > This patch optimises the choice of immediates in integer comparisons. Integer > comparisons allow for different choices (e.g. a > b is equivalent to a >= b+1) > and there are cases where an incremented/decremented immediate can be

[PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

Related with bug 86829, but for hyperbolic trigonometric functions. This patch adds substitution rules to both sinh(tanh(x)) -> x / sqrt(1 - x*x) and cosh(tanh(x)) -> 1 / sqrt(1 - x*x). Notice that the both formulas has division by 0, but it causes no harm because 1/(+0) -> +infinity, thus the

Re: [PATCH, testsuite]: Fix g++.dg/torture/pr86763.C link failure for glibc < 2.17

Hi Andreas, > How about replacing clock_gettime with something else? It's not needed > for the particular test. that would certainly be useful: Solaris 10 also needs librt or clock_gettime, while Solaris 11 has folded it into libc. Rainer --

Re: [PATCH] Line map table allocation

On Mon, 2018-08-06 at 12:58 -0400, Nathan Sidwell wrote: > Here's a line-map patch to make the new_linemap logic simpler. On > the > modules branch I need to allocate blocks of linemaps, and found the > current allocation scheme a little confusing to adjust. This'll > make > that subsequent

[PATCH, rs6000] testcases for GIMPLE folding of vec_splat builtin.

Hi, Some testcases to exercise the vec_splat() built-in. Tested successfully on assorted powerpc Linux systems, in conjunction with the vec-splat() folding patch, which is being posted separately. In building and updating these tests I consciously violated the 80 char per line rule, as

[PATCH, rs6000] Early gimple folding of vec_mergeh and vec_mergel for float

Hi, This adds support for gimple folding of vec_mergeh and vec_mergel for float and double types. Support for the integral types is already in-tree. This change includes updates to the fold_mergehl_helper function to handle creating the (integral) permute vector when the vector type non

[PATCH, RFC, rs6000] enable GIMPLE folding of vec_splat

Hi Enable GIMPLE folding of the vec_splat() intrinsic. For review.. feedback is expected. :-) I came up with the following after spending some time poking around at the tree_vec_extract() and vector_element() functions as seen in tree-vect-generic.c looking for insights. Some of this

Re: [PATCH] fix std::variant::swap for trivially-move-assignable types

On 07/08/18 17:57 +0300, Ville Voutilainen wrote: On 7 August 2018 at 17:29, Jonathan Wakely wrote: On 07/08/18 15:24 +0100, Jonathan Wakely wrote: This patch fixes the bug, but is it correct? IIUC the _M_destructive_move effects don't depend on whether move assignment is trivial, so should

Re: [PATCH] Make strlen range computations more conservative

On August 7, 2018 6:31:36 PM GMT+02:00, Martin Sebor wrote: >On 08/07/2018 09:33 AM, Bernd Edlinger wrote: >> On 08/07/18 17:02, Martin Sebor wrote: >>> On 08/06/2018 11:45 PM, Richard Biener wrote: On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor > wrote: > On 08/06/2018 11:40 AM,

Re: [PATCH] Make strlen range computations more conservative

On August 7, 2018 4:37:00 PM GMT+02:00, Martin Sebor wrote: >On 08/07/2018 02:51 AM, Richard Biener wrote: >> On August 7, 2018 4:24:42 AM GMT+02:00, Martin Sebor > wrote: >>> On 07/26/2018 02:55 AM, Richard Biener wrote: On Wed, 25 Jul 2018, Martin Sebor wrote: >> BUT - for the

Re: [Patch][Aarch64] Implement Aarch64 SIMD ABI and aarch64_vector_pcs attribute

Hi! Some very trivial comments... On Mon, Aug 06, 2018 at 03:13:52PM -0700, Steve Ellcey wrote: > (aarch64_components_for_bb): Check for simd function. > (aarch64_epilogue_uses): New function. > (aarch64_process_components): Ditto. > (aarch64_expand_prologue): Ditto. >

Re: [PING 3][PATCH] [v4][aarch64] Avoid tag collisions for loads falkor

On 08/07/2018 10:30 PM, James Greenhalgh wrote: To help set expectations here. I'm currently only able to dedicate a couple of hours of time to review each week. Tamar's Stack Clash has been taking a big chunk of that time recently as we push it to a final state for trunk. This pass is... large

libgo patch committed: Uncomment trace.Stop call in testing package

This patch by Than McIntosh uncomments the call to trace.Stop in the testing package. It was commented out when the runtime/trace package did not build with gccgo, but now it does and has for some time. The fixes the go test -test.trace option. Bootstrapped and ran Go testsuite on

Re: [PATCH] [Ada] Make middle-end string literals NUL terminated

On 08/07/18 18:40, Olivier Hainque wrote: > Hi Bernd, > > (Thanks for your interest in the Ada case as well :) > >> On 7 Aug 2018, at 15:07, Bernd Edlinger wrote: > >> When I try this example: >> >> $ cat array9.adb >> -- { dg-do run } >> >> procedure Array9 is >> >>V1 : String(1..10) :=

Re: [PATCH][Middle-end] disable strcmp/strncmp inlining with O2 below and Os

Hi, Christophe, I have attached a patch in PR86519, could you please download it and test it, and let me know the result. thanks. Qing > On Jul 30, 2018, at 8:45 AM, Christophe Lyon > wrote: > > On Wed, 25 Jul 2018 at 19:08, Qing Zhao > wrote: >> >> Hi, >> >>

Re: [PING 3][PATCH] [v4][aarch64] Avoid tag collisions for loads falkor

On Tue, Aug 07, 2018 at 03:01:28AM -0500, Siddhesh Poyarekar wrote: > Hello, > > Ping! To help set expectations here. I'm currently only able to dedicate a couple of hours of time to review each week. Tamar's Stack Clash has been taking a big chunk of that time recently as we push it to a final

Re: [PATCH] [aarch64][v2] Fix falkor pipeline description for dup

On Thu, Aug 02, 2018 at 09:02:05PM -0500, Siddhesh Poyarekar wrote: > On 08/03/2018 12:02 AM, James Greenhalgh wrote: > > On Thu, Aug 02, 2018 at 11:58:37AM -0500, Siddhesh Poyarekar wrote: > >> There was a typo in the pipeline description where DUP was assigned to > >> the vector pipes for quad

Re: [PATCH] [Ada] Make middle-end string literals NUL terminated

Hi Bernd, (Thanks for your interest in the Ada case as well :) > On 7 Aug 2018, at 15:07, Bernd Edlinger wrote: > When I try this example: > > $ cat array9.adb > -- { dg-do run } > > procedure Array9 is > > V1 : String(1..10) := "1234567890"; > V2 : String(1..-1) := ""; > > procedure

Re: dejagnu version update?

On Mon, Aug 06, 2018 at 08:25:49AM -0700, Mike Stump wrote: > Since g++ already requires 1.5.3, it make no sense to bump to anything older > that 1.5.3, so let's bump to 1.5.3. Those packaging systems and OSes that > wanted to update by now, have had their chance to update. Those that punt >

Re: [PATCH] Make strlen range computations more conservative

On 08/07/2018 09:33 AM, Bernd Edlinger wrote: On 08/07/18 17:02, Martin Sebor wrote: On 08/06/2018 11:45 PM, Richard Biener wrote: On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor wrote: On 08/06/2018 11:40 AM, Jeff Law wrote: On 08/06/2018 11:15 AM, Martin Sebor wrote: These examples

Re: [PATCH][GCC][AArch64] Validate and set default parameters for stack-clash. [Patch (3/3)]

On Tue, Aug 07, 2018 at 05:09:30AM -0500, Tamar Christina wrote: > Hi All, > > This is an updated patch which applies the same style changes as requested in > patch 5/6. No full stop on an error message IIRC. Otherwise, OK. Thanks, James > gcc/ > 2018-08-07 Tamar Christina > > *

Re: [PATCH][GCC][AArch64] Ensure that outgoing argument size is at least 8 bytes when alloca and stack-clash. [Patch (3/6)]

On Tue, Aug 07, 2018 at 05:09:34AM -0500, Tamar Christina wrote: > Hi All, > > This is a re-spin to address review comments. No code change aside from a > variable rename. > > Ok for trunk? OK. Thanks, James > gcc/ > 2018-08-07 Tamar Christina > > PR target/86486 > *

[PATCH] PR libstdc++/86861 Meet precondition for Solaris memalign

Solaris memalign requires alignment to be at least sizeof(int), so increase it as needed. Also move the check for valid alignments from the fallback implementation of aligned_alloc into operator new, as it's required for all of aligned_alloc, memalign, posix_memalign and __aligned_malloc. This

Re: [Patch][Aarch64] Implement Aarch64 SIMD ABI and aarch64_vector_pcs attribute

I have a question about my own patch.  In doing testing I realized that if I use the aarch64_vector_pcs attribute on a platform without SIMD (i.e. -march=armv8.1-a+nosimd) I get an ICE.  That is obviously not what we want but I was wondering what the right behaviour is. We certainly don't want to

Re: [PATCH] Make strlen range computations more conservative

On 08/06/2018 05:59 PM, Martin Sebor wrote: >>> But as I said, far more essential than the optimization is >>> the ability to detect these invalid access (both reads and >>> writes), such as in: >> >> The essential thing is to not introduce latent wrong code issues >> because you exploit C

Re: [PATCH][GCC][AARCH64] Use STLUR for atomic_store

Hello everyone, This is an updated patch where I've made what was a predicate into a pure C function based on some feedback outside the mailing list. Ok for trunk? Matthew gcc/ 2018-08-07  Matthew Malcomson      * config/aarch64/aarch64-protos.h    

Re: [PATCH] Make strlen range computations more conservative

On 08/07/18 17:02, Martin Sebor wrote: > On 08/06/2018 11:45 PM, Richard Biener wrote: >> On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor >> wrote: >>> On 08/06/2018 11:40 AM, Jeff Law wrote: On 08/06/2018 11:15 AM, Martin Sebor wrote: >>> These examples do not aim to be valid C,

Re: [PATCH] Make strlen range computations more conservative

On 08/06/2018 09:38 PM, Martin Sebor wrote: > On 08/06/2018 11:40 AM, Jeff Law wrote: >> On 08/06/2018 11:15 AM, Martin Sebor wrote: > These examples do not aim to be valid C, they just point out > limitations > of the middle-end design, and a good deal of the problems are due > to

Re: [AArch64] Fix -mlow-precision-div (PR 86838)

On Fri, Aug 03, 2018 at 10:34:37AM -0500, Richard Sandiford wrote: > The "@" handling broke -mlow-precision-div, because the scalar forms of > the instruction were provided by a pattern that also provided FRECPX > (and so were parameterised on an unspec code as well as a mode), > while the SIMD

Re: [PATCH] Make strlen range computations more conservative

On 08/06/2018 11:45 PM, Richard Biener wrote: On August 7, 2018 5:38:59 AM GMT+02:00, Martin Sebor wrote: On 08/06/2018 11:40 AM, Jeff Law wrote: On 08/06/2018 11:15 AM, Martin Sebor wrote: These examples do not aim to be valid C, they just point out limitations of the middle-end design,

Re: [PATCH] fix std::variant::swap for trivially-move-assignable types

On 7 August 2018 at 17:29, Jonathan Wakely wrote: > On 07/08/18 15:24 +0100, Jonathan Wakely wrote: >> >> This patch fixes the bug, but is it correct? >> >> IIUC the _M_destructive_move effects don't depend on whether move >> assignment is trivial, so should be defined the same way in both >>

Re: [PATCH 00/11] (v2) Mitigation against unsafe data speculation (CVE-2017-5753)

On 2018-08-07 10:05 AM, Richard Earnshaw (lists) wrote: Thanks. Wrong PR, though: that was for the SPU port. The hppa PR is 86785. Oops, sorry for extra work. Dave -- John David Anglin dave.ang...@bell.net

Re: [PATCH] Make strlen range computations more conservative

On 08/07/2018 02:51 AM, Richard Biener wrote: On August 7, 2018 4:24:42 AM GMT+02:00, Martin Sebor wrote: On 07/26/2018 02:55 AM, Richard Biener wrote: On Wed, 25 Jul 2018, Martin Sebor wrote: BUT - for the string_constant and c_strlen functions we are, in all cases we return something

Fix PR number in hppa commit for CVE-2017-5753)

This just fixes the PR number in the ChangeLog. Nothing we can do about the SVN history. gcc/ChangeLog Committed as obvious. Index: ChangeLog === --- ChangeLog (revision 263357) +++ ChangeLog (working copy) @@ -9,7 +9,7 @@

Re: [PATCH] fix std::variant::swap for trivially-move-assignable types

On 07/08/18 15:24 +0100, Jonathan Wakely wrote: This patch fixes the bug, but is it correct? IIUC the _M_destructive_move effects don't depend on whether move assignment is trivial, so should be defined the same way in both specializations. It also looks like we can use it in the non-trivial

[PATCH] fix std::variant::swap for trivially-move-assignable types

This patch fixes the bug, but is it correct? IIUC the _M_destructive_move effects don't depend on whether move assignment is trivial, so should be defined the same way in both specializations. It also looks like we can use it in the non-trivial move assignment. Should we define

Re: Improve std::rotate usages

On 27/05/18 19:25 +0200, François Dumont wrote: Still no chance to review it ? I'd like this one to go in before submitting other algo related patches.     * include/bits/stl_algo.h     (__rotate(_Ite, _Ite, _Ite, forward_iterator_tag))     (__rotate(_Ite, _Ite, _Ite,

Re: [PATCH 00/11] (v2) Mitigation against unsafe data speculation (CVE-2017-5753)

On 06/08/18 22:52, John David Anglin wrote: > On 2018-08-03 5:06 AM, Richard Earnshaw (lists) wrote: >>> I don't think there's a suitable barrier.  The sync instruction seems >>> like overkill. >>> >>> So, I'm going to install attached change after testing is complete. >>> >> It's your call as

Re: [PATCH,nvptx] Use CUDA driver API to select default runtime launch, geometry

On 08/06/2018 11:08 PM, Tom de Vries wrote: > On 08/01/2018 12:18 PM, Tom de Vries wrote: > >> I think we need to add and handle: >> ... >> CUDA_ONE_CALL_MAYBE_NULL (cuOccupancyMaxPotentialBlockSize) >> ... >> > > I realized that the patch I posted introducing CUDA_ONE_CALL_MAYBE_NULL > was

Re: PR libstdc++/68222 Hide safe iterator operators

On 02/08/18 22:16 +0200, François Dumont wrote: Hi     Here is a patch to avoid definition of invalid operators on the Debug mode safe iterator type depending on its category.     Even if it is limited to the Debug mode code I would like to have a feedback before committing. Especially on

[RFC][PATCH][mid-end] Optimize immediate choice in comparisons.

Hi. This patch optimises the choice of immediates in integer comparisons. Integer comparisons allow for different choices (e.g. a > b is equivalent to a >= b+1) and there are cases where an incremented/decremented immediate can be loaded into a register in fewer instructions. The cases are as

Re: [PATCH] [Ada] Make middle-end string literals NUL terminated

Hi Olivier, On 08/06/18 20:01, Olivier Hainque wrote: > Hi Bernd, > > Things are moving fast so I'll answer your > messages incrementally :-) > >> On 3 Aug 2018, at 20:37, Bernd Edlinger wrote: > [...] >> Oh, how interesting. >> >> My patch only intends to add a dummy byte that is stripped

Re: [PATCH] Handle not explicitly zero terminated strings in merge sections

Hi, I realized that the previous version did not handle zero terminated Ada constants correctly as in $ cat hello.adb procedure Hello is procedure puts (S : String) with Import, Convention => C; X : String(1..8) := "abcdefg" & Ascii.Nul; begin puts ("1234" & Ascii.Nul ); puts (X);

Re: [PATCH] Introduce __builtin_expect_with_probability (PR target/83610).

> 2018-07-24 Martin Liska > > PR target/83610 > * builtin-types.def (BT_FN_LONG_LONG_LONG_DOUBLE): New type. > * builtins.c (expand_builtin_expect_with_probability): > New function. > (expand_builtin): Handle also BUILT_IN_EXPECT_WITH_PROBABILITY. >

Re: [PATCH] Add malloc predictor (PR middle-end/83023).

On 08/07/2018 01:51 PM, Jan Hubicka wrote: >> >> 2018-07-26 Martin Liska >> >> PR middle-end/83023 >> * predict.c (expr_expected_value_1): Handle DECL_IS_MALLOC, >> BUILT_IN_REALLOC and DECL_IS_OPERATOR_NEW. >> * predict.def (PRED_MALLOC_NONNULL): New predictor. > >

Re: [C++ PATCH] PR c++/79133

On 7 August 2018 at 14:50, Jason Merrill wrote: > OK. Trunk only, no backports, presumably. I asked about backports in the second-to-last submission, but I am gravitating away from backporting this, it's a non-regression that's dealing with a fairly recent change, so I'm going to operate with a

Re: [PATCH] Add malloc predictor (PR middle-end/83023).

> > 2018-07-26 Martin Liska > > PR middle-end/83023 > * predict.c (expr_expected_value_1): Handle DECL_IS_MALLOC, > BUILT_IN_REALLOC and DECL_IS_OPERATOR_NEW. > * predict.def (PRED_MALLOC_NONNULL): New predictor. Patch is OK. I am still somewhat worried that we

Re: [C++ PATCH] PR c++/79133

OK. On Tue, Aug 7, 2018 at 8:43 PM, Ville Voutilainen wrote: > On 7 August 2018 at 13:12, Jason Merrill wrote: >> Maybe put this block first rather than add !is_capture_proxy to the if >> condition? > > Thus?

Re: [C++ Patch] PR 59480 ("Missing error diagnostic: friend declaration specifying a default argument must be a definition")​ (Take 2)

OK. On Wed, Aug 1, 2018 at 8:38 PM, Paolo Carlini wrote: > Hi, > > thus, as you may or may not have noticed I reverted my first try, when > Tobias noticed that in his large codebase we were rejecting code like: > > class Matrix; > > Matrix rot90 (const Matrix& a, int k = 1); > > class Matrix {

[PATCH] PR86844: Fix for store merging

From: Andreas Krebbel Bootstrapped and regtested on s390x and x86_64. gcc/ChangeLog: 2018-08-07 Andreas Krebbel PR tree-optimization/86844 * gimple-ssa-store-merging.c (check_no_overlap): Add a check to reject overlaps if it has seen a non-constant store in between.

[PATCH] Define monotonic_buffer_resource members out-of-line

Move the allocation logic into libstdc++.so so that it can be changed without worrying about inlined code in existing binaries. Leave do_allocate inline so that calls to it can be devirtualized, and only the slow path needs to call into the library. * config/abi/pre/gnu.ver: Export

Re: [PATCH] convert braced initializers to strings (PR 71625)

On Tue, 7 Aug 2018, Martin Sebor wrote: > 2) skipping embedded nuls made it possible to create a string > with fewer elements than the initializer array, which caused > arrays with unspecified bound to be smaller than they would > have been otherwise I think there should be explicit tests of

Re: [RFC,PATCH] Introduce -msdata=explicit for powerpc

Hi! On Tue, Aug 07, 2018 at 02:18:59AM -0300, Alexandre Oliva wrote: > This option allows users to manually select what goes in the limited > small data range, and still get smaller and faster small data access > sequences for the selected data. > We've considered adding a new attribute, say

Re: [C++ PATCH] PR c++/79133

On 7 August 2018 at 13:12, Jason Merrill wrote: > Maybe put this block first rather than add !is_capture_proxy to the if > condition? Thus? diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c index 3aafb0f..0faf739 100644 --- a/gcc/cp/name-lookup.c +++ b/gcc/cp/name-lookup.c @@ -2640,13

Re: [C++ PATCH] PR c++/79133

On 08/07/2018 07:12 AM, Ville Voutilainen wrote: On 8 July 2018 at 02:08, Ville Voutilainen wrote: On 8 July 2018 at 01:54, Paolo Carlini wrote: That would make this more consistent with such a shadow warning, but I don't want to use the shadowing wording (which would be easy to do; just set

RE: [PATCH][GCC][AArch64] Updated stack-clash implementation supporting 64k probes. [patch (1/6)]

Hi All, This is a re-spin of the patch to address review comments. It mostly just adds more comments and corrects typos. Ok for trunk? Thanks, Tamar gcc/ 2018-08-07 Jeff Law Richard Sandiford Tamar Christina PR target/86486 *

RE: [PATCH][GCC][AArch64] Ensure that outgoing argument size is at least 8 bytes when alloca and stack-clash. [Patch (3/6)]

Hi All, This is a re-spin to address review comments. No code change aside from a variable rename. Ok for trunk? Thanks, Tamar gcc/ 2018-08-07 Tamar Christina PR target/86486 * config/aarch64/aarch64.h (STACK_CLASH_MIN_BYTES_OUTGOING_ARGS, STACK_DYNAMIC_OFFSET):

RE: [PATCH][GCC][AArch64] Validate and set default parameters for stack-clash. [Patch (3/3)]

Hi All, This is an updated patch which applies the same style changes as requested in patch 5/6. Ok for trunk? Thanks, Tamar gcc/ 2018-08-07 Tamar Christina * common/config/aarch64/aarch64-common.c (TARGET_OPTION_DEFAULT_PARAM, aarch64_option_default_param): New.

Re: [PATCH] convert braced initializers to strings (PR 71625)

On Wed, Aug 1, 2018 at 12:49 AM, Martin Sebor wrote: > On 07/31/2018 07:38 AM, Jason Merrill wrote: >> >> On Tue, Jul 31, 2018 at 9:51 AM, Martin Sebor wrote: >>> >>> The middle-end contains code to determine the lengths of constant >>> character arrays initialized by string literals. The code

Re: [PATCH] Make strlen range computations more conservative

On August 7, 2018 4:24:42 AM GMT+02:00, Martin Sebor wrote: >On 07/26/2018 02:55 AM, Richard Biener wrote: >> On Wed, 25 Jul 2018, Martin Sebor wrote: >> BUT - for the string_constant and c_strlen functions we are, in all cases we return something interesting, able to look at an

[PATCH 2/2] S/390: Remove TARGET_CPU_ZARCH

TARGET_CPU_ZARCH allowed to distinguish between g5/g6 and newer machines. Since the former are now gone, we can assume that TARGET_CPU_ZARCH is always true. As a side-effect, branch splitting is now completely gone. Some parts of literal pool splitting are also gone, but it's still there: we

[PATCH 1/2] S/390: Remove support for g5 and g6 machines

g5 and g6 were deprecated since gcc 6.1.0 (commit 3bd8520f). gcc/ChangeLog: 2018-08-02 Ilya Leoshkevich * common/config/s390/s390-common.c (processor_flags_table): Remove flags. * config.gcc: Remove with_arch/with_tune support. * config/s390/2064.md: Remove

[PATCH 0/2] S/390: Remove deprecated machines

Remove g5 and g6 machines as well as the corresponding lower-level features.

[PING 3][PATCH] [v4][aarch64] Avoid tag collisions for loads falkor

Hello, Ping! Siddhesh On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote: Hi, This is a rewrite of the tag collision avoidance patch that Kugan had written as a machine reorg pass back in February. The falkor hardware prefetching system uses a combination of the source, destination and offset

Re: [Patch, avr, PR85624] - Fix ICE when initializing 128-byte aligned array

Jeff Law writes: > On 08/06/2018 04:53 AM, Senthil Kumar Selvaraj wrote: >> Ping! >> >> Regards >> Senthil >> >> Senthil Kumar Selvaraj writes: >> >>> Hi, >>> >>> The below patch fixes an ICE for the avr target when the setmemhi >>> expander is involved. >>> >>> The setmemhi expander

Re: [PATCH,nvptx] Use CUDA driver API to select default runtime launch, geometry

On 08/01/2018 12:18 PM, Tom de Vries wrote: > I think we need to add and handle: > ... > CUDA_ONE_CALL_MAYBE_NULL (cuOccupancyMaxPotentialBlockSize) > ... > I realized that the patch I posted introducing CUDA_ONE_CALL_MAYBE_NULL was incomplete, and needed to use the weak attribute in case of