Re: [PATCH][RFC] Remove warning for SET VOIDmode -> BLKmode.

On 11/06/2015 04:12 PM, Bernd Schmidt wrote: On 11/06/2015 10:45 PM, Jeff Law wrote: On 11/03/2015 10:16 AM, Dominik Vogt wrote: * genrecog.c (validate_pattern): Allow "set VOIDmode -> BLKmode" without warnings. First, for reference, I was initially concerned the patterns were bogus,

Re: [PATCH][RFC] Remove warning for SET VOIDmode -> BLKmode.

On 11/06/2015 10:45 PM, Jeff Law wrote: On 11/03/2015 10:16 AM, Dominik Vogt wrote: * genrecog.c (validate_pattern): Allow "set VOIDmode -> BLKmode" without warnings. First, for reference, I was initially concerned the patterns were bogus, but these are reasonably canonical ways to

[PATCH 1/2] [graphite] do not create unnecessary dimensions in scop scattering

* graphite-sese-to-poly.c (build_pbb_scattering_polyhedrons): Remove. (build_pbb_minimal_scattering_polyhedrons): New. (build_scop_scattering): Remove. (build_scop_minimal_scattering): New. (build_scop_scattering): Call

Re: [libgomp] task scheduler rewrite and task priorities implementation

On 10/29/2015 08:46 AM, Aldy Hernandez wrote: Yo! As promised, here is the work implementing a new API for the task scheduler, rewriting the scheduler to fit into this new API, and implementing the task priorities that are in OpenMP > 4.1. There are also lots of cleanups and documentation.

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/67749: Do not emit separate SET insn in IF-ELSE case

On 11/03/2015 02:09 AM, Kyrill Tkachov wrote: Hi Jeff, On 02/11/15 22:46, Jeff Law wrote: On 10/27/2015 08:49 AM, Kyrill Tkachov wrote: Hi all, This patch fixes the gcc.dg/ifcvt-2.c test for x86_64 where we were failing to if-convert. This was because in my patch at

[PATCH] Allow vrp to thread across backedges using FSM threader

This is in preparation for removing a blob of code in the old threader that knew how to thread across backedges. Essentially this just allows us to try FSM threading in VRP's instance of threader. So certain jump threading happens earlier in the pipeline. It also tightens up the

[gomp4] revert fortran declare changes

This patch reverts the declare cleanups I introduced in . Notably, I deleted resolve_omp_duplicate_list and resolve_oacc_declare_map. Jim, I also reverted my changes to declare-2.f95. Please make the error messages consistent with the rest

Re: [PATCH] i386: Use the STC bb-reorder algorithm at -Os (PR67864)

Adding x86 maintainer, ping? On Fri, Oct 16, 2015 at 05:53:41AM -0700, Segher Boessenkool wrote: > For x86, STC still gives better results for optimise-for-size than > "simple" does. So use STC at -Os as well. > > Is this okay for trunk? > > > Segher > > > 2015-10-16 Segher Boessenkool

Re: regrename: Fix for earlyclobber operands

On 11/06/2015 08:30 PM, Jeff Law wrote: * regrename.c (record_out_operands): Terminate earlyclobbered operands here. Do you want to terminate those chains after step 6 is complete so that the earlyclobber output conflicts with all the other outputs? I'm not sure what you mean by your

[gomp4] backport trunk FE changes

I've applied this patch to gomp-4_0-branch which backports most of my front end changes from trunk. Note that I found a regression while testing, which is also present in trunk. It looks like kernels-acc-loop-reduction.c is failing because I'm incorrectly propagating the reduction variable to both

[PATCH 2/2] add original schedule to scop

From: Abderrazek Zaafrani * graphite-optimize-isl.c (optimize_isl): Call isl_union_map_is_equal. * graphite-poly.c (new_scop): Initialize original_schedule. (free_scop): Free original_schedule. * graphite-poly.h (struct scop): Add field original_schedule.

libgo patch committed: Fix unexported embedded structs

There has been a long-standing discrepancy between the gc and the gccgo Go compilers in their handling of the type descriptors for unexported embedded structs. gccgo correctly records a PkgPath for the package where those embedded structs are defined. gc does not. The Go libraries are written

Re: [PATCH v3 1/2] [PR debug/67192] Fix C loops' back-jump location

