Re: [PATCH] c++/60760 - arithmetic on null pointers should not be allowed in constant expressions

Hi! On Wed, 6 Jul 2016 16:20:44 -0600, Martin Sebor wrote: > PR c++/60760 - arithmetic on null pointers should not be allowed in constant > expressions > PR c++/71091 - constexpr reference bound to a null pointer dereference >accepted > > [...] > * g++.dg/cpp0x/constexpr-cast.C: New

Re: Create multiple directory through fixinc.in script.

Hi Jeff, On 01/08/2016 21:07, Jeff Law wrote: On 08/01/2016 08:55 AM, mbilal wrote: Hi, This patch fixes the mkheaders directory creation. It failed to create the multiple multilib directory on some cases. e.g For i686-pc-linux-gnu target config, I have following 'fixinc_list' for multilibs.

Re: [patch,avr] PR70677: Use -fno-caller-saves for avr

Denis Chertykov writes: > 2016-08-01 15:17 GMT+03:00 Georg-Johann Lay : >> Problem with -fcaller-saves is that there are situations where it triggers >> an expensive frame just to store a variable around a function call even >> though there are plenty of call-saved registers. >> >> Example: >> >>

[PR55641] drop spurious const_type from reference_type variables

Although C++ reference types, denoted by DW_TAG_reference_type in DWARFv2+ debug info, are unchangeable, we output names of reference type with DW_TAG_const_type, because internally we mark such variables as TREE_READONLY. That's an internal implementation detail that shouldn't leak to debug infor

[PR63240] generate debug info for defaulted member functions

This implements , a proposal already accepted for inclusion in DWARF-5, but using DW_AT_GNU_defaulted instead of DW_AT_defaulted as the attribute name, because the attribute id for DW_AT_defaulted is not yet publicly available. Regstrapped on x86_6

Re: [PR49366] emit loc exprs for C++ non-virtual pmf template value parms

On Jul 23, 2016, Alexandre Oliva wrote: > We used to emit, in debug information, the values bound to pointer to > member function template parameters only when they were NULL or > virtual member functions, because those can be represented with > DW_AT_const_value. > In order to represent the sym

Re: [PATCH build/doc] Replacing libiberty with gnulib

