[PATCH 2/2] Move Asan instrumentation to sanopt pass

Hi all, Attached patch delays generation of Asan memory checking code until sanopt pass. This is a first step towards global static analysis of Asan instrumentation (hope to send it for review next week). The patch also changes the logic behind asan-instrumentation-with-call-threshold parameter

[PATCH 1/2] Support fnspecs for internal functions

Hi all, Following discussion in https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00016.html this patch adds support for fnspecs to internal function machinery which should (hopefully) allow compiler to perform better analysis and optimization of this construct. For now the only internal functi

[testsuite patch] check before using -mthumb in 5 arm tests

Five tests in gcc.target/arm add -mthumb without first checking that the option is compatible with the current multilib flags. This patch fixes that by skipping each test if neither arm_thumb1_ok or arm_thumb2_ok is true. Tested by running gcc.target/arm tests with a variety of multilib flags, so

[testsuite patch] add code to arm_thumbX_ok to exercise ABI

Running an arm-none-eabi test that adds "-mthumb" for a multilib that uses "-march=armv5te -mfloat-abi=hard" works fine if the test doesn't have any calls, but if it does then the effective-target checks for arm_thumb1_ok and arm_thumb2_ok pass but the test's compile step fails with "sorry, unimple

[PATCH] Remove a redundant statement in predict.c

Remove a redundant assignment "*predictor = PRED_BUILTIN_EXPECT;", since six lines later *predictor is assigned again. -- 2014-08-07 Yi Yang gcc: * predict.c (expr_expected_value_1): Remove the redundant assignment. diff --git gcc/predict.c gcc/predict.c index 835c618..869fc5d 100644 ---

Re: [patch] Avoid memory allocations when making futures ready