On 11/04/2015 09:17 AM, Andreas Arnez wrote: Since r223098 ("Implement -Wmisleading-indentation") the backward-jump generated for a C while- or for-loop can get the wrong line number. This is because the check for misleading indentation peeks ahead one token, advancing input_location to after

Re: Move const char * -> int/fp folds to fold-const-call.c

On 11/06/2015 08:22 AM, Richard Sandiford wrote: This patch moves folds that deal with constant string arguments and return a constant integer or floating-point value. For example, it handles strcmp ("foo", "bar") but not strstr ("foobar", "bar"), which wouldn't currently be accepted by the

[PATCH] Remove more backedge threading support

This removes the last bits of code to thread through backedges using the old threader. Behaviour is essentially the same, except some shuffling of code to ensure we always fall back to the FSM threader if a backedge is found. Bootstrapped and regression tested on x86_64-linux-gnu.

[PATCH/RFC] C++ FE: expression ranges (work in progress)

Caveat: this patch is a work-in-progress, but I thought it was worth posting to check that the concept is OK. This patch builds on top of the patch kit: "[PATCH 00/10] Overhaul of diagnostics (v5)" https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02536.html of which patches 1-4 are now in trunk.

Re: [PATCH] x86 interrupt attribute

On 11/06/2015 03:19 PM, H.J. Lu wrote: On Fri, Nov 6, 2015 at 7:31 AM, Uros Bizjak wrote: On Fri, Nov 6, 2015 at 3:07 PM, Yulia Koval wrote: Hi, I updated and reposted the patch. Regtested/bootstraped on x86_64/Linux and i686/Linux. Ok for trunk?

Re: regrename: Fix for earlyclobber operands

On 11/06/2015 04:04 PM, Bernd Schmidt wrote: On 11/06/2015 08:30 PM, Jeff Law wrote: * regrename.c (record_out_operands): Terminate earlyclobbered operands here. Do you want to terminate those chains after step 6 is complete so that the earlyclobber output conflicts with all the other

Re: [PATCH v3 2/2] [PR debug/67192] Further fix C loops' back-jump location

On 11/04/2015 09:18 AM, Andreas Arnez wrote: After parsing an unconditional "while"- or "for"-loop, the C front-end generates a backward-goto statement and implicitly sets its location to the current input_location. But in some cases the parser peeks ahead first, such that input_location

Re: [hsa 7/12] Disabling the vectorizer for GPU kernels/functions

On Thu, 5 Nov 2015, Martin Jambor wrote: > Hi, > > in the previous email I wrote we need to "change behavior" of a few > optimization passes. One was the flattening of GPU functions and the > other two are in the patch below. It all comes to that, at the > moment, we need to switch off the

Re: [hsa 9/12] Small alloc-pool fix

On Fri, 6 Nov 2015, Martin Liška wrote: > On 11/06/2015 10:00 AM, Richard Biener wrote: > > On Thu, 5 Nov 2015, Martin Jambor wrote: > > > >> Hi, > >> > >> we use C++ new operators based on alloc-pools a lot in the subsequent > >> patches and realized that on the current trunk, such new

Re: [PATCH] Add configure flag for operator new (std::nothrow)

On 11/06/2015 01:56 AM, Jonathan Wakely wrote: > On 5 November 2015 at 23:31, Daniel Gutson >> The issue is, as I understand it, to do the actual work of operator >> new, i.e. allocate memory. It should force >> us to copy most of the code of the original code of operator new, >> which may change

Re: Merge of HSA branch

On 11/05/2015 10:51 PM, Martin Jambor wrote: Individual changes are described in slightly more detail in their respective messages. If you are interested in how the HSAIL generation works in general, I encourage you to have a look at my Cauldron slides or presentation, only very few things have

Re: [PATCH] PR driver/67613 - spell suggestions for misspelled command line options

On 11/04/2015 03:53 PM, David Malcolm wrote: This patch adds hints to the option-not-found error in the driver, using the Levenshtein distance implementation posted here: "[PATCH 0/2] Levenshtein-based suggestions (v3)" https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03379.html It splits out

Re: [PATCH 6/6] Make SRA replace constant-pool loads

