[hsa 3/10] HSA libgomp plugin

2015-12-07 Thread Martin Jambor
Hi, the patch below adds the HSA-specific plugin for libgomp. The plugin implements the interface mandated by libgomp and takes care of finding any available HSA devices, finalizing HSAIL code and running it on HSA-capable GPUs. The plugin does not really implement any data movement functions (i

[hsa 2/10] Modifications to libgomp proper

2015-12-07 Thread Martin Jambor
Hi, The patch below contains all changes to libgomp files except for the hsa plugin (which is in the following patch). The changes can roughly divided into three categories. First, it contains changes I that are necessary to support shared-memory devices. In majority of cases this means treatin

[hsa 1/10] Configury changes and new options

2015-12-07 Thread Martin Jambor
Hi, this patch contains changes to the configuration mechanism and offload bits, so that users can build compilers with HSA support. It plays nicely with other accelerators despite using an altogether different implementation approach. I have also added to it definitions of the new options and pa

[hsa 0/10] Merge of HSA branch

2015-12-07 Thread Martin Jambor
Hi, I'm sorry it took me more than a month to come up with another round of patches aiming at merging the HSA branch into the trunk. Keeping up-to date with the latest changes in the OpenMP 4.5 area was strenuous and we have discovered and fixed a few bugs as I intensified my testing efforts. Wh

Re: [AArch64] Rework ARMv8.1 command line options.

2015-12-07 Thread Matthew Wahab
Ping. Updated patch attached. Matthew On 27/11/15 09:23, Matthew Wahab wrote: On 24/11/15 15:22, James Greenhalgh wrote: > On Mon, Nov 16, 2015 at 04:31:32PM +, Matthew Wahab wrote: >> >> The command line options for target selection allow ARMv8.1 extensions >> to be individually enable

Re: [PATCH PR68542]

2015-12-07 Thread Yuri Rumyantsev
Richard! Here is middle-end part of patch with changes proposed by you. Is it OK for trunk? Thanks. Yuri. ChangeLog: 2015-12-07 Yuri Rumyantsev PR middle-end/68542 * fold-const.c (fold_relational_const): Add handling of vector comparison with boolean result. * tree-cfg.c (verify_gimple_comp

Re: [PATCH] enable loop fusion on isl-15

2015-12-07 Thread Richard Biener
On Fri, Dec 4, 2015 at 8:59 PM, Sebastian Paul Pop wrote: > I would highly recommend updating the required version of ISL to isl-0.15: > that would simplify the existing code, removing a lot of code under "#ifdef > old ISL", > and allow us to fully transition to schedule_trees instead of dealing w

Re: [PATCH] Adjust vect-widen-mult-const-[su]16.c for r226675

2015-12-07 Thread Richard Biener
On Fri, Dec 4, 2015 at 8:51 PM, Bill Schmidt wrote: > Since r226675, we have been seeing these failures: > > FAIL: gcc.dg/vect/vect-widen-mult-const-s16.c -flto -ffat-lto-objects > scan-tree-dump-times vect "pattern recognized" 2 > FAIL: gcc.dg/vect/vect-widen-mult-const-s16.c scan-tree-dump-times

[PATCH][ARM] PR target/68648: Fold NOT of CONST_INT in andsi_iorsi3_notsi splitter

2015-12-07 Thread Kyrill Tkachov
Hi all, In this PR we ICE because during post-reload splitting we generate the insn: (insn 27 26 11 2 (set (reg:SI 0 r0 [orig:121 D.4992 ] [121]) (and:SI (not:SI (const_int 1 [0x1])) (reg:SI 0 r0 [orig:121 D.4992 ] [121]))) (nil)) The splitter at fault is andsi_iorsi3_n

Re: [PATCH] Fix missing range information for "%q+D" format code

2015-12-07 Thread Bernd Schmidt
On 12/04/2015 10:09 PM, David Malcolm wrote: Updated patch to comment attached, which rewrites things to clarify the meaning of SHOW_CARET_P. I guess this is OK for now. I think I'll go play with the Fortran frontend a bit to see what exactly is going on with its use of set_range there, I sti

Re: [PATCH] Fix -Werror= handling for Joined warnings, add a few missing Warning keywords (PRs c/48088, c/68657)

2015-12-07 Thread Bernd Schmidt
On 12/04/2015 08:36 PM, Jakub Jelinek wrote: On Fri, Dec 04, 2015 at 06:19:19PM +, Manuel López-Ibáñez wrote: My guess is that the first error_at should use arg instead of option->opt_text to be equivalent. Of course, ideally, this code would not be duplicated, but rather merged "somehow".

Re: [patch] Fix PR middle-end/68291 & 68292

2015-12-07 Thread Bernd Schmidt
On 12/07/2015 10:35 AM, Eric Botcazou wrote: As discussed with Alexandre in the audit trail, the attached minimal fix just prevents the problematic BLKmode REG from being generated, which appears to be sufficient to restore the nominal operating mode. PR middle-end/68291 PR mi

Re: [Fortran, Patch] Memory sync after coarray image control statements and assignment

2015-12-07 Thread Tobias Burnus
I wrote: > I wonder whether using > > __asm__ __volatile__ ("":::"memory"); > > would be sufficient as it has a way lower overhead than > __sync_synchronize(). Namely, something like the attached patch. Regarding the original patch submission: Is there a reason that you didn't include the test c

[patch] Fix PR middle-end/68291 & 68292

2015-12-07 Thread Eric Botcazou
Hi, it's a couple of regressions in the C testsuite present on SPARC 64-bit and coming from the new coalescing code which fails to handle vector types with BLKmode that are returned in multiple registers. The code assigns a BLKmode REG to the RESULT_DECL of the function in expand_function_star

RE: [PATCH][ARC] Refurbish emitting DWARF2 for epilogue.

2015-12-07 Thread Claudiu Zissulescu
Hi Joern, > > + insn = emit_insn (gen_blockage ()); > > Is this actually part of the patch to fix cfi generation? This instruction prevents the delay branch scheduler to speculatively use epilogue instructions to fill up the delay slots. Hence, generating an assert during dwarf2cfi execut

Re: [Fortran, Patch] Memory sync after coarray image control statements and assignment

2015-12-07 Thread Alessandro Fanfarillo
Hi, 2015-12-07 8:20 GMT+01:00 Tobias Burnus : > Always - or only with optimization? > Only with optimization. > I wonder whether using > > __asm__ __volatile__ ("":::"memory"); > > would be sufficient as it has a way lower overhead than > __sync_synchronize(). > > > That would be something like:

Re: [PATCH 1/2] Fix minor glitches with basic asm

2015-12-07 Thread Richard Biener
On Sun, 6 Dec 2015, Bernd Edlinger wrote: > > Hi, > > while looking at the handling of basic asm statements > I noticed two minor glitches, which I want to fix now. > > First there is a missing check in compare_gimple_asm in ipa-icf-gimple.c > > Here we check if two asm statements are exactly

Re: [PATCH 2/2] Fix minor glitches with basic asm

2015-12-07 Thread Richard Biener
On Sun, 6 Dec 2015, Bernd Edlinger wrote: > > Hi, > > while looking at the handling of basic asm statements > I noticed two minor glitches, which I want to fix now. > > Secondly there is a wrong check in shorten_branches in final.c > > Here we check if GET_CODE (body) == ASM_INPUT, that is > n

Re: [PATCH][1/2] Fix PR68553

2015-12-07 Thread Richard Biener
On Fri, 4 Dec 2015, Alan Lawrence wrote: > On 04/12/15 17:46, Ramana Radhakrishnan wrote: > > > > > > On 04/12/15 16:04, Richard Biener wrote: > > > On December 4, 2015 4:32:33 PM GMT+01:00, Alan Lawrence > > > wrote: > > > > On 27/11/15 08:30, Richard Biener wrote: > > > > > > > > > > This is

Re: -fstrict-aliasing fixes 6/6: permit inlining of comdats

2015-12-07 Thread Richard Biener
On Fri, 4 Dec 2015, Jan Hubicka wrote: > Hi, > this is the patch for fold-const.c. Can you think of some testcase for the > MR_DEPENDENCE_CLIQUE comparsion? I am not that familiar with the code to > be able to construct it :( With ICF it would involve a variant using restrict args vs. non-restric

[PING] [ARM] Use vector wide add for mixed-mode adds

2015-12-07 Thread Michael Collison
Ping. Originally posted here: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03440.html Regards, Michael Collison

Re: -fstrict-aliasing fixes 6/6: permit inlining of comdats

2015-12-07 Thread Richard Biener
On Fri, 4 Dec 2015, Jan Hubicka wrote: > > > > I wonder if you can split out the re-naming at this stage. Further > > comments below. > > OK, I will commit the renaming and ipa-icf fix separately. > > > > > Bootstrapped/regtested x86_64-linux, OK? > > > > > > I will work on some testcases for

<    1   2