On 08/08/14 00:07 +0200, Dominique Dhumieres wrote: This patch replaces some reference members with pointers, ... ... Tested x86_64-linux, committed to trunk. This breaks bootstrap (see https://gcc.gnu.org/ml/gcc-regression/2014-08/): Fixed by this patch, sorry about that. I was caught out (a

[GSoC][match-and-simplify] reject builtin operator as for variable

reject operator to be used as variable in for. eg: (for mult in plus minus) * genmatch.c (get_operator): New function. (e_operation::e_operation): Adjust to call get_operator. (parse_for): Add call to get_operator. Thanks, Prathamesh Index: genmatch.c

Re: [patch] Avoid memory allocations when making futures ready

On 7 August 2014 23:07, Dominique Dhumieres wrote: >> This patch replaces some reference members with pointers, ... >> ... >> Tested x86_64-linux, committed to trunk. > > This breaks bootstrap (see https://gcc.gnu.org/ml/gcc-regression/2014-08/): Strange, I didn't see that - I'll fix it ASAP.

Re: [patch] Avoid memory allocations when making futures ready

> This patch replaces some reference members with pointers, ... > ... > Tested x86_64-linux, committed to trunk. This breaks bootstrap (see https://gcc.gnu.org/ml/gcc-regression/2014-08/): ... libtool: compile: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/

[PATCH, Cilk+] Fix for PR62008

Hi! Following patch adds necessary handling of the cases with incorrect type of an array in ArrayNotation and thus avoids ICE. Regtested on x86_64. Ok for trunk/4.9? Thanks, Igor gcc/c/ChangeLog: 2014-08-07  Igor Zamyatin  PR other/62008 * c-parser.c (c_parser_array_notation):

[committed] xfail gfortran.dg/pr45636.f90 on 32-bit hppa-*-*

Test fails on all 32-bit hppa systems. Tested on hppa-unknown-linux-gnu. Committed to trunk, 4.9 and 4.8. Dave -- John David Anglin dave.ang...@bell.net 2014-08-07 John David Anglin PR tree-optimization/60707 * gfortran.dg/pr45636.f90: xfail on 32-bit hppa*-*-*. Ind

Re: [GOOGLE, AUTOFDO] Assign different discriminators to calls with the same lineno

On Thu, Aug 7, 2014 at 2:40 PM, Xinliang David Li wrote: > On Thu, Aug 7, 2014 at 2:20 PM, Wei Mi wrote: >> No, it is not. This IR is dumped before early inline -- just after >> pass_build_cfg. The line number of the deconstructor is marked >> according to where its constructor is located, > > Th

Re: [GOOGLE, AUTOFDO] Assign different discriminators to calls with the same lineno

On Thu, Aug 7, 2014 at 2:20 PM, Wei Mi wrote: > No, it is not. This IR is dumped before early inline -- just after > pass_build_cfg. The line number of the deconstructor is marked > according to where its constructor is located, The definition location or the invocation location? David > instea

Re: [GOOGLE, AUTOFDO] Assign different discriminators to calls with the same lineno

No, it is not. This IR is dumped before early inline -- just after pass_build_cfg. The line number of the deconstructor is marked according to where its constructor is located, instead of where it is inserted. This is also problematic. Wei. On Thu, Aug 7, 2014 at 12:11 PM, Xinliang David Li wrot

patch to fix a wrong code generation with LRA when SDmode is used on ppc.

Hi, Mike. Here is the patch which solves LRA SDmode problem which we discussed on IRC on Friday. The patch was successfully tested and bootstrapped on ppc64 with -mlra switched on. David, is it ok to commit it to the trunk? 2014-08-07 Vladimir Makarov * config/rs6000/rs6000.c (rs600

Re: [GOOGLE, AUTOFDO] Assign different discriminators to calls with the same lineno

Yes, that is intentional. It is to avoid assiging a discriminator for the first call in the group of calls with the same source lineno. Starting from the second call in the group, it will get a different discriminator with previous call in the same group. Thanks, Wei. On Thu, Aug 7, 2014 at 12:17

Re: Fix ivopts address space confusion

On 08/07/2014 09:50 PM, Bernd Schmidt wrote: The following patch reworks this area - instead of trying to find a proper pointer type, it just recognizes the case where an integer is promoted to be the base, and performs all calculations in that type rather than sizetype. That also seems to be an

[PATCH] Don't unilaterally include when checking for fpsetmask

The attached change fixes the build of libgfortran on hppa1.1-hp- hpux10.20 (I know I'm going for the oldest system that will build gfortran). OK? Dave -- John David Anglin dave.ang...@bell.net 2014-08-08 John David Anglin * configure.ac: Guard include of . * configu

[patch] Avoid memory allocations when making futures ready

This patch replaces some reference members with pointers, so that the types containing them become trivial and are more efficient to pass as function arguments and can use the small object optimization when stored in a std::function, so that promise::set_value() doesn't need to allocate any memory

Fix ivopts address space confusion

This is a followup fix for the patches from PR41857, which contained a bug that is exposed by the ptx backend. The problem is finding the right pointer type for a mem_ref during ivopts. The original problem was that on spu-elf, __ea pointers are 64 bit while sizetype is 32 bit. During ivopts,

C++ PATCH for c++/62043 (ICE after sorry giving multiple input files to cc1plus)

As pinskia suggested in a comment. Tested x86_64-pc-linux-gnu, applying to trunk. commit fb5be680f7e1c545bc13ccf603dfd99c9fd707a2 Author: Jason Merrill Date: Thu Aug 7 15:14:49 2014 -0400 PR c++/62043 * parser.c (c_parse_file): Change sorry to fatal_error. diff --git a/gcc

C++ PATCH for c++/61959 (POINTER_PLUS_EXPR in CONSTRUCTOR)

It seems that an empty base initializer can show up with an index of POINTER_PLUS_EXPR as well. Tested x86_64-pc-linux-gnu, applying to trunk, 4.8, 4.9. commit 36db761e7a61c86d1c95dd6aa65bc325b6642966 Author: Jason Merrill Date: Thu Aug 7 15:10:08 2014 -0400 PR c++/61959 * semantic

Re: [PATCH, AArch64] Use MOVN to generate 64-bit negative immediates where sensible

On 08/07/2014 02:57 AM, Kyrill Tkachov wrote: > + if (one_match > zero_match) > +{ > + /* Set either first three quarters or all but the third.*/ > + mask = 0xll << (16 - first_not__match); > + emit_insn (gen_rtx_SET (VOIDmode, dest, > +

[committed] Fix trivial failure of gcc.dg/atomic/c11-atomic-exec-[45].c on hppa-hpux

_POSIX_C_SOURCE is predefined on hppa-hpux, so it needs to be undefined before it can be redefined. Tested on hppa2.0-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed to trunk and 4.9 branch. Dave -- John David Anglin dave.ang...@bell.net 2014-08-07 John David Anglin * g

Re: [GOOGLE, AUTOFDO] Assign different discriminators to calls with the same lineno

> static int > -next_discriminator_for_locus (location_t locus) > +increase_discriminator_for_locus (location_t locus, bool return_next) > { >struct locus_discrim_map item; >struct locus_discrim_map **slot; > @@ -934,8 +936,10 @@ next_discriminator_for_locus (location_t >(*slot)->

Re: [GOOGLE, AUTOFDO] Assign different discriminators to calls with the same lineno

Is this [1.cc : 179:64] Reader::~Reader (&version); from an inline instance? David On Wed, Aug 6, 2014 at 10:18 AM, Wei Mi wrote: > We saw bb like this in the IR dump after pass_build_cfg: > > : > [1.cc : 205:45] D.332088 = table->_vptr.Table; > [1.cc : 205:45] D.332134 = D.332088 + 104;

Re: [patch] [Bug libstdc++/61667] setting max_load_factor of unordered_map cause buckets shrink

On 07/08/14 20:56 +0200, François Dumont wrote: Hi I took a closer look to this PR and there is indeed a problem. My comment on the PR is incorrect, I thought the problem was in the rehash method but is it not. It is indeed wrong to shrink buckets when invoking max_load_factor, it reverts

[committed] Add comment to gcc.dg/atomic/stdatomic-flag.c regarding xfail

The attached change adds a requested comment regarding the xfail. Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed to trunk and 4.9 branch. Dave -- John David Anglin dave.ang...@bell.net 2014-08-07 John David Anglin * gcc.dg/atomic/stdatomic-flag.c: Add xfa

[patch] [Bug libstdc++/61667] setting max_load_factor of unordered_map cause buckets shrink

Hi I took a closer look to this PR and there is indeed a problem. My comment on the PR is incorrect, I thought the problem was in the rehash method but is it not. It is indeed wrong to shrink buckets when invoking max_load_factor, it reverts the effect of preallocating buckets before a bi

[committed] Fix alignment in gcc.dg/memcpy-5.c on hppa*-*-hpux*

Tested on hppa2.0-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed to trunk. Dave -- John David Anglin dave.ang...@bell.net 2014-08-07 John David Anglin * gcc.dg/memcpy-5.c: Add -fno-common option on hppa*-*-hpux*. Index: gcc.dg/memcpy-5.c ==

[PATCH], rs6000 cleanup, make constraints tighter

I'm starting to look at updating my old address branch with an eye towards getting the changes committed in GCC 4.10. The address branch is meant to rewrite handling of addresses in the rs6000 backend, to generalize the addresses before register allocation to allow more general forms, and then wit

[committed] Fix failure of gcc.c-torture/compile/pr60655-1.c on 32-bit hppa-hpux

32-bit hppa-hpux doesn't support -fdata-sections causing the test to fail. Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed to trunk and 4.9 branch. Dave -- John David Anglin dave.ang...@bell.net 2014-08-07 John David Anglin * gcc.c-torture/compile/pr6065

Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)

On Thu, Aug 07, 2014 at 01:44:02PM +0200, Jan Hubicka wrote: > > It's only important to not inline the static constructor into the > > one function calling all of them. And only not doing that during > > early inlining (but still inline into those constructors). That's > > because we eventually w

[committed] Fix alignment in gcc.dg/pr57233.c and c-c++-common/pr50459.c on hppa*-*-hpux*

Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Both hunks committed to trunk. First hunk committed to 4.9 branch. Dave -- John David Anglin dave.ang...@bell.net 2014-08-07 John David Anglin * gcc.dg/pr57233.c: Add -fno-common option on hppa*-*-hpux*. * c-c+

Re: [C++ Patch] PR 51312

On 08/07/2014 12:41 PM, Paolo Carlini wrote: Ok. Probably at some point I should review which kind of diagnostics the various implementations emit: for example *for enum27.C* currently clang talks about *narrowing*, the kind of of diagnostics we emit from chech_narrowing; EDG instead produces

Re: Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation

Hi Bernd! On Mon, 4 Aug 2014 23:00:07 +0200, Bernd Schmidt wrote: > On 07/23/2014 04:37 PM, Ilya Verbin wrote: > > On 23 Jul 16:16, Bernd Schmidt wrote: > >> Here's the latest version, which fixes some more issues and removes > >> things that are now unnecessary. > I've committed this version t

Re: [C PATCH] Implement -Wc90-c99-compat (PR c/51849)

On Thu, 31 Jul 2014, Marek Polacek wrote: > A few issues: currently we don't warn (in -std=c90 -pedantic mode) > about the usage of __func__ and _Pragma (possible others - va_copy?). > I'm hoping this is not that important though. For restrict/inline, > in GNU90 mode we just don't compile the cod

Re: [C++ Patch] PR 51312

Hi, On 08/07/2014 06:32 PM, Jason Merrill wrote: On 08/07/2014 11:28 AM, Jason Merrill wrote: -Wno-narrowing should prevent an error on enum27 Er, should *not*. Ok. Probably at some point I should review which kind of diagnostics the various implementations emit: for example *for enum27.C* c

Re: [C++ Patch] PR 51312

On 08/07/2014 11:28 AM, Jason Merrill wrote: -Wno-narrowing should prevent an error on enum27 Er, should *not*. Jason

Re: [PATCH 199/236] Introduce rtx_insn_list subclass of rtx_def

On Wed, 2014-08-06 at 21:29 -0400, Trevor Saunders wrote: > On Wed, Aug 06, 2014 at 01:22:58PM -0400, David Malcolm wrote: > > +class GTY(()) rtx_insn_list : public rtx_def > > +{ > > + /* No extra fields, but adds invariant: (GET_CODE (X) == INSN_LIST). > > some nice future work would be to see

Re: [C++ Patch] PR 51312

On 08/07/2014 09:58 AM, Paolo Carlini wrote: Also, I was thinking earlier today that conceptually the check pasted above should check cases different from the cases handled by perform_implicit_conversion_flags, thus, eg, *not* handle enum27.C, because it's an hard error, isn't our standard (and s

Re: [PATCH 212/236] Use rtx_expr_list for expr_status.x_forced_labels

On Thu, 2014-08-07 at 13:32 +0200, Bernd Schmidt wrote: > On 08/06/2014 07:23 PM, David Malcolm wrote: > > diff --git a/gcc/function.h b/gcc/function.h > > index 28a20f3..ba7597c 100644 > > --- a/gcc/function.h > > +++ b/gcc/function.h > > @@ -135,7 +135,7 @@ struct GTY(()) expr_status { > > rt

[PATCH] Add -ffat-lto-objects to gcc.dg/torture/pr61772.c

Hi all, This test in the torture suite fails on -flto because it scans for a sentinel string inside an asm block that it wants to make sure is not optimised away. However, with -flto gcc uses slim LTO objects which contain a binary representation of the structure of the program rather than out

Teach ipa-devirt about dynamic type changes

Hi, this patch adds logic for determining dynamic type of a memory location based on constructor calls or vtable stores as discussed on the Cauldron. It is based on existing code in ipa-prop that does look for type changes, but it newly handles the ctor calls too and fills in the polymorphic_call_

Re: [GOMP4, RFC] OpenMP4 offload support for Intel PHI targets.

Hello, On 25 Jul 20:55, Kirill Yukhin wrote: > Hello, > Branch was rebased on trunk. > > It contains fixes for several issues in the build system. > Now 'configure' can be called using relative path. > > Also some options are now unnecessary, updated manual is posted > on wiki: https://gcc.gnu.or

Re: [AArch64] Implement movmem for the benefit of inline memcpy

On Thu, Aug 7, 2014 at 4:20 PM, James Greenhalgh wrote: > On Tue, Aug 05, 2014 at 08:05:00AM +0100, Andrew Pinski wrote: >> On Fri, Aug 1, 2014 at 2:21 AM, wrote: >> >> On Jun 6, 2014, at 1:50 AM, James Greenhalgh >> >> wrote: >> >> >> >> >> >> Hi, >> >> >> >> The move_by_pieces infrastructure

Re: [PATCH][ARM] Delete f_sels, f_seld types, use fcsel instead

On 07/08/14 12:26, Kyrill Tkachov wrote: > Hi all, > > During the great types rework this must have slipped through the cracks. > We had two different types to describe the fcsel (A64) and vsel (A32) > instructions: fcsel and f_sel[s,d]. > In the A53 pipeline description we use fcsel, so the AAr

Re: [PATCH][AArch64] Restrict usage of FP/SIMD registers for TImode reload and absdi2 patterns for non-float/simd targets

On 07/08/14 12:22, Kyrill Tkachov wrote: > Hi all, > > This patch arises from PR 62014 where apparently gcc generates usage of > FP registers with -mgeneral-regs-only. The PR turned out to be bogus in > the end that but an inspection of aarch64.md shows that there are some > patterns that don't

Re: [AArch64] Implement movmem for the benefit of inline memcpy

On Tue, Aug 05, 2014 at 08:05:00AM +0100, Andrew Pinski wrote: > On Fri, Aug 1, 2014 at 2:21 AM, wrote: > >> On Jun 6, 2014, at 1:50 AM, James Greenhalgh > >> wrote: > >> > >> > >> Hi, > >> > >> The move_by_pieces infrastructure performs a copy by repeatedly trying > >> the largest safe copy it

Re: [C++ Patch] PR 51312

Hi, On 08/07/2014 03:24 PM, Jason Merrill wrote: On 08/07/2014 06:49 AM, Paolo Carlini wrote: + if (ENUM_UNDERLYING_TYPE (enumtype)) +value = perform_implicit_conversion_flags + (ENUM_UNDERLYING_TYPE (enumtype), value, tf_warning_or_error, + LOOKUP_IMPLICIT | LOO

Re: [PINGv3][PATCH] Fix for PR 61561

Sendinggcc/ChangeLog Sendinggcc/config/arm/thumb1.md Transmitting file data .. Committed revision 213710. P.S. Sorry for inconvenience. On 08/07/2014 01:02 PM, Marat Zakirov wrote: Sorry ;( Will test&fix it. On 08/07/2014 12:50 PM, Richard Earnshaw wrote: On 08/06/2014 06:44 P

Re: [PATCH][LTO] Streamer re-org (what's left)

On Thu, 7 Aug 2014, Richard Biener wrote: > > The following are the non-cleanup parts. The patch moves us > to compress streams (what data-streamer thinks of "streams") > instead of whole sections. This enables us to only need > a single compressed and uncompressed block of data "live" > as opp

[PATCH, fortran] PR fortran/60255 Deferred character length

Hi, in the bugtracker for PR60255 janus proposed to fix the bug by removing the error and additionally checking if the character array length declaration is deferred, which leaves the the charlen to be 0 (gcc/fortran/class.c (find_intrinsic_vtab) 2418-2420). My contribution to that patch is the

Re: Patch for constexpr variable templates

>> * decl.c (cp_finish_decl): Don't check the initializer if it is >> value-dependent. > > > Why is this needed? I thought that check_initializer was evaluating the constant expression, and was resulting in errors because a template-id referring to a variable template with a conc

Re: [GSoC] Elimination of CLooG library installation dependency

On 07/08/2014 15:18, Roman Gareev wrote: To commit 2), I would like you to run a wider set of tests (e.g., the LLVM test suite). If this passes successful, we should give a headsup on the GCC mailing list and ask other people to try the new isl support. If now bugs have found, we switch. I've t

Re: [PATCH, AArch64] Use MOVN to generate 64-bit negative immediates where sensible

On 07/08/14 13:57, Kyrill Tkachov wrote: > > On 07/08/14 13:46, Richard Earnshaw wrote: >> On 07/08/14 12:32, Kyrill Tkachov wrote: >>> On 16/05/14 13:35, Richard Earnshaw wrote: On 08/05/14 18:36, Ian Bolton wrote: > Hi, > > It currently takes 4 instructions to generate certain i

Re: Patch for constexpr variable templates

On 08/07/2014 09:22 AM, Andrew Sutton wrote: * pt.c (lookup_template_variable): Make the type unspecified if any template arguments are dependent. This hunk is OK. * decl.c (cp_finish_decl): Don't check the initializer if it is value-dependent. Why is thi

Re: [C++ Patch] PR 51312

On 08/07/2014 06:49 AM, Paolo Carlini wrote: + if (ENUM_UNDERLYING_TYPE (enumtype)) + value = perform_implicit_conversion_flags + (ENUM_UNDERLYING_TYPE (enumtype), value, tf_warning_or_error, + LOOKUP_IMPLICIT | LOOKUP_NO_NARROWING); It seems like doin

Re: Patch for constexpr variable templates

This patch prevents the initializer from being checked when it is dependent. It also sets the type of a dependent template-id referring to a variable template to be unknown, making such expressions type dependent. 2014-08-07 Andrew Sutton * pt.c (lookup_template_variable): Make the typ

Re: [GSoC] Elimination of CLooG library installation dependency

> To commit 2), I would like you to run a wider set of tests (e.g., the LLVM > test suite). If this passes successful, we should give a headsup on the GCC > mailing list and ask other people to try the new isl support. > If now bugs have found, we switch. I've tested the modified version of Graphi

Re: [PATCH, AArch64] Use MOVN to generate 64-bit negative immediates where sensible

On 07/08/14 13:46, Richard Earnshaw wrote: On 07/08/14 12:32, Kyrill Tkachov wrote: On 16/05/14 13:35, Richard Earnshaw wrote: On 08/05/14 18:36, Ian Bolton wrote: Hi, It currently takes 4 instructions to generate certain immediates on AArch64 (unless we put them in the constant pool). For

Re: [PATCH, AArch64] Use MOVN to generate 64-bit negative immediates where sensible

On 07/08/14 12:32, Kyrill Tkachov wrote: > > On 16/05/14 13:35, Richard Earnshaw wrote: >> On 08/05/14 18:36, Ian Bolton wrote: >>> Hi, >>> >>> It currently takes 4 instructions to generate certain immediates on >>> AArch64 (unless we put them in the constant pool). >>> >>> For example ... >>> >>>

Re: [PATCH, trans-mem, PR 61393] Copy tm_clone field of cgraph_node when cloning the node

Hi, On Thu, Aug 07, 2014 at 08:10:51AM +0200, Patrick Marlier wrote: > Hi Martin, > > On Wed, Aug 6, 2014 at 4:02 PM, Martin Jambor wrote: > > Hi, > > > > On Wed, Jul 30, 2014 at 06:56:05PM +0200, Martin Jambor wrote: > >> Hi, > >> > >> IPA-CP can wreck havoc to transactional memory support as d

Re: [PATCH, Cilk+] Fix for PR61962

On Thu, Aug 07, 2014 at 12:33:00PM +, Zamyatin, Igor wrote: > --- a/gcc/c-family/array-notation-common.c > +++ b/gcc/c-family/array-notation-common.c > @@ -221,11 +221,15 @@ find_rank (location_t loc, tree orig_expr, tree expr, > bool ignore_builtin_fn, > current_rank++; >

Re: [PATCH, Cilk+] Fix for PR61962

On Thu, Aug 7, 2014 at 2:33 PM, Zamyatin, Igor wrote: >> > >> > Changelog: >> > >> > gcc/c-family: >> > >> > 2014-07-31 Igor Zamyatin >> > >> > PR other/61962 >> > * array-notation-common.c (find_rank): Added handling for other >> > types of references. >> > >> > >> > gc

RE: [PATCH, Cilk+] Fix for PR61962

> > > > Changelog: > > > > gcc/c-family: > > > > 2014-07-31 Igor Zamyatin > > > > PR other/61962 > > * array-notation-common.c (find_rank): Added handling for other > > types of references. > > > > > > gcc/testsuite: > > > > 2014-07-31 Igor Zamyatin > > > > PR

Re: [PATCH lto]Fix the mis-matched arguments of lto_define_builtins

On Thu, Aug 7, 2014 at 11:46 AM, Bin Cheng wrote: > Hi, > As analyzed in PR62032, this patch fixes the latent lto bug by switching > arguments of lto_define_builtins, otherwise vsnprintf-chk.c would fail on > arm/aarch64 with lto options. > > Is it ok if bootstrap and test pass? Ok (would be nice

Re: [PATCH testcase]Skip test pr61772.c for lto tests

On Thu, Aug 7, 2014 at 11:43 AM, Bin Cheng wrote: > Hi, > Case pr61772.c scans specific string in assembly file, and it is run for > many different option combinations. When it's tested against different lto > option combinations on targets like ARM, the generated pr61772.s may only > contain lto

[PATCH] Move memory and some string folding from builtins.c to gimple-fold.c

The following moves memcpy, memmove and memset folding from builtins.c to gimple-fold.c. This also drags in stringop foldings (at least those that are done from gimple-fold.c) because otherwise we may end up recursing into fold_stmt via gimplifying of builtin.c folding results which ends up confu

[PATCH][LTO] Streamer re-org (what's left)

The following are the non-cleanup parts. The patch moves us to compress streams (what data-streamer thinks of "streams") instead of whole sections. This enables us to only need a single compressed and uncompressed block of data "live" as opposed to a whole section (well, in theory - we still do

Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)

> It's only important to not inline the static constructor into the > one function calling all of them. And only not doing that during > early inlining (but still inline into those constructors). That's > because we eventually want to eliminate the body of the static > constructor in favor of a D

Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)

On Thu, 7 Aug 2014, Jan Hubicka wrote: > > > > > > Probably not ;) > > > > > > But seriously it's a matter of a) keeping constructors for each > > > variable separate and optimize them in GIMPLE, b) recognize > > > resulting code that can be expressed with a initializer > > > > > > a) can be do

Re: [PATCH 212/236] Use rtx_expr_list for expr_status.x_forced_labels

On 08/06/2014 07:23 PM, David Malcolm wrote: diff --git a/gcc/function.h b/gcc/function.h index 28a20f3..ba7597c 100644 --- a/gcc/function.h +++ b/gcc/function.h @@ -135,7 +135,7 @@ struct GTY(()) expr_status { rtx x_apply_args_value; /* List of labels that must never be deleted. */ -

Re: [PATCH, AArch64] Use MOVN to generate 64-bit negative immediates where sensible

On 16/05/14 13:35, Richard Earnshaw wrote: On 08/05/14 18:36, Ian Bolton wrote: Hi, It currently takes 4 instructions to generate certain immediates on AArch64 (unless we put them in the constant pool). For example ... long long beefcafebabe () { return 0xBEEFCAFEBABEll

Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)

> > err yeah, I guess we'd need to rework things so front end just creates > functions for each variable and then middle end pass creates function > that call all of them if necessary. There is already code for that in cdtor optimization pass (ipa.c), but I think C++ does its own wrapper to solve

[PATCH][ARM] Delete f_sels, f_seld types, use fcsel instead

Hi all, During the great types rework this must have slipped through the cracks. We had two different types to describe the fcsel (A64) and vsel (A32) instructions: fcsel and f_sel[s,d]. In the A53 pipeline description we use fcsel, so the AArch32 version was presumably scheduled improperly Th

[PATCH][AArch64] Restrict usage of FP/SIMD registers for TImode reload and absdi2 patterns for non-float/simd targets

Hi all, This patch arises from PR 62014 where apparently gcc generates usage of FP registers with -mgeneral-regs-only. The PR turned out to be bogus in the end that but an inspection of aarch64.md shows that there are some patterns that don't have their usage of FP/SIMD registers properly gua

[patch] optimize std::list move constructor

While preparing the initial commit for the std::list ABI transition I noticed the move constructor does unnecessary work, initializing the object to an empty state, then calling _List_node_base::swap which checks whether it's empty (but we already know it is) and then initializes it again. The _Li

[PATCH] Cancel bswap opt when intermediate stmts are reused

Hi all, Currently, when an expression doing manual load or bswap is detected, the bswap optimization replace it by an actual load and/or bswap instruction without considering whether the intermediate values computed in the expressions are reused later. If that is the case, the construction of thes

Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)

On Thu, Aug 07, 2014 at 12:29:34PM +0200, Jan Hubicka wrote: > > > > > > Probably not ;) > > > > > > But seriously it's a matter of a) keeping constructors for each > > > variable separate and optimize them in GIMPLE, b) recognize > > > resulting code that can be expressed with a initializer > >

[C++ Patch] PR 51312

Hi, this is a rejects valid issue with constexpr conversion operators and enums, eg: struct X0 { constexpr operator int() const { return 1; } }; enum E0 { e0 = X0() }; Given build_expr_type_conversion, we can handle the bug rather easily by using it when the enum doesn't have an underlyin

Re: [PATCH 4/7] Convert ipa-devirt to inchash

> From: Andi Kleen > > gcc/: > > 2014-07-30 Andi Kleen > > * ipa-devirt.c (polymorphic_call_target_hasher::hash): > Convert to inchash. OK, Honza

Re: [PATCH 000/236] Introduce rtx subclasses

On Wed, Aug 06, 2014 at 01:19:39PM -0400, David Malcolm wrote: > This is the patch series I spoke about at Cauldron in the talk > "A proposal for typesafe RTL"; slides here: > http://dmalcolm.fedorapeople.org/presentations/cauldron-2014/rtl > > They can also be seen at: > https://dmalcolm.fedorape

Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)

> > > > Probably not ;) > > > > But seriously it's a matter of a) keeping constructors for each > > variable separate and optimize them in GIMPLE, b) recognize > > resulting code that can be expressed with a initializer > > > > a) can be done with delaying inlining to IPA time and hoping > > tha

Re: [PATCH][testsuite] Don't run cproj-fails-with-broken-glibc.c for broken glibc

Hi Tom, >> the test now XPASSes on Solaris, adding testsuite noise in the other >> direction on completely innocent systems. > > FWIW, I would be interested in understanding the details there. easy once you get it ;-) The check_effective_target_* procs are supposed to return 1 in the success cas

Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)

On Thu, Aug 07, 2014 at 09:53:13AM +0200, Richard Biener wrote: > On Wed, 6 Aug 2014, Mike Stump wrote: > > > On Aug 6, 2014, at 12:56 AM, Richard Biener wrote: > > >> My concern is the code we're removing discusses the need to simplify when > > >> these expressions are in static initializers. W

Re: [PATCH testcase]Add bind_pic_locally to case addrtmp.c

On Thu, Aug 7, 2014 at 5:43 PM, Bin Cheng wrote: > Hi, > > The case depends on GCC inlining of global function, but the callee won't be > inlined because it's global function and considered over-writable during > run-time. It won't be inlined only if it's tested against -fpic/-fPIC. > This patch

[PATCH lto]Fix the mis-matched arguments of lto_define_builtins

Hi, As analyzed in PR62032, this patch fixes the latent lto bug by switching arguments of lto_define_builtins, otherwise vsnprintf-chk.c would fail on arm/aarch64 with lto options. Is it ok if bootstrap and test pass? 2014-08-07 Bin Cheng PR lto/62032 * lto/lto-lang.c (lto_in

[PATCH testcase]Skip test pr61772.c for lto tests

Hi, Case pr61772.c scans specific string in assembly file, and it is run for many different option combinations. When it's tested against different lto option combinations on targets like ARM, the generated pr61772.s may only contain lto object content, rather than assembly codes. The scanning ch

[PATCH testcase]Add bind_pic_locally to case addrtmp.c

Hi, The case depends on GCC inlining of global function, but the callee won't be inlined because it's global function and considered over-writable during run-time. This patch fixes the failure by binding it to pic locally. Is it OK? Thanks, bin gcc/testsuite/ChangeLog 2014-08-07 Bin Cheng

Re: [PINGv3][PATCH] Fix for PR 61561

Sorry ;( Will test&fix it. On 08/07/2014 12:50 PM, Richard Earnshaw wrote: On 08/06/2014 06:44 PM, Richard Earnshaw wrote: Similarly for the movqi pattern. You haven't updated the thumb1 QImode pattern in the same way. R. On 07/08/14 09:10, Marat Zakirov wrote: --Marat On 08/07/2014 12:00

[PINGv2][PATCHv3] Fix vector tests on ARM platforms with disabled unaligned accesses

On 07/31/2014 04:08 PM, Marat Zakirov wrote: On 07/24/2014 07:40 PM, Marat Zakirov wrote: On 07/24/2014 04:27 PM, Marat Zakirov wrote: On 07/23/2014 06:23 PM, Marat Zakirov wrote: Hi there! I made a patch which fixes regressions on ARM platforms with disabled unaligned accesses. The prob

Re: [PINGv3][PATCH] Fix for PR 61561

>>> On 08/06/2014 06:44 PM, Richard Earnshaw wrote: Similarly for the movqi pattern. You haven't updated the thumb1 QImode pattern in the same way. R. On 07/08/14 09:10, Marat Zakirov wrote: > --Marat > On 08/07/2014 12:00 PM, Ramana Radhakrishnan wrote: >> On Thu, Aug 7, 2014 at 8:36 AM,

[PATCH][committed] Remove arm-specific -march option in gcc.dg/pr61756.c

Hi all, As Bin pointed out, setting -march=armv5 explicitly on this test causing a FAIL when testing with /-mthumb. The bug fixed by the commit that added this test occured only on pre-SMP architectures, i.e. ARMv5 and earlier. I think it's best to just remove the -march option. If someone was

Re: [PATCH][AArch64][tests]Skip graphite tests that don't fit -mcmodel=tiny

Hi Mike, On 01/08/14 01:00, Mike Stump wrote: On Jul 31, 2014, at 3:55 PM, Ramana Radhakrishnan wrote: However if we have a situation where a port tries to ameliorate some of these errors with linker veneering and the compiler testsuite peels off such error messages and just marks them as UNS

Re: [PATCH] Fix PR61950

On Thu, 31 Jul 2014, Richard Biener wrote: > > The following fixes PR61950 by properly initializing the _size field > of the static constructor for the vtable init member. Previously > gfortran would use a 64bit integer to initialize the 32bit size field > (not sure why larger aggregates are not

Re: [PINGv3][PATCH] Fix for PR 61561

--Marat On 08/07/2014 12:00 PM, Ramana Radhakrishnan wrote: On Thu, Aug 7, 2014 at 8:36 AM, Marat Zakirov wrote: Thank you. $ svn commit Sendinggcc/ChangeLog Sendinggcc/config/arm/thumb1.md Sendinggcc/config/arm/thumb2.md Transmitting file data ... Committed revision 21

Re: [PATCH 2/2] Enable elimination of zext/sext

On Thu, Aug 7, 2014 at 7:24 AM, Kugan wrote: > On 06/08/14 23:29, Richard Biener wrote: >> On Wed, Aug 6, 2014 at 3:21 PM, Kugan >> wrote: >>> On 06/08/14 22:09, Richard Biener wrote: On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek wrote: > On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richa

Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)

On Wed, 6 Aug 2014, Mike Stump wrote: > On Aug 6, 2014, at 12:56 AM, Richard Biener wrote: > >> My concern is the code we're removing discusses the need to simplify when > >> these expressions are in static initializers. What's going to ensure that > >> we're still simplifying instances which ap

Re: [PINGv3][PATCH] Fix for PR 61561

On Thu, Aug 7, 2014 at 8:36 AM, Marat Zakirov wrote: > Thank you. > > $ svn commit > Sendinggcc/ChangeLog > Sendinggcc/config/arm/thumb1.md > Sendinggcc/config/arm/thumb2.md > Transmitting file data ... > Committed revision 213695. > > P.S. > > Minor nit was reg. tested. A

  1   2   >