> Hmm, can you clarify, do you mean I should *not* replace constant pool > values with their DECL_INITIAL? The attempt to substitute in the > initial value is what leads to most of the problems. For example, in > gnat/opt31.adb, create_access finds this expression accessing *.LC0: > >

Re: [PATCH] Fix PR68067

On 28/10/15 13:38, Richard Biener wrote: Applied as follows. Bootstrapped / tested on x86_64-unknown-linux-gnu. Richard. 2015-10-28 Richard Biener * fold-const.c (negate_expr_p): Adjust the division case to properly avoid introducing undefined overflow.

Re: Merge of HSA branch

On Fri, 6 Nov 2015, Bernd Schmidt wrote: > On 11/05/2015 10:51 PM, Martin Jambor wrote: > > Individual changes are described in slightly more detail in their > > respective messages. If you are interested in how the HSAIL > > generation works in general, I encourage you to have a look at my > >

Re: Re: [PATCH] Fix PRs 66502 and 67167

On 21/08/15 10:47, Jiong Wang wrote: Richard Biener writes: I see the following ICE: t.c:13:1: internal compiler error: in decompose_normal_address, at rtlanal.c:6090 } ^ 0xc94a37 decompose_normal_address /space/rguenther/tramp3d/trunk/gcc/rtlanal.c:6090 0xc94d25

Re: [hsa 9/12] Small alloc-pool fix

On Thu, 5 Nov 2015, Martin Jambor wrote: > Hi, > > we use C++ new operators based on alloc-pools a lot in the subsequent > patches and realized that on the current trunk, such new operators > would needlessly call the placement ::new operator within the allocate > method of pool-alloc. Fixed

[PATCH] Fix PR ipa/68035

Hello. Following patch triggers hash calculation of items (functions and variables) in situations where LTO mode is not utilized. Patch survives regression tests and bootstraps on x86_64-linux-pc. Ready for trunk? Thanks, Martin >From 62266e21a89777c6dbd680f7c87f15abe603c024 Mon Sep 17 00:00:00

[PATCH] Make BB vectorizer work on sub-BBs

The following patch makes the BB vectorizer not only handle BB heads (until the first stmt with a data reference it cannot handle) but arbitrary regions in a BB separated by such stmts. This improves the number of BB vectorizations from 469 to 556 in a quick test on SPEC CPU 2006 with -Ofast on

Re: [hsa 9/12] Small alloc-pool fix

On 11/06/2015 10:00 AM, Richard Biener wrote: > On Thu, 5 Nov 2015, Martin Jambor wrote: > >> Hi, >> >> we use C++ new operators based on alloc-pools a lot in the subsequent >> patches and realized that on the current trunk, such new operators >> would needlessly call the placement ::new operator

[PATCH] Fix transform_to_exit_first_loop_alt with -g

Hi, This patch fixes a problem with -g compilation in transform_to_exit_first_loop_alt. Consider test-case test.c: ... void f (int *a, int n) { int i; for (i = 0; i < n; ++i) a[i] = 1; } ... If we add a "checking_verify_ssa (true, true)" call at the end of

Re: [hsa 5/12] New HSA-related GCC options

On Thu, 5 Nov 2015, Martin Jambor wrote: > Hi, > > the following small part of the merge deals with new options. It adds > four independent things: > > 1) flag_disable_hsa is used by code in opts.c (in the first patch) to >remember whether HSA has been explicitely disabled on the compiler

Re: [Patch ifcvt] Teach RTL ifcvt to handle multiple simple set instructions

On 4 November 2015 at 16:37, James Greenhalgh wrote: > > On Wed, Nov 04, 2015 at 12:04:19PM +0100, Bernd Schmidt wrote: >> On 10/30/2015 07:03 PM, James Greenhalgh wrote: >> >+ i = tmp_i; <- Should be cleaned up >> >> Maybe reword as "Subsequent passes are expected

Re: [PATCH] PR67518 and PR53852 -- add testcase.

Dear Joost, These two testcases look fine to me. PR53852 is marked as being a 4.9,5,6 regression. If I have understood correctly, it has only been fixed on trunk. Do you know if there is any intention to fix it on the other branches? OK for trunk and, subject to the previous question being

RE: [PATCH] PR67518 and PR53852 -- add testcase.