On 29 July 2016 at 17:55, Manuel López-Ibáñez wrote: > On 29 July 2016 at 17:51, Joseph Myers wrote: >> On Wed, 20 Jul 2016, Manuel López-Ibáñez wrote: >> >>> On 20 July 2016 at 19:21, ayush goel wrote: >>> > Hey, >>> > As a first step of my GSOC project >>> > (https://gcc.gnu.org/wiki/replaceli

Re: [PATCH] Fix wrong code on aarch64 due to paradoxical subreg

Hi, On Mon, Aug 01, 2016 at 06:52:54PM +, Bernd Edlinger wrote: > On 08/01/16 19:54, Jeff Law wrote: > > Looks like you've probably nailed it. It'll be interesting see if > > there's any fallout (though our RTL optimizer testing is pretty weak, so > > even if there were, I doubt we'd catch it

Re: [PATCH, 4 of 4], Enhance PowerPC vec_extract support for power8/power9 machines

On Mon, Aug 01, 2016 at 06:37:42PM -0400, Michael Meissner wrote: > One further optimization would be to add support for constant element extracts > if the vector is currently in GPRs rather than vector registers on 64-bit > systems. I'm not sure if it would be a win in general, or if it would cau

Re: [PATCH, 4 of 4], Enhance PowerPC vec_extract support for power8/power9 machines

This is the 4th path to enhance vec_extract on 64-bit power8/power9 machines. This patch uses the load from memory support and the variable elment patch that were part of the previous patches for vector long/vector double, and adds the same support for vector float, vector int, vector short, and v

Re: [PATCH 1/3] (v2) On-demand locations within string-literals

On Thu, 28 Jul 2016, Martin Sebor wrote: > like it as well. So perhaps the problem to solve is how to teach > LTO to talk to the front end. One way to do it would be to build > the front ends as shared libraries. I think building front ends as shared libraries would run into different platform

Re: [PATCH,rs6000] Add built-in function support Power9 binary floating point operations

Hi Kelvin, On Fri, Jul 29, 2016 at 09:47:55AM -0600, Kelvin Nilsen wrote: > This patch adds built-in support for the following fourteen new binary > floating point instructions introduced with the Power9 architecture: Some comments, mostly about whitespace: > --- gcc/doc/extend.texi (revi

Re: [PATCH] nvptx: do not implicitly enable -ftoplevel-reorder

On 08/01/2016 10:44 PM, Joseph Myers wrote: On Fri, 22 Jul 2016, Bernd Schmidt wrote: What's the motivation for supporting -fno-toplevel-reorder anyway? That's practically just a legacy mode as far as I know. It's for code that uses toplevel asms in ways for which it matters where they appear

Re: [PATCH] nvptx: do not implicitly enable -ftoplevel-reorder

On Fri, 22 Jul 2016, Bernd Schmidt wrote: > What's the motivation for supporting -fno-toplevel-reorder anyway? That's > practically just a legacy mode as far as I know. It's for code that uses toplevel asms in ways for which it matters where they appear in relation to functions in the .s file, o

Re: RFA: new pass to warn on questionable uses of alloca() and VLAs

On Tue, 19 Jul 2016, Aldy Hernandez wrote: > + // Do not warn on VLAs occurring in a loop, since VLAs are > + // guaranteed to be cleaned up when they go out of scope. > + // That is, there is a corresponding __builtin_stack_restore > + // at the end of the scope in which the V

C++ PATCHes to tweak -Wabi mangling warning

The first patch fixes the warning about mangled name changes for some current testcases to associate a mangled name with the right ABI version; they had been swapped around. The second patch changes that warning to be given when mangling external references, not just when mangling a definition. T

[PATCH] Add non-const std::basic_string::data() for C++17

This is a minimal version of the change I reverted recently. This adds the non-const data() overload, without supporting fancy pointers for allocator_type::pointer and without needing to export the new function (because we suppress the explicit instantiation declarations for C++17 now). *

Re: [PATCH] Fix wrong code on aarch64 due to paradoxical subreg

Hi Jeff, On 08/01/16 19:54, Jeff Law wrote: > Looks like you've probably nailed it. It'll be interesting see if > there's any fallout (though our RTL optimizer testing is pretty weak, so > even if there were, I doubt we'd catch it). > If there is, it will probably a performance regression... An

Re: [patch,avr] PR70677: Use -fno-caller-saves for avr

2016-08-01 15:17 GMT+03:00 Georg-Johann Lay : > Problem with -fcaller-saves is that there are situations where it triggers > an expensive frame just to store a variable around a function call even > though there are plenty of call-saved registers. > > Example: > > typedef __UINT8_TYPE__ uint8_t; >

Re: [PATCH] Fix wrong code on aarch64 due to paradoxical subreg

On 07/31/2016 04:44 AM, Bernd Edlinger wrote: like this? Index: emit-rtl.c === --- emit-rtl.c (revision 238891) +++ emit-rtl.c (working copy) @@ -1156,7 +1156,11 @@ { #if defined(POINTERS_EXTEND_UNSIGNED) if (((GE

Re: [PATCH] Fix wrong code on aarch64 due to paradoxical subreg

On 07/30/2016 02:17 AM, Bernd Edlinger wrote: In your first mail you showed reg 481 as _not_ being REG_POINTER: (insn 1047 1046 1048 (set (reg:DI 481) (subreg:DI (reg/f:SI 479) 0)) y.c:12702 -1 (nil)) (note the lack of /f). So which is it? REG_POINTER here is not correct as fa

Re: [PATCH 2/4] BRIG (HSAIL) frontend: The FE itself.

Hi, On Mon, May 16, 2016 at 08:25:57PM +0300, Pekka Jääskeläinen wrote: > The BRIG frontend itself. thanks making the effort to submit patches against trunk. I would be very glad to see this included in the upcoming gcc version, not least because it would make it easy to do basic testing of the

Re: [patch] Some testsuite cleanup

On 01/08/16 09:23 -0700, Mike Stump wrote: On Jul 31, 2016, at 1:30 PM, Jonathan Wakely wrote: -fno-show-column is a good general option. If you guys want to add column number test cases, they can avoid it, and test down to the column. Most people don't care, and most test aren't interes

Re: [patch] Some testsuite cleanup

On Jul 31, 2016, at 1:30 PM, Jonathan Wakely wrote: > > -fno-show-column is a good general option. If you guys want to add column number test cases, they can avoid it, and test down to the column. Most people don't care, and most test aren't interested in column testing anyway. But, if you

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

On 08/01/2016 03:09 AM, Ilya Enkovich wrote: 2016-07-26 18:38 GMT+03:00 Ilya Enkovich : 2016-07-26 18:26 GMT+03:00 Jeff Law : On 07/26/2016 03:57 AM, Ilya Enkovich wrote: Ilya, what's the fundamental reason why we need to run if-conversion again? Yes, I know you want to if-convert the epilog

Re: [PATCH][RFC] PR middle-end/22141 GIMPLE store widening pass

On 08/01/2016 03:15 AM, Kyrill Tkachov wrote: On 18/07/16 13:22, Richard Biener wrote: On Fri, Jul 15, 2016 at 5:13 PM, Kyrill Tkachov wrote: Hi all, This is a GIMPLE pass to implement PR middle-end/22141. that is merge narrow stores of constants into fewer wider stores. A 2009 patch from J

Re: Create multiple directory through fixinc.in script.

On 08/01/2016 08:55 AM, mbilal wrote: Hi, This patch fixes the mkheaders directory creation. It failed to create the multiple multilib directory on some cases. e.g For i686-pc-linux-gnu target config, I have following 'fixinc_list' for multilibs. /system32; /system64;/64 /sgxx-glibc;/sgxx-glibc

[PATCH] Disable std::string and std::wstring extern templates for C++17

As I mentioned last week, the explicit instantiation definitions for std::string and std::wstring are compiled as C++11, so do not instantiate the new member functions added for C++17. Rather than change what we instantiate and export from the library I'd prefer to suppress the explicit instantia

Repeated use of the OpenACC routine directive

Hi! We found that it's not correct that we currently unconditionally diagnose an error for repeated use of the OpenACC routine directive on one function/declaration. (For reference, it is also permissible for an "ordinary" function to have several declarations plus a definition, as long as these

Use verify_oacc_routine_clauses for Fortran (was: Use verify_oacc_routine_clauses for C/C++)

Hi! On Mon, 01 Aug 2016 17:21:37 +0200, I wrote: > Some checking of OpenACC clauses currently done in the front ends should > be moved later, and be unified. (Also, I suppose, for supporting of the > device_type clause, such checking actually *must* be moved later, into > the oaccdevlow pass, or

Use verify_oacc_routine_clauses for C/C++

Hi! Some checking of OpenACC clauses currently done in the front ends should be moved later, and be unified. (Also, I suppose, for supporting of the device_type clause, such checking actually *must* be moved later, into the oaccdevlow pass, or similar.) Here is a first preparatory patch. OK for

C++ PATCH for c++/72766 (ICE with VLA)

cxx_eval_pointer_plus_expression was assuming that array_type_nelts_top would be a constant expression, which it might not be. Tested x86_64-pc-linux-gnu, applying to trunk. commit b9f0335823eff3e6d6f562268cb36c05b41790ab Author: Jason Merrill Date: Mon Aug 1 10:28:50 2016 -0400 PR c++

Create multiple directory through fixinc.in script.

Hi, This patch fixes the mkheaders directory creation. It failed to create the multiple multilib directory on some cases. e.g For i686-pc-linux-gnu target config, I have following 'fixinc_list' for multilibs. /system32; /system64;/64 /sgxx-glibc;/sgxx-glibc /sgxx-glibc;/64/sgxx-glibc /sgxx-g

Re: [PATCH][expr.c] PR middle-end/71700: zero-extend sub-word value when widening constructor element

On 11/07/16 18:55, Bernd Schmidt wrote: On 07/11/2016 04:52 PM, Kyrill Tkachov wrote: Based on that, I think that code block is a useful optimisation, we just need to take care with immediates. What do you think? Yeah, I think the patch is ok. This patch (https://gcc.gnu.org/ml/gcc-patche

Re: PATCH: PR71818: Don't advance IVs with a variable step

On 01/08/2016 14:49, "Richard Biener" wrote: >On Mon, Aug 1, 2016 at 11:24 AM, Alan Hayward >wrote: >> In the given test case, the loop is split into vectorised and non >> vectorised >> versions due to peeling. At the end of the loop the IVs are incremented >>to >> their latest value. This is

Re: [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])

On Sun, Jul 31, 2016 at 4:27 PM, Martin Sebor wrote: > On 07/31/2016 10:28 AM, Jason Merrill wrote: >> On Fri, Jul 29, 2016 at 7:22 PM, Martin Sebor wrote: >>> On 07/26/2016 12:53 PM, Jason Merrill wrote: On 07/23/2016 01:18 PM, Martin Sebor wrote: > > + /* A pair of the first non-s

[PATCH] Remove ignored "xfail" from dg-do compile directives

As documented at https://gcc.gnu.org/onlinedocs/gccint/Directives.html an "xfail" is ignored for dg-do what unless what==run. This removes five such ignored uses of xfail in the dg-do directive. These tests are already expected to XFAIL because of the dg-excess-errors directives (with optional ta

Re: [PATCH][AArch64] Optimize prolog/epilog

On 29/07/16 12:49, Wilco Dijkstra wrote: > This patch optimizes the prolog and epilog code to reduce the number of > instructions and avoid multiple writes to SP. The key idea is that epilogs > are almost exact reverses of prologs, and thus all the decisions only need > to be taken once. The fram

Re: PATCH: PR71818: Don't advance IVs with a variable step

On Mon, Aug 1, 2016 at 11:24 AM, Alan Hayward wrote: > In the given test case, the loop is split into vectorised and non > vectorised > versions due to peeling. At the end of the loop the IVs are incremented to > their latest value. This is achieved by taking the base of the loop (g_21) > and > ad

Re: [PATCH 1/4] Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch

On 08/01/2016 02:22 PM, Nathan Sidwell wrote: > As I just wrote, this patch needs work. the general points are: Thank for the comments. > 1) exposing integers 0-3 to the user as switch values. Don't do that, give > them names. In this case a comma separated list of orthogonal names seems >

[PATCH AArch64][V3]Rewrite vcond patterns using vcond_mask/vec_cmp, also support missing vect_cond_mixed patterns

Hi, This is the 3rd version patch implementing vcond patterns on AArch64. It rewrites vcond patterns using newly introduced vcond_mask and vec_cmp patterns in previous patch. It also adds missing vect_cond_mixed patterns for AArch64. Note we rely on RTL combiner to optimize "mask = !x; res =

[PATCH AArch64/V3]Add new patterns for vcond_mask and vec_cmp

Hi, This is the 3rd version patch implementing vcond_mask and vec_cmp patterns on AArch64. Bootstrap and test along with next patch on AArch64, is it OK? Thanks, bin 2016-07-28 Alan Lawrence Renlin Li Bin Cheng * config/aarch64/aarch64-simd.md (vec_cmp): N

libcpp: Fix comment typo

Committed. Andreas. * include/cpplib.h: Fix comment typo. diff --git a/libcpp/include/cpplib.h b/libcpp/include/cpplib.h index 543f3b9..4e0084c 100644 --- a/libcpp/include/cpplib.h +++ b/libcpp/include/cpplib.h @@ -880,7 +880,7 @@ struct cpp_num #define CPP_N_FLOATING 0x0002 #define

Re: [PATCH] Change dump expectation in PR71857

On Mon, Aug 1, 2016 at 2:12 PM, Martin Liška wrote: > On 08/01/2016 01:58 PM, Richard Biener wrote: >> On Mon, Aug 1, 2016 at 1:30 PM, Martin Liška wrote: >>> Hello. >>> >>> After changing the expected number of loop iterations, IVOPTS decides to >>> pick up an another IV. >>> Bin agreed that th

Re: [patch] Some testsuite cleanup

On 28/07/16 22:06 +0100, Jonathan Wakely wrote: When I added _Temporary_object to vector recently I updated the construct/destroy counts in this test to match, but the changes only apply for C++11 and later. This makes the test pass whether run as C++98 or C++11 and later. Fix std::vector test

Re: [PR71078] x / abs(x) -> copysign (1.0, x)

On Mon, 1 Aug 2016, Richard Biener wrote: > > Correct expansion of abs or copysign for IBM long double (i.e., for the > > case where signbit_rw for the format is -1) requires special logic for > > that format; inhibiting particular incorrect expansion code may cause an > > external function cal

Re: [PR71078] x / abs(x) -> copysign (1.0, x)

On Mon, 1 Aug 2016, Joseph Myers wrote: > On Mon, 1 Aug 2016, Richard Biener wrote: > > > On Mon, 1 Aug 2016, Joseph Myers wrote: > > > > > On Mon, 1 Aug 2016, Richard Biener wrote: > > > > > > > I don't think so - the pattern is as much a canonicalization as an > > > > optimization. If the ta

Re: [PATCH 1/4] Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch

As I just wrote, this patch needs work. the general points are: 1) exposing integers 0-3 to the user as switch values. Don't do that, give them names. In this case a comma separated list of orthogonal names seems appropriate. But see below. 2) Poor documentation. How might the user might

[PATCH] More testsuite cleanup

Another bunch of fixes to make the testsuite work with any -std option, and remove some redundancy. I don't know why this file has "-x c" in the options, but since those options come after the filename it's ignored and has no effect anyway: Remove "-x c" from dg-options in libstdc++ C++ test

[patch,avr] PR70677: Use -fno-caller-saves for avr

Problem with -fcaller-saves is that there are situations where it triggers an expensive frame just to store a variable around a function call even though there are plenty of call-saved registers. Example: typedef __UINT8_TYPE__ uint8_t; extern uint8_t uart0_getc (void); void foo (uint8_t *bu

Re: [PATCH] Change dump expectation in PR71857

On 08/01/2016 01:58 PM, Richard Biener wrote: > On Mon, Aug 1, 2016 at 1:30 PM, Martin Liška wrote: >> Hello. >> >> After changing the expected number of loop iterations, IVOPTS decides to >> pick up an another IV. >> Bin agreed that the test-case still makes sense with changed expectation. >> >>

Re: [PATCH 0/4] Various GCOV/PGO improvements

On 08/01/16 04:48, marxin wrote: Hi. My attempt in the following small series is to cover couple of issues I've recently observed. I'll briefly describe changes in respect to an individual patch: marxin (4): Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch As mentioned in [1],

Re: [RFC, v2] Test coverage for --param boundary values

On 07/28/2016 11:26 PM, Joseph Myers wrote: > On Mon, 18 Jul 2016, Martin Liška wrote: > >> Well, I can imaging a guard which will test whether >> "$objdir/../../params.options" file exits, and if so, then the tests are >> executed? Is it acceptable approach? > > The correct way to test for bui

Re: [PR71078] x / abs(x) -> copysign (1.0, x)

On Mon, 1 Aug 2016, Richard Biener wrote: > On Mon, 1 Aug 2016, Joseph Myers wrote: > > > On Mon, 1 Aug 2016, Richard Biener wrote: > > > > > I don't think so - the pattern is as much a canonicalization as an > > > optimization. If the target cannot expand copysign then the > > > middle-end exp

Re: [PATCH] Change dump expectation in PR71857

On Mon, Aug 1, 2016 at 1:30 PM, Martin Liška wrote: > Hello. > > After changing the expected number of loop iterations, IVOPTS decides to pick > up an another IV. > Bin agreed that the test-case still makes sense with changed expectation. > > Ready to be installed? Hmm, but do all targets replac

Re: [PR71078] x / abs(x) -> copysign (1.0, x)

On Mon, 1 Aug 2016, Joseph Myers wrote: > On Mon, 1 Aug 2016, Richard Biener wrote: > > > I don't think so - the pattern is as much a canonicalization as an > > optimization. If the target cannot expand copysign then the > > middle-end expander should try an alternative like the a / abs(x) > > f

Re: [patch,avr] Adjust insn length of forward branches.

2016-08-01 10:56 GMT+03:00 Georg-Johann Lay : > The length computation of "branch" flavour insn length attribute computed a > length one instruction too short, e.g. in the following test case: > > #define N0(N) if (X++ < N) __builtin_avr_nop() > > #define N1(N) N0(N);N0(N);N0(N);N0(N);N0(N);N0(N);N

Re: [patch,avr] Add built-in function to emit NOPs

2016-08-01 11:23 GMT+03:00 Georg-Johann Lay : > This adds a new built-in function that inserts a requested number of NOPs > into the instruction stream. I found it useful when testing avr-gcc. > > Ok to apply? > > > Johann > > > * doc/extend.texi (AVR Built-in Functions): Document >

Re: fold strlen (s) eq/ne 0 to *s eq/ne 0 on GIMPLE

On Mon, 1 Aug 2016, Andrew Pinski wrote: > On Mon, Aug 1, 2016 at 12:22 AM, Andrew Pinski wrote: > > On Mon, Aug 1, 2016 at 12:15 AM, Prathamesh Kulkarni > > wrote: > >> Hi Richard, > >> The attached patch tries to fold strlen (s) eq/ne 0 to *s eq/ne 0 on > >> GIMPLE. > >> I am not sure where w

Re: fold strlen (s) eq/ne 0 to *s eq/ne 0 on GIMPLE

On Mon, 1 Aug 2016, Prathamesh Kulkarni wrote: > Hi Richard, > The attached patch tries to fold strlen (s) eq/ne 0 to *s eq/ne 0 on GIMPLE. > I am not sure where was the ideal place to put this transform in and ended up > adding it to strlen_optimize_stmt(). > Does that look OK ? > > I needed to

Re: [PR71078] x / abs(x) -> copysign (1.0, x)

On Mon, 1 Aug 2016, Richard Biener wrote: > I don't think so - the pattern is as much a canonicalization as an > optimization. If the target cannot expand copysign then the > middle-end expander should try an alternative like the a / abs(x) > form. Though if copysign cannot be open-coded then I

[PATCH] Change dump expectation in PR71857

Hello. After changing the expected number of loop iterations, IVOPTS decides to pick up an another IV. Bin agreed that the test-case still makes sense with changed expectation. Ready to be installed? Martin >From 8073251d3827e0c7cd26680e97aa416e23132386 Mon Sep 17 00:00:00 2001 From: marxin Dat

[PATCH] Add more Aarch64 NEON intrinsics

Hi all, This patch adds the following NEON intrinsics to the ARM Aarch64 GCC: * vmaxnm_f64 * vminnm_f64 * vmax_f64 * vmin_f64 Some refactoring was done as well to remove some superfluous UNSPECS and iterators that could be combined into one. 3 was removed from aarch64-simd.md because after the

Re: [Patch, libfortran] Multi-threaded random_number

On Mon, Aug 1, 2016 at 1:48 PM, Andreas Schwab wrote: > On Mo, Aug 01 2016, Janne Blomqvist wrote: > >> PING? >> >> Also, a minor bugfix on top of the previous patch: >> >> diff --git a/libgfortran/intrinsics/random.c >> b/libgfortran/intrinsics/random.c >> index 9b54a02..21395ea 100644 >> --- a

Re: [Patch, libfortran] Multi-threaded random_number

On Mo, Aug 01 2016, Janne Blomqvist wrote: > PING? > > Also, a minor bugfix on top of the previous patch: > > diff --git a/libgfortran/intrinsics/random.c b/libgfortran/intrinsics/random.c > index 9b54a02..21395ea 100644 > --- a/libgfortran/intrinsics/random.c > +++ b/libgfortran/intrinsics/rando

Re: [PATCH] Fix early debug regression with DW_AT_string_length (PR debug/71906)

On Fri, Jul 22, 2016 at 2:39 PM, Richard Biener wrote: > On Fri, Jul 22, 2016 at 2:08 PM, Jakub Jelinek wrote: >> On Fri, Jul 22, 2016 at 01:55:22PM +0200, Richard Biener wrote: >>> > @@ -19201,18 +19205,70 @@ gen_array_type_die (tree type, dw_die_re >>> >if (size >= 0) >>> > add_

Re: [Patch, libfortran] Multi-threaded random_number

PING? Also, a minor bugfix on top of the previous patch: diff --git a/libgfortran/intrinsics/random.c b/libgfortran/intrinsics/random.c index 9b54a02..21395ea 100644 --- a/libgfortran/intrinsics/random.c +++ b/libgfortran/intrinsics/random.c @@ -787,7 +787,7 @@ random_seed_i4 (GFC_INTEGER_4 *size

Re: [AARCH64/PATCH] update vulcan L1 cacheline size

On 01/08/16 10:40, Virendra Pathak wrote: > Hi gcc-patches group, > > Please find the patch for updating vulcan L1 cacheline size. > > Tested the patch with compiling cross aarch64-linux-gcc, > bootstrapped native aarch64-unknown-linux-gnu and > run gcc regression. > > Kindly review and merge th

Re: [PATCH][AArch64] Allow multiple-of-8 immediate offsets for TImode LDP/STP

On 13/07/16 17:14, Kyrill Tkachov wrote: > Hi all, > > The most common way to load and store TImode value in aarch64 is to > perform an LDP/STP of two X-registers. > This is the *movti_aarch64 pattern in aarch64.md. > There is a bug in the logic in aarch64_classify_address where it > validates the

Re: [PATCH][AArch64] Allow multiple-of-8 immediate offsets for TImode LDP/STP

Ping. https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00737.html Thanks, Kyrill On 13/07/16 17:14, Kyrill Tkachov wrote: Hi all, The most common way to load and store TImode value in aarch64 is to perform an LDP/STP of two X-registers. This is the *movti_aarch64 pattern in aarch64.md. There is

[avr,backported,6] Fix PR 71151

Applied the simple fix for PR71151: Set JUMP_TABLES_IN_TEXT_SECTION to 1. https://gcc.gnu.org/r238935 Johann gcc/ Backport from 2016-06-16 trunk r237536. 2016-06-16 Senthil Kumar Selvaraj PR target/71151 * config/avr/avr.c (avr_asm_init_sections): Remove set

[AARCH64/PATCH] update vulcan L1 cacheline size

Hi gcc-patches group, Please find the patch for updating vulcan L1 cacheline size. Tested the patch with compiling cross aarch64-linux-gcc, bootstrapped native aarch64-unknown-linux-gnu and run gcc regression. Kindly review and merge the patch to trunk, if the patch is okay. Thanks. gcc/ChangeL

PATCH: PR71818: Don't advance IVs with a variable step

In the given test case, the loop is split into vectorised and non vectorised versions due to peeling. At the end of the loop the IVs are incremented to their latest value. This is achieved by taking the base of the loop (g_21) and adding the iterations (240) multiplied by the step (_6): : # _1

Re: [PATCH][RFC] PR middle-end/22141 GIMPLE store widening pass

On 18/07/16 13:22, Richard Biener wrote: On Fri, Jul 15, 2016 at 5:13 PM, Kyrill Tkachov wrote: Hi all, This is a GIMPLE pass to implement PR middle-end/22141. that is merge narrow stores of constants into fewer wider stores. A 2009 patch from Jakub [1] contains many testcases but a simple m

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

2016-07-26 18:38 GMT+03:00 Ilya Enkovich : > 2016-07-26 18:26 GMT+03:00 Jeff Law : >> On 07/26/2016 03:57 AM, Ilya Enkovich wrote: Ilya, what's the fundamental reason why we need to run if-conversion again? Yes, I know you want to if-convert the epilogue, but why?

[PATCH 0/4] Various GCOV/PGO improvements

Hi. My attempt in the following small series is to cover couple of issues I've recently observed. I'll briefly describe changes in respect to an individual patch: marxin (4): Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch As mentioned in [1], our current implementation can pro

[PATCH 1/4] Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch

libgcc/ChangeLog: 2016-07-28 Martin Liska * Makefile.in: Add functions to LIBGCOV_PROFILER. * libgcov-profiler.c (__gcov_one_value_profiler_body_atomic): New function. (__gcov_one_value_profiler_atomic): Likewise. (__gcov_indirect_call_profiler_v2): Fix

[PATCH 3/4] Fix typo in gcov.texi

gcc/ChangeLog: 2016-07-28 Martin Liska * doc/gcov.texi: Change _gcov_dump to __gcov_dump and _gcov_reset to __gcov_reset. * doc/gcov-tool.texi: Fix typo. libgcc/ChangeLog: 2016-08-01 Martin Liska * libgcov-util.c: Fix typo and GNU coding style. --- gcc/do

[PATCH 2/4] Remove __gcov_indirect_call_profiler

libgcc/ChangeLog: 2016-07-28 Martin Liska * Makefile.in: Remove __gcov_indirect_call_profiler. * libgcov-profiler.c (__gcov_indirect_call_profiler): Remove function. * libgcov.h: And the declaration of the function. --- libgcc/Makefile.in| 2 +- libgcc

[PATCH 4/4] Add tests for __gcov_dump and __gcov_reset

gcc/testsuite/ChangeLog: 2016-07-28 Martin Liska * g++.dg/gcov/gcov-dump-1.C: New test. * g++.dg/gcov/gcov-dump-2.C: New test. --- gcc/testsuite/g++.dg/gcov/gcov-dump-1.C | 23 +++ gcc/testsuite/g++.dg/gcov/gcov-dump-2.C | 32 +++

[patch,avr] Add built-in function to emit NOPs

This adds a new built-in function that inserts a requested number of NOPs into the instruction stream. I found it useful when testing avr-gcc. Ok to apply? Johann * doc/extend.texi (AVR Built-in Functions): Document __builtin_avr_nops. * config/avr/builtins.def (NOPS

[patch,avr] Adjust insn length of forward branches.

The length computation of "branch" flavour insn length attribute computed a length one instruction too short, e.g. in the following test case: #define N0(N) if (X++ < N) __builtin_avr_nop() #define N1(N) N0(N);N0(N);N0(N);N0(N);N0(N);N0(N);N0(N);N0(N);N0(N);N0(N) #define N2(N) N1(N);N1(N);N1(N)

Re: [PR71078] x / abs(x) -> copysign (1.0, x)

On Mon, 1 Aug 2016, Prathamesh Kulkarni wrote: > On 30 July 2016 at 02:57, Joseph Myers wrote: > > On Tue, 26 Jul 2016, Richard Sandiford wrote: > > > >> (which are really just extended tree codes). I suppose copysign is > >> a special case since we can always open code it, but in general we > >

Re: Implement -Wimplicit-fallthrough (take 2): fix missing breaks

On Fri, 29 Jul 2016, Marek Polacek wrote: > On Fri, Jul 29, 2016 at 01:46:11AM -0500, Segher Boessenkool wrote: > > On Thu, Jul 28, 2016 at 05:57:34PM +0200, Marek Polacek wrote: > > > Segher, is the rs6000.c part ok? > > > > Yes, that looks fine, thanks! Will you handle the backports as well? >

Re: [RFC] warn on dead function calls in ipa-pure-const [1/4]

On Sun, 31 Jul 2016, Prathamesh Kulkarni wrote: > On 31 July 2016 at 22:01, Jan Hubicka wrote: > >> On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > >> > >> > + warning_at (gimple_location (g), OPT_Wunused_value, > >> > + "Call from %s to %s has no effect", > >> > +

Re: [PATCH] Update libstdc++ baseline symbols

Attached patch updates alpha. 2016-08-01 Uros Bizjak * config/abi/post/alpha-linux-gnu/baseline_symbols.txt: Update. Tested on alphaev68-linux-gnu and committed. Uros. Index: config/abi/post/alpha-linux-gnu/baseline_symbols.txt

Re: fold strlen (s) eq/ne 0 to *s eq/ne 0 on GIMPLE

On Mon, Aug 1, 2016 at 12:22 AM, Andrew Pinski wrote: > On Mon, Aug 1, 2016 at 12:15 AM, Prathamesh Kulkarni > wrote: >> Hi Richard, >> The attached patch tries to fold strlen (s) eq/ne 0 to *s eq/ne 0 on GIMPLE. >> I am not sure where was the ideal place to put this transform in and ended up >>

Re: fold strlen (s) eq/ne 0 to *s eq/ne 0 on GIMPLE

On Mon, Aug 1, 2016 at 12:15 AM, Prathamesh Kulkarni wrote: > Hi Richard, > The attached patch tries to fold strlen (s) eq/ne 0 to *s eq/ne 0 on GIMPLE. > I am not sure where was the ideal place to put this transform in and ended up > adding it to strlen_optimize_stmt(). > Does that look OK ? I s

fold strlen (s) eq/ne 0 to *s eq/ne 0 on GIMPLE

Hi Richard, The attached patch tries to fold strlen (s) eq/ne 0 to *s eq/ne 0 on GIMPLE. I am not sure where was the ideal place to put this transform in and ended up adding it to strlen_optimize_stmt(). Does that look OK ? I needed to add TODO_update_ssa to strlen pass, otherwise we hit the follo