Thanks Paul. I believe PR53852 won't be fixed on 4.9/5 as it seems to depend on the recent graphite cleanup work and recent isl. As such I'll commit to trunk only.

Re: [PATCH] Fix PR68067

On Fri, 6 Nov 2015, Alan Lawrence wrote: > On 28/10/15 13:38, Richard Biener wrote: > > > > Applied as follows. > > > > Bootstrapped / tested on x86_64-unknown-linux-gnu. > > > > Richard. > > > > 2015-10-28 Richard Biener > > > > * fold-const.c (negate_expr_p):

[gomp4] Re: [1/3] OpenACC reductions

Hi Nathan! On Mon, 2 Nov 2015 11:18:37 -0500, Nathan Sidwell wrote: > This is the core execution bits of OpenACC reductions. > One thing not handled by this patch are reductions of variables of reference > type. We have an implementation on gomp4 branch [...] Trying to keep

[PATCH][ARM] PR 68143 Properly update memory offsets when expanding setmem

Hi all, In this wrong-code PR the vector setmem expansion and arm_block_set_aligned_vect in particular use the wrong offset when calling adjust_automodify_address. In the attached testcase during the initial zeroing out we get two V16QI stores, but they both are recorded by

Re: [patch] fix regrename pass to ensure renamings produce valid insns

On 06/17/2015 07:11 PM, Sandra Loosemore wrote: Index: gcc/regrename.c === --- gcc/regrename.c (revision 224532) +++ gcc/regrename.c (working copy) @@ -942,19 +942,22 @@ regrename_do_replace (struct du_head *he int

[gomp4] Re: [3/3] OpenACC reductions

Hi Nathan! On Mon, 2 Nov 2015 11:38:47 -0500, Nathan Sidwell wrote: > This patch are the initial set of tests. The libgomp tests use an idiom of > summing thread identifiers and then checking the expected set of threads > participated. They are all derived from the loop tests

[gomp4] Re: [2/3] OpenACC reductions

Hi Nathan! On Wed, 4 Nov 2015 11:59:28 -0500, Nathan Sidwell wrote: > [PTX backend pieces of OpenACC reduction handling] Merged your trunk r229768 into gomp-4_0-branch in r229836: commit 089a0224af68e30b55f42734de48adc645eb7370 Merge: 2b76127 78a78aa Author: tschwinge

Re: Merge of HSA branch

On 11/06/2015 11:12 AM, Bernd Schmidt wrote: > On 11/05/2015 10:51 PM, Martin Jambor wrote: >> Individual changes are described in slightly more detail in their >> respective messages. If you are interested in how the HSAIL >> generation works in general, I encourage you to have a look at my >>

regrename: Fix for earlyclobber operands

I have a patch which makes use of the renamer more often, and this exposed a bug with earlyclobber operands. The code that does the terminate_write step has the following comment: /* Step 5: Close open chains that overlap writes. Similar to step 2, we hide in-out

Re: improved RTL-level if conversion using scratchpads [half-hammock edition]

On 11/06/2015 12:43 AM, Abe wrote: Feedback from Bernd has also been applied. But inconsistently, and I think not quite in the way I meant it in one case. -/* Return true if a write into MEM may trap or fault. */ - static bool noce_mem_write_may_trap_or_fault_p (const_rtx mem) { -

Re: Merge of HSA branch

On 11/06/2015 11:30 AM, Richard Biener wrote: On Fri, 6 Nov 2015, Bernd Schmidt wrote: Realistically we're probably not going to reject this work, but I still want to ask whether the approach was acked by the community before you started. I'm really not exactly thrilled about having two

Re: [PATCH] Make BB vectorizer work on sub-BBs

On Fri, 6 Nov 2015, Richard Biener wrote: > > The following patch makes the BB vectorizer not only handle BB heads > (until the first stmt with a data reference it cannot handle) but > arbitrary regions in a BB separated by such stmts. > > This improves the number of BB vectorizations from 469

regrename: don't overflow insn_rr_info

This one is a fix for something that could currently only affect c6x, but I have code that exposes it on i386. When optionally gathering operand info in regrename, we can overflow the array in certain situations. This can occur when we have a situation where a value is constructed in multiple

Re: regrename: don't overflow insn_rr_info

On 06/11/15 11:08, Bernd Schmidt wrote: > This one is a fix for something that could currently only affect c6x, but I > have code that exposes it on i386. > > When optionally gathering operand info in regrename, we can overflow the > array in certain situations. This can occur when we have a

Re: [PATCH] Fix PR68067

On Fri, 6 Nov 2015, Alan Lawrence wrote: > On 06/11/15 10:39, Richard Biener wrote: > > > ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error: > > > location > > > references block not in block tree > > > l1_279 = PHI <1(28), l1_299(33)> > > > > ^^^ > > > > this is the error to

Re: libgo patch committed: Update to Go 1.5 release

Ian Lance Taylor writes: > I have committed a patch to libgo to update it to the Go 1.5 release. > > As usual for libgo updates, the actual patch is too large to attach to > this e-mail message. I've attached the changes to the gccgo-specific > files. > > Bootstrapped and ran

Re: [openacc] tile, independent, default, private and firstprivate support in c/++

On 11/06/15 01:50, Jakub Jelinek wrote: On Thu, Nov 05, 2015 at 06:10:49PM -0800, Cesar Philippidis wrote: I've applied this patch to trunk. It also includes the fortran and template changes. Note that there is a new regression in gfortran.dg/goacc/combined_loop.f90. Basically, the gimplifier

Re: [gomp4 06/14] omp-low: copy omp_data_o to shared memory on NVPTX

On Fri, Nov 06, 2015 at 03:00:30PM +0100, Bernd Schmidt wrote: > >Sanity-checked by running the libgomp testsuite. I realize the #ifdef in > >internal-fn.c is not appropriate: it's there to make the patch smaller, I'll > >replace it with a target hook if otherwise this approach is ok. > > FWIW,

Re: [gomp4 05/14] omp-low: set 'omp target entrypoint' only on entypoints

On 10/30/2015 05:44 PM, Alexander Monakov wrote: + /* Ignore "omp target entrypoint" here: OpenMP target region functions are + called from gomp_nvptx_main. The corresponding kernel entry is emitted + from write_omp_entry. */ } I'm probably confused, but didn't we agree that this

Re: [PATCH][ARM/AArch64] PR 68088: Fix RTL checking ICE due to subregs inside accumulator forwarding check

On 11/06/2015 08:09 PM, Kyrill Tkachov wrote: On 06/11/15 17:07, Nikolai Bozhenov wrote: On 11/06/2015 04:46 PM, Ramana Radhakrishnan wrote: Hi! I faced the same issue but I had somewhat different RTL for the consumer: (insn 20 15 21 2 (set (reg/i:SI 0 r0) (minus:SI

Re: regrename: don't overflow insn_rr_info

On 11/06/2015 12:17 PM, Ramana Radhakrishnan wrote: On 06/11/15 11:08, Bernd Schmidt wrote: This one is a fix for something that could currently only affect c6x, but I have code that exposes it on i386. When optionally gathering operand info in regrename, we can overflow the array in certain

RE: [PATCH, MIPS, PR/61114] Migrate to reduc_..._scal optabs.

Committed r229844. Thanks, Simon > -Original Message- > From: Moore, Catherine [mailto:catherine_mo...@mentor.com] > Sent: 03 November 2015 14:09 > To: Simon Dardis; Alan Lawrence; Matthew Fortune > Cc: gcc-patches@gcc.gnu.org > Subject: RE: [PATCH, MIPS, PR/61114] Migrate to

Re: [PATCH] Fix PR68067

On 06/11/15 10:39, Richard Biener wrote: ../spec2000/benchspec/CINT2000/254.gap/src/polynom.c:358:11: error: location references block not in block tree l1_279 = PHI <1(28), l1_299(33)> ^^^ this is the error to look at! It means that the GC heap will be corrupted quite easily. Thanks, I'll

Re: [PATCH] Fix PR ipa/68035

On Fri, Nov 6, 2015 at 10:10 AM, Martin Liška wrote: > Hello. > > Following patch triggers hash calculation of items (functions and variables) > in situations where LTO mode is not utilized. > > Patch survives regression tests and bootstraps on x86_64-linux-pc. Why does that make

Re: [PATCH PR52272]Be smart when adding iv candidates

On Wed, Nov 4, 2015 at 11:18 AM, Bin Cheng wrote: > Hi, > PR52272 reported a performance regression in spec2006/410.bwaves once GCC is > prevented from representing address of one memory object using address of > another memory object. Also as I commented in that PR, we have

Remove noce_mem_write_may_trap_or_fault_p in ifcvt

The ifcvt scratchpad patch had some modifications to the function noce_mem_write_may_trap_or_fault_p in ifcvt, but as far as I can tell, that function itself makes no sense whatsoever. It returns true for MEM_READONLY_P which is sensible, but then it also goes on an unreliable search through

[Patch] Change to argument promotion in fixed conversion library calls

This is part one of a two part patch I want to checkin in order to improve argument passing on MIPS. Right now MIPS defines TARGET_PROMOTE_PROTOTYPES as true and so short and char arguments are getting promoted in the caller and callee functions. The ABI requires callers to do the promotion and

Re: [OpenACC] declare directive

On Fri, Nov 06, 2015 at 10:08:26AM -0600, James Norris wrote: > 2015-10-27 James Norris > Joseph Myers > > gcc/ > * c-family/c-pragma.c (oacc_pragmas): Add entry for declare directive. > * c-family/c-pragma.h

Re: [Patch] Change to argument promotion in fixed conversion library calls

On 11/06/2015 08:04 PM, Steve Ellcey wrote: When I made this change I had one regression in the GCC testsuite (gcc.dg/fixed-point/convert-sat.c). I tracked this down to the fact that emit_library_call_value_1 does not do any argument promotion because it does not have the original tree type

Handle internal functions in is_tm_pure_call

The upcoming changes to use internal functions for things like sqrt caused a failure in gcc.dg/tm/20100610.c, because we were trying to get call flags from the null gimple_call_fn of an IFN_SQRT call. We've been making fairly heavy use of internal functions for a while now so I think this might

Re: libgo patch committed: Update to Go 1.5 release

On Fri, Nov 6, 2015 at 5:01 AM, Rainer Orth wrote: > Ian Lance Taylor writes: > >> I have committed a patch to libgo to update it to the Go 1.5 release. >> >> As usual for libgo updates, the actual patch is too large to attach to >> this e-mail

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

On 11/06/2015 11:44 AM, Bernd Schmidt wrote: On 11/06/2015 07:39 PM, Jeff Law wrote: Given the name "..may_trap_or_fault_p" ISTM that its mode of operation should be to return true (the safe value) unless we can prove the write will not fault. The more cases we can prove true, the better

Re: [Patch] Change to argument promotion in fixed conversion library calls

On Fri, 2015-11-06 at 20:14 +0100, Bernd Schmidt wrote: > > > + if (SCALAR_INT_MODE_P (from_mode)) > > +{ > > + /* If we need to promote the integer function argument we need to do > > Extra space at the start of the comment. > > > + it here instead of inside

Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

On 11/06/2015 08:20 PM, Jeff Law wrote: So maybe what noce_mem_write_may_trap_or_fault_p is really trying to do is take objects where may_trap_or_fault_p returns false, but which in fact may fault if we write that memory? ie, working around lameness in may_trap_or_fault_p not knowing the

Re: regrename: Fix for earlyclobber operands

On 11/06/2015 03:54 AM, Bernd Schmidt wrote: I have a patch which makes use of the renamer more often, and this exposed a bug with earlyclobber operands. The code that does the terminate_write step has the following comment: /* Step 5: Close open chains that overlap writes. Similar

Re: [Patch] Change to argument promotion in fixed conversion library calls

On 11/06/2015 08:27 PM, Steve Ellcey wrote: Are you thinking of a simple function that is called on all targets or a target specific function? Maybe a target specific function would be safer. No, I think just what you have there is probably sufficient. Bernd

Re: [OpenACC] declare directive

On Fri, Nov 06, 2015 at 08:03:52PM +0100, Jakub Jelinek wrote: > What exactly do you want to achieve? Why do you record it > in gimplify_omp_ctx, but then only look at it in gimplify_body? > The way you abuse gimplify_omp_ctx for that is just too ugly. > All the gimplification code expects that

Re: Handle internal functions in is_tm_pure_call

On 11/06/2015 12:15 PM, Richard Sandiford wrote: The upcoming changes to use internal functions for things like sqrt caused a failure in gcc.dg/tm/20100610.c, because we were trying to get call flags from the null gimple_call_fn of an IFN_SQRT call. We've been making fairly heavy use of

Re: OpenACC declare directive updates

On Wed, Nov 04, 2015 at 06:32:00AM -0600, James Norris wrote: > +/* Node in the linked list used for storing !$oacc declare constructs. */ > + > +typedef struct gfc_oacc_declare > +{ > + struct gfc_oacc_declare *next; > + bool module_var; > + gfc_omp_clauses *clauses; > + gfc_omp_clauses

Re: [RFA] Do not use libiberty's getpagesize on Android

> libiberty/ChangeLog: > > * configure.ac: Set AC_CV_FUNC_GETPAGESIZE to "yes" on > Android hosts. > * configure: Regenerate. > > OK to apply? Ok.

Re: Unreviewed patch

On 11/06/2015 06:29 AM, Rainer Orth wrote: The following patch has remained unrevied for a month: [build] Support init priority on Solaris https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00716.html It needs build and ia64 maintainers and someone familiar with the init priority

Re: [PING] Re: [PATCH] c++/67913, 67917 - fix new expression with wrong number of elements

OK. Jason

Re: improved RTL-level if conversion using scratchpads [half-hammock edition]

On 11/06/2015 03:10 PM, Sebastian Pop wrote: On Fri, Nov 6, 2015 at 2:56 AM, Bernd Schmidt wrote: Formatting problem, here and in a few other places. I didn't fully read the patch this time around. I'm probably not reviewing further patches because I don't see this

Add -fno-math-errno to gcc.dg/lto/20110201-1_0.c

At the moment the ECF_* flags for a gimple call to a built-in function are derived from the function decl, which in turn is derived from the global command-line options. So if the compiler is run with -fno-math-errno, we always assume functions don't set errno, regardless of local optimization

Don't treat rint as setting errno

builtins.def says that rint sets errno, but it looks like this might be a mistake. C99 says that rint doesn't set errno and the builtins.c expansion code doesn't try to keep errno up to date. Perhaps this was because earlier versions of POSIX said that rint sets errno on overflow:

Move c_getstr to fold-const.c

Upcoming patches to fold-const-call.c want to use c_getstr, which is currently defined in builtins.c. The function doesn't really do anything related to built-ins, and I'd rather not make fold-const-call.c depend on builtins.c and builtins.c depend on fold-const-call.c, so this patch moves the

[gomp4, committed] Revert "Add dom_walker::walk_until"

Hi, this patch reverts the "Add dom_walker::walk_until" patch. The dom_walker::walk_until functionality is no longer required now that we've reverted pass_dominator::sese_mode_p. Committed to gomp-4_0-branch. Thanks, - Tom Revert "Add dom_walker::walk_until" 2015-11-06 Tom de Vries

[gomp4, committed] Fix double word typo in tree-inline.c

Hi, reverting a patch in tree-inline.c in gomp-4_0-branch exposed a typo already fixed on trunk. This patch fixes that. Committed to gomp-4_0-branch. Thanks, - Tom 2015-11-06 Tom de Vries backport from trunk: 2015-07-12 Aldy Hernandez *

Handle constant fp classifications in fold-const-call.c

Move the constant "is finite", "is infinite" and "is nan" queries to fold-const-call.c. Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi. OK to install? Thanks, Richard gcc/ * builtins.c (fold_builtin_classify): Move constant cases to... * fold-const-call.c

Move constant bitop and bswap folds to fold-const-call.c

The only folds left in builtins.c were for constants, so we can remove the builtins.c handling entirely. Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi. OK to install? Thanks, Richard gcc/ * builtins.c (fold_builtin_bitop, fold_builtin_bswap): Delete.

Re: Move c_getstr to fold-const.c

On 11/06/2015 04:05 PM, Richard Sandiford wrote: Upcoming patches to fold-const-call.c want to use c_getstr, which is currently defined in builtins.c. The function doesn't really do anything related to built-ins, and I'd rather not make fold-const-call.c depend on builtins.c and builtins.c

Re: Don't treat rint as setting errno

On 11/06/2015 04:02 PM, Richard Sandiford wrote: builtins.def says that rint sets errno, but it looks like this might be a mistake. C99 says that rint doesn't set errno and the builtins.c expansion code doesn't try to keep errno up to date. [snip explanation of the history] FWIW the manpage

Small C++ PATCH to clean up non-type template parameter handling

The old code here laments not being able to reuse the CONST_DECL created by process_template_parm, but we can get to it from the TEMPLATE_PARM_INDEX. Tested x86_64-pc-linux-gnu, applying to trunk. commit 02af5bca9bd6dbd3080bef614e411c56303d3c66 Author: Jason Merrill Date:

Re: [PING 2] [PATCH] c++/67942 - diagnose placement new buffer overflow

On 11/06/2015 05:55 AM, Rainer Orth wrote: Martin Sebor writes: If we use gcc_checking_assert it won't fire in release builds; let's go with that. Okay. Attached is an updated patch with that change. Unfortunately, this breaks i386-pc-solaris2.10 bootstrap:

Move #undef DEF_INTERNAL_FN to internal-fn.def

In practice the definition of DEF_INTERNAL_FN is never reused after including internal-fn.def, so we might as well #undef it there. This becomes more obvious with a later patch that adds other DEF_INTERNAL_* directives, such as DEF_INTERNAL_OPTAB_FN. If the includer doesn't care about the

Move const char * -> int/fp folds to fold-const-call.c

This patch moves folds that deal with constant string arguments and return a constant integer or floating-point value. For example, it handles strcmp ("foo", "bar") but not strstr ("foobar", "bar"), which wouldn't currently be accepted by the gimple folders. The builtins.c folding for strlen

Re: [PATCH] x86 interrupt attribute

On Fri, Nov 6, 2015 at 3:07 PM, Yulia Koval wrote: > Hi, > > I updated and reposted the patch. Regtested/bootstraped on > x86_64/Linux and i686/Linux. Ok for trunk? This version still emits insns from ix86_function_arg, so NAK. Uros.

Re: [PATCH] gcc/config.gcc: fix typo for powerpc e6500 cpu_is_64bit

2015-11-06 Arnout Vandecappelle * gcc/config.gcc: fix typo for powerpc e6500 cpu_is_64bit For GCC, please don't send ChangeLog entries as diffs. Applied. Thanks. - David

Move #undef DEF_BUILTIN* to builtins.def

I was confused at first why tree-core.h was undefining DEF_BUILTIN_CHKP before defining it, then undefining it again after including builtins.def. This is because builtins.def provides a default definition of DEF_BUILTIN_CHKP, but leaves it up to the caller to undefine it where necessary.

Re: improved RTL-level if conversion using scratchpads [half-hammock edition]

On Fri, Nov 6, 2015 at 6:32 AM, Bernd Schmidt wrote: > On 11/06/2015 03:10 PM, Sebastian Pop wrote: >> >> On Fri, Nov 6, 2015 at 2:56 AM, Bernd Schmidt wrote: >>> >>> Formatting problem, here and in a few other places. I didn't fully read >>> the >>>

C++ PATCH for non-type constrained-type-specifiers

I started looking at allowing non-type constrained-type-specifiers in auto deduction and then realized that we didn't handle them in function parameters either. Fixing that brought home to me the oddity of having a type-specifier stand in for a non-type. Mind weighing in on that on the core

Re: Handle constant fp classifications in fold-const-call.c

On 11/06/2015 04:08 PM, Richard Sandiford wrote: Move the constant "is finite", "is infinite" and "is nan" queries to fold-const-call.c. I kind of missed it when that file was added, but I'm assuming it's the correct direction for things to move. Ok. Bernd

[Obivous][testsuite,aarch64/arm] Fix typo

Hi, I've committed the attached fix for a comment in gcc.target/aarch64/advsimd-intrinsics/vtbX.c. (as revision 229858) Christophe. 2015-11-06 Christophe Lyon * gcc.target/aarch64/advsimd-intrinsics/vtbX.c: Fix typos in comment.

Re: [OpenACC] declare directive

Thomas, I've added the issues that you pointed out. Attached is the updated patch and ChangeLog. Thanks for taking the time for your review! Jakub, Could you queue this patch ahead of my other one for today? If it doesn't pass review, I'd like to work the weekend and have the updated patch

  1   2   3   >