Re: [PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

Hi Steve, I have a couple of questions before I have to hurry off to work: First, why is @@ -2253,22 +2253,19 @@ gfc_simplify_dim (gfc_expr *x, gfc_expr *y) gfc_expr* gfc_simplify_dot_product (gfc_expr *vector_a, gfc_expr *vector_b) { + /* If vector_a is a zero-sized array, the result

Re: New istreambuf_iterator debug check

On Wed, 24 Jan 2018 21:34:48 +0100 François Dumont wrote: > On 24/01/2018 18:53, Petr Ovtchenkov wrote: > > On Wed, 24 Jan 2018 17:39:59 +0100 > > François Dumont wrote: > > > >> Hi > >> > >>     I'd like to propose this new debug check. Comparing

libbacktrace patch committed: Fix setting str_size on PE/COFF

This libbacktrace patch fixes the setting of str_size on PE/COFF to not leave some bytes uninitialized on a 64-bit host. Committed to mainline. Ian 2018-01-24 Ian Lance Taylor * pecoff.c (coff_add): Use coff_read4, not memcpy. Index: pecoff.c

libbacktrace patch committed: Only keep 16 entries on free list

PR 68239 points out that libbacktrace can sometimes take a long time scanning the list of free memory blocks looking for one that is large enough. Since the libbacktrace memory allocator does not have to be perfect in practice, only keep the 16 largest entries on the free list. Bootstrapped and

[PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

All, The attach patch fixes a regression with dot_product and zero-sized arrays. I bootstrapped and regression tested the patch on x86_64-*-freebsd. OK to commit? 2018-01-23 Steven G. Kargl PR fortran/83998 * simplify.c (gfc_simplify_dot_product): Deal

Re: [PATCH], PR target/81550, Rewrite PowerPC loop_align test so it still tests the original target hook

On Wed, Jan 24, 2018 at 05:00:39PM -0500, Michael Meissner wrote: > Replacing 'int' with 'unsigned long' allows the test to succeed once again. I > have checked this on a big endian power8 (both 32-bit and 64-bit) and on a > little endian power8 (64-bit only), and it passes in all three

[committed] Fix jit.dg/test-alignment* (PR jit/82846)

These testcases jit-compile functions that return char, but were erroneously calling them as if they returned int. This led to errors for certain target configurations (e.g. reading from %eax (32-bit) in the harness when only %al (8-bit) had been written to in the jit-compiled function).

Re: [PATCH], PR target/81550, Rewrite PowerPC loop_align test so it still tests the original target hook

On Wed, Jan 24, 2018 at 03:19:00PM -0500, Michael Meissner wrote: > On Wed, Jan 24, 2018 at 12:35:38PM -0600, Segher Boessenkool wrote: > > Although, hrm, in your patch you also change "int i" to "long i"; that > > alone seems to be enough to fix everything? Could you check that please? > >

Go patch committed: Rationalize external symbol names

This patch to the Go frontend rationalizes the external symbol names that appear in assembler code. It changes from the ad hoc mechanisms used to date to produce a set of names that are at least somewhat more coherent. They are also more readable, after applying a simple demangling algorithms

[C++ PATCH] Don't clear TREE_CONSTANT on ADDR_EXPRs (PR c++/83993)

Hi! cxx_eval_outermost_constant_expr clears TREE_CONSTANT on ADDR_EXPRs that aren't considered by C++ constant expressions, but that breaks middle-end which relies on TREE_CONSTANT being set on ADDR_EXPR where the address is constant. The following patch just special cases ADDR_EXPR not to clear

[C++ PATCH] Fix constexpr handling of arrays with unknown bound (PR c++/83993)

Hi! In constexpr evaluation of array references for arrays with unknown bounds, we need to diagnose out of bounds accesses, but really don't know the bounds at compile time, right now GCC will see nelts as error_mark_node + 1 and will not consider them a constant expression at all. >From the

Re: Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467)

On 01/24/2018 03:24 PM, Joseph Myers wrote: > PR target/68467 is libgcc failing to build for m68k-linux-gnu > configured for ColdFire. > > Jeff has an analysis in the PR identifying the problem as resulting > from the callers of libcalls with 1-byte or 2-byte arguments wanting > to push just 1 or

Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467)

PR target/68467 is libgcc failing to build for m68k-linux-gnu configured for ColdFire. Jeff has an analysis in the PR identifying the problem as resulting from the callers of libcalls with 1-byte or 2-byte arguments wanting to push just 1 or 2 bytes on the stack, while the libcall implementations

Re: [PATCH, fortran] Support Fortran 2018 teams

On Wed, Jan 24, 2018 at 08:19:58PM +, Paul Richard Thomas wrote: > (Jakub, This is all hidden behind the -fcoarray option. To my mind > this is safe for release.) Ok from RM POV. Jakub

Re: [PATCH][PR target/83994] Fix stack-clash-protection code generation on x86

On 01/24/2018 12:11 AM, Uros Bizjak wrote: > On Wed, Jan 24, 2018 at 12:15 AM, Jeff Law wrote: >> >> pr83994 is a code generation bug in the stack-clash support that affects >> openssl (we've turned on stack-clash-protection by default for the F28 >> builds). >> >> The

Re: [PATCH], PR target/81550, Rewrite PowerPC loop_align test so it still tests the original target hook

On Wed, Jan 24, 2018 at 12:35:38PM -0600, Segher Boessenkool wrote: > Hi! > > On Wed, Jan 24, 2018 at 12:27:55AM -0500, Michael Meissner wrote: > > > > As Segher and I were discussing over private IRC, the root cause of this > > bug is > > the compiler no long generates the BDNZ instruction for

[RFC][PR82479] missing popcount builtin detection

Hi All, Here is a patch for popcount builtin detection similar to LLVM. I would like to queue this for review for next stage 1. 1. This is done part of loop-distribution and effective for -O3 and above. 2. This does not distribute loop to detect popcount (like memcpy/memmove). I dont think that

[PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

The following patch fixes both PR56010 and PR83743. PR56010 is fixed by adding an extra altname field to the RS6000_CPU table which matches the cases where the Linux kernel's AT_PLATFORM name differs from the name GCC expects. If we match on the altname, then we return the canonical name.

Re: [PATCH, fortran] Support Fortran 2018 teams

On January 24, 2018 at 1:29:12 PM, Steve Kargl (s...@troutmask.apl.washington.edu) wrote: Yes, thanks, Paul. Unfortunately, I've run out of time. Damian, GCC is in stage 3, we need to wait for approval from the release manager (aka Jakub) before committing the patch. Will do.  

Re: [PATCH, fortran] Support Fortran 2018 teams

On Wed, Jan 24, 2018 at 01:25:51PM -0800, Damian Rouson wrote: > Thank you, Paul. I think Alessandro has commit rights. > If so, then I’ll ask him to make the requested edits and commit it. > > Damian > Yes, thanks, Paul. Unfortunately, I've run out of time. Damian, GCC is in stage 3, we need

Re: [PATCH, fortran] Support Fortran 2018 teams

Thank you, Paul.   I think Alessandro has commit rights.  If so, then I’ll ask him to make the requested edits and commit it. Damian On January 24, 2018 at 12:19:58 PM, Paul Richard Thomas (paul.richard.tho...@gmail.com) wrote: Hi All, Given the delay relative to the start of stage 3, I

Re: New istreambuf_iterator debug check

On 24/01/2018 18:53, Petr Ovtchenkov wrote: On Wed, 24 Jan 2018 17:39:59 +0100 François Dumont wrote: Hi     I'd like to propose this new debug check. Comparing with non-eos istreambuf_iterator sounds like an obvious coding mistake.     I propose it despite the

Re: Add support for bitwise reductions

Jeff Law writes: > On 11/22/2017 11:12 AM, Richard Sandiford wrote: >> Richard Sandiford writes: >>> This patch adds support for the SVE bitwise reduction instructions >>> (ANDV, ORV and EORV). It's a fairly mechanical extension of existing >>>

Re: [PATCH, fortran] Support Fortran 2018 teams

Hi All, Given the delay relative to the start of stage 3, I thought that I had better deal with this asap: + /* TODO: this works on any derived type when + it should only work with team_type. */ + if (team->ts.type != BT_DERIVED) Why don't you give the team_type derived type

Re: [PATCH], PR target/81550, Rewrite PowerPC loop_align test so it still tests the original target hook

On Wed, Jan 24, 2018 at 12:35:38PM -0600, Segher Boessenkool wrote: > Hi! > > On Wed, Jan 24, 2018 at 12:27:55AM -0500, Michael Meissner wrote: > > > > As Segher and I were discussing over private IRC, the root cause of this > > bug is > > the compiler no long generates the BDNZ instruction for

Re: [PATCH] Fix gcc.target/aarch64/sve/peel_ind_1.c for -mcmodel=tiny

Szabolcs Nagy writes: > Fix test failures with -mcmodel=tiny when adr is generated instead of adrp. > > FAIL: gcc.target/aarch64/sve/peel_ind_1.c -march=armv8.2-a+sve > scan-assembler \\tadrp\\tx[0-9]+, x\\n > FAIL: gcc.target/aarch64/sve/peel_ind_2.c -march=armv8.2-a+sve >

patch to fix PR84014

The following patch fixes    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84014 The patch was tested on powerpc64 and bootstrapped on x86-64. Committed as rev. 257029. Index: ChangeLog === --- ChangeLog (revision 257028) +++

Re: [PATCH], PR target/81550, Rewrite PowerPC loop_align test so it still tests the original target hook

Hi! On Wed, Jan 24, 2018 at 12:27:55AM -0500, Michael Meissner wrote: > > As Segher and I were discussing over private IRC, the root cause of this bug > is > the compiler no long generates the BDNZ instruction for a count down loop, > instead it decrements the index in a GPR and does a

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

On January 24, 2018 6:51:54 PM GMT+01:00, Richard Biener wrote: >On January 24, 2018 6:40:25 PM GMT+01:00, Jakub Jelinek > wrote: >>On Wed, Jan 24, 2018 at 06:36:02PM +0100, Martin Jambor wrote: >>> > I think there's already a set of attributes that prevent

Re: New istreambuf_iterator debug check

On Wed, 24 Jan 2018 17:39:59 +0100 François Dumont wrote: > Hi > >     I'd like to propose this new debug check. Comparing with non-eos > istreambuf_iterator sounds like an obvious coding mistake. > >     I propose it despite the stage 1 as it is just a new debug

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

On January 24, 2018 6:40:25 PM GMT+01:00, Jakub Jelinek wrote: >On Wed, Jan 24, 2018 at 06:36:02PM +0100, Martin Jambor wrote: >> > I think there's already a set of attributes that prevent cloning >and >> > or are adjusted by the IPA param machinery. The Martins or Honza >> >

[build] Configure USE_HIDDEN_LINKONCE on Solaris/x86

Prompted by PR target/83838 (Many gcc.target/i386/indirect-thunk*.c tests FAIL), which is caused by this snippet in i386/sol2.h /* Only recent versions of Solaris 11 ld properly support hidden .gnu.linkonce sections, so don't use them. */ #ifndef USE_GLD #define USE_HIDDEN_LINKONCE 0 #endif

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

On Wed, Jan 24, 2018 at 06:36:02PM +0100, Martin Jambor wrote: > > I think there's already a set of attributes that prevent cloning and > > or are adjusted by the IPA param machinery. The Martins or Honza > > should know better. > > I am not sure I understand the problem but if >

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

On Wed, Jan 24 2018, Richard Biener wrote: > On January 24, 2018 5:16:45 PM GMT+01:00, Jakub Jelinek > wrote: >>On Wed, Jan 24, 2018 at 05:08:10PM +0100, Richard Biener wrote: >>> >The "omp declare simd" attribute refers to argument numbers of the >>> >functions, so trying to

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Tue, Dec 12, 2017 at 12:54:13AM -0200, Alexandre Oliva wrote: > +/* Check whether BLOCK, a lexical block, is nested within OUTER, or is > + OUTER itself. If BOTHWAYS, check not only that BLOCK can reach > + OUTER through BLOCK_SUPERCONTEXT links, but also that there is a > + path from

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Tue, Dec 12, 2017 at 12:52:18AM -0200, Alexandre Oliva wrote: > --- a/include/dwarf2.h > +++ b/include/dwarf2.h > @@ -298,6 +298,14 @@ enum dwarf_location_list_entry_type > DW_LLE_start_end = 0x07, > DW_LLE_start_length = 0x08, > > +/* >

Re: [aarch64][PATCH v2] Disable reg offset in quad-word store for Falkor

On Wednesday 24 January 2018 06:29 PM, Siddhesh Poyarekar wrote: >>> +  /* Avoid register indexing for 128-bit stores when the >>> + AARCH64_EXTRA_TUNE_SLOW_REGOFFSET_QUADWORD_STORE option is set.  */ >>> +  if (!optimize_size >>> +  && type == ADDR_QUERY_STR >>> +  &&

[PATCH, rs6000] Updates for vec_cmp_*() gimple-folding vector testcases

Hi, Assorted updates for the vector intrinsics / gimple folding vec_cmp() testcases to handle codegen variations as seen between P8,P9 targets. This breaks apart the testcases into a #included header that contains the testcase contents, and fold-vec-cmp-*.c tests that contain the target specific

[PATCH, rs6000] Updates for vec_abs() gimple-folding vector tests

Hi, Assorted testcase updates to handle codegen variations between P7,p8,p9. This breaks out the tests into p7,p8,p9 -specific versions of the same. Sniff-tested on multiple systems, this clears up multiple errors currently seen on P9. OK for trunk? Thanks -Will [testsuite]

[PATCH, rs6000] Updates for vec_neg() gimple-folding vector tests

Hi, Update the vec-neg-longlong folding tests to handle codegen variations as seen between p8 and p9 targets. This breaks out the tests into p7,p8,p9 versions of the same, while moving the common testcase content into a #included header. sniff-tested across power systems (P6,P8,P9) This

New istreambuf_iterator debug check

Hi     I'd like to propose this new debug check. Comparing with non-eos istreambuf_iterator sounds like an obvious coding mistake.     I propose it despite the stage 1 as it is just a new debug check, it doesn't impact the lib in normal mode.     Tested under Linux x86_64, ok to commit ?

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

On January 24, 2018 5:16:45 PM GMT+01:00, Jakub Jelinek wrote: >On Wed, Jan 24, 2018 at 05:08:10PM +0100, Richard Biener wrote: >> >The "omp declare simd" attribute refers to argument numbers of the >> >functions, so trying to apply it on versioned functions that can >>

[PATCH] Fix gcc.target/aarch64/sve/peel_ind_1.c for -mcmodel=tiny

Fix test failures with -mcmodel=tiny when adr is generated instead of adrp. FAIL: gcc.target/aarch64/sve/peel_ind_1.c -march=armv8.2-a+sve scan-assembler \\tadrp\\tx[0-9]+, x\\n FAIL: gcc.target/aarch64/sve/peel_ind_2.c -march=armv8.2-a+sve scan-assembler \\tadrp\\tx[0-9]+, x\\n FAIL:

Fix funcition level hot/cold partitionig

Hi, this patch fixes another issue found by Martin Liska's patch to trap in unlikely section (last one which I need to bootstrap). Here we confused local and global counts, which was misupdate at a time I introudced them. Bootstrapped/regtested x86_64-linux. Honza * ipa-profile.c

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

On Wed, Jan 24, 2018 at 05:08:10PM +0100, Richard Biener wrote: > >The "omp declare simd" attribute refers to argument numbers of the > >functions, so trying to apply it on versioned functions that can > >perhaps > >have different number and types of arguments results in ICEs or > >wrong-code. >

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

On January 24, 2018 4:47:06 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >The "omp declare simd" attribute refers to argument numbers of the >functions, so trying to apply it on versioned functions that can >perhaps >have different number and types of arguments results in ICEs or

[C++ Patch/RFC] PR 83796 ("[6/7/8 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor")

Hi, I'm looking into this rather mild regression, which should be relatively easy to fix. In short, Jason's fix for c++/54325 moved an abstract_virtuals_error_sfinae check from build_aggr_init_expr to build_cplus_new therefore the testcase in this new bug isn't rejected anymore because a

[PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

Hi! The "omp declare simd" attribute refers to argument numbers of the functions, so trying to apply it on versioned functions that can perhaps have different number and types of arguments results in ICEs or wrong-code. Unfortunately, if simd attribute or #pragma omp declare simd is used on C++

Re: [PATCH, 2/2][nvptx, PR83589] Workaround for branch-around-nothing JIT bug

On 01/24/2018 03:07 PM, Jakub Jelinek wrote: On Wed, Jan 24, 2018 at 02:56:28PM +0100, Tom de Vries wrote: +#if WORKAROUND_PTXJIT_BUG_2 +/* Variant of pc_set that only requires JUMP_P (INSN) if STRICT. This variant + is needed in the nvptx target because the branches generated for +

[PATCH][testsuite] Fix arm options in gcc.dg/lto/20110201-1_0.c

Hi all, This test fails on arm hardfloat targets because it sets an explicit -mfloat-abi=softfp. The usual approach to setting the NEON options is to use dg-add-options arm_neon. But in the lto tests we don't have that framework, we can only set them explicitly with dg-lto-options. The

Re: Fix use of boolean_true/false_node (PR 83979)

On Tue, Jan 23, 2018 at 12:25 PM, Richard Sandiford wrote: > r255913 changed some constant_boolean_node calls to boolean_true_node > and boolean_false_node, which meant that the returned tree didn't > always have the right type. > > Tested on aarch64-linux-gnu.

Re: [PR81611] improve auto-inc

On Wed, Jan 24, 2018 at 4:42 AM, Alexandre Oliva wrote: > These two patches fix PR81611. > > The first one improves forwprop so that we avoid adding SSA conflicting > by forwpropping the iv increment, which may cause both the incremented > and the original value to be live,

Re: Remove explicit dg-do runs from gcc.dg/vect (PR 83889)

On Tue, Jan 23, 2018 at 12:32 PM, Richard Sandiford wrote: > The failures in this PR were from forcing { dg-do run } even when > vect.exp chooses options that are incompatible with the runtime. > The default vect.exp behaviour is to execute when possible, so there's

Re: [PATCH, 2/2][nvptx, PR83589] Workaround for branch-around-nothing JIT bug

On Wed, Jan 24, 2018 at 02:56:28PM +0100, Tom de Vries wrote: > +#if WORKAROUND_PTXJIT_BUG_2 > +/* Variant of pc_set that only requires JUMP_P (INSN) if STRICT. This > variant > + is needed in the nvptx target because the branches generated for > + parititioning are NONJUMP_INSN_P, not

C++ PATCH for c++/82249, wrong mismatched pack length error

tsubst_pack_expansion already knows how to deal with partial instantiation of a pack expansion, where we end up with arguments for some packs but not others, but my recent lambda work made this come up in a new situation: within a function, where we need to deal with function parameter packs as

RE: [PATCH] Fix various x86 avx512{bitalg, vpopcntdq, vbmi2} issues (PR target/83488)

Hi, Fixed it. Ok for trunk? gcc/ * config/i386/avx512bitalgintrin.h (_mm512_bitshuffle_epi64_mask, _mm512_mask_bitshuffle_epi64_mask, _mm256_bitshuffle_epi64_mask, _mm256_mask_bitshuffle_epi64_mask, _mm_bitshuffle_epi64_mask, _mm_mask_bitshuffle_epi64_mask): Fix

Re: [PATCH, 2/2][nvptx, PR83589] Workaround for branch-around-nothing JIT bug

On 01/24/2018 12:03 PM, Jakub Jelinek wrote: On Wed, Jan 24, 2018 at 11:41:45AM +0100, Tom de Vries wrote: +/* Insert a dummy ptx insn when encountering a branch to a label with no ptx + insn inbetween the branch and the label. This works around a JIT bug + observed at driver version

Re: [nvptx, PR81352] Add exit insn after noreturn call for neutered threads in warp

On 01/24/2018 12:53 PM, Richard Biener wrote: On Wed, 24 Jan 2018, Tom de Vries wrote: I'll commit this shortly for stage4. Strictly speaking, this is not an 8 regression, but a wrong code bug. But I think that the code generation error seems fundamental enough, and the fix simple and localized

Re: [aarch64][PATCH v2] Disable reg offset in quad-word store for Falkor

On Wednesday 24 January 2018 05:50 PM, Kyrill Tkachov wrote: > I would tend towards making the costs usage more intelligent and > differentiating > between loads and stores but I agree that is definitely GCC 9 material. > Whether this approach is an acceptable stopgap for GCC 8 is up to the >

Re: [aarch64][PATCH v2] Disable reg offset in quad-word store for Falkor

Hi Siddhesh, On 23/01/18 15:41, Siddhesh Poyarekar wrote: Hi, Here's v2 of the patch to disable register offset addressing mode for stores of 128-bit values on Falkor because they're very costly. Differences from the last version: - Incorporated changes Jim made to his patch earlier that I

Re: [nvptx, PR81352] Add exit insn after noreturn call for neutered threads in warp

On Wed, 24 Jan 2018, Tom de Vries wrote: > Hi, > > atm the test-case contained in this patch hangs. > > For the test-case we generate: > ... > @ %r79 bra $L18; > { > call _gfortran_abort; > trap; > exit; > } > $L18: > ... > > which results in SASS code (at

Re: [PATCH 1/7]: SVE: Add CLOBBER_HIGH expression

Ping. Any comments on this? The one line summary is that using self sets instead of clobber high would result in a patch roughly the same, but with different condition checks. It depends if people think it really is useful for self sets to not be live. Given that we are at stage 4 now, and this

[PATCH][testsuite] XFAIL gcc.dg/tree-ssa/ssa-dom-cse-2.c on non-NEON arm targets

Hi all, This test fails to optimise away the PLUS reduction in the loop on arm targets when vectorisation is not enabled due to absence of SIMD instructions. From reading the logs and the PR I gather that the presence or absence of SIMD affects the passing of this test on other targets as

[nvptx, PR81352] Add exit insn after noreturn call for neutered threads in warp

Hi, atm the test-case contained in this patch hangs. For the test-case we generate: ... @ %r79 bra $L18; { call _gfortran_abort; trap; exit; } $L18: ... which results in SASS code (at GOMP_NVPTX_JIT=-O4): ... /*05d8*/ @P0 BRA `(.L_18); /*05e8*/

RE: [patch][x86] -march=icelake

On Wed, 24 Jan 2018, Koval, Julia wrote: > I think we may want to extend it to more than 2 ints someday, when we run out > of bits again. It won't break the existing functionality if 3rd int will be > zero by default. That's why I tried to avoid "two" in the name. > > Julia > > >

RE: [patch][x86] -march=icelake

I think we may want to extend it to more than 2 ints someday, when we run out of bits again. It won't break the existing functionality if 3rd int will be zero by default. That's why I tried to avoid "two" in the name. Julia > -Original Message- > From: Jakub Jelinek

Re: [patch][x86] -march=icelake

On Wed, Jan 24, 2018 at 12:00:26PM +0100, Uros Bizjak wrote: > On Mon, Jan 22, 2018 at 3:44 PM, Koval, Julia wrote: > > Yes, you are right, any() is not required. Here is the patch. > > Please also attach ChangeLog. > > The patch is OK for x86 target, it needs global

Re: [PATCH, 2/2][nvptx, PR83589] Workaround for branch-around-nothing JIT bug

On Wed, Jan 24, 2018 at 11:41:45AM +0100, Tom de Vries wrote: > +/* Insert a dummy ptx insn when encountering a branch to a label with no ptx > + insn inbetween the branch and the label. This works around a JIT bug > + observed at driver version 384.111, at -O0 for sm_50. */ > + > +static

Re: [patch][x86] -march=icelake

On Mon, Jan 22, 2018 at 3:44 PM, Koval, Julia wrote: > Yes, you are right, any() is not required. Here is the patch. Please also attach ChangeLog. The patch is OK for x86 target, it needs global reviewer approval (Maybe Jakub, as the patch touches OMP part). Uros. >

Re: [PATCH, 2/2][nvptx, PR83589] Workaround for branch-around-nothing JIT bug

On Wed, 24 Jan 2018, Tom de Vries wrote: > Hi, > > this patch adds a workaround for the nvptx target JIT bug PR83589 - "[nvptx] > mode-transitions.c and private-variables.{c,f90} execution FAILs at > GOMP_NVPTX_JIT=-O0". > > > When compiling a branch-around-nothing (where the branch is warp

[PATCH, 2/2][nvptx, PR83589] Workaround for branch-around-nothing JIT bug

Hi, this patch adds a workaround for the nvptx target JIT bug PR83589 - "[nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0". When compiling a branch-around-nothing (where the branch is warp neutering, so it's a divergent branch): ... .reg

Re: [PATCH, 1/2][nvptx, libgomp] Add GOMP_NVPTX_JIT=-O[0-4] in nvptx libgomp plugin

On Wed, Jan 24, 2018 at 10:58:57AM +0100, Tom de Vries wrote: > I realize this is not really a stage4 patch, so: OK for stage1? Ok. Jakub

[PATCH, 1/2][nvptx, libgomp] Add GOMP_NVPTX_JIT=-O[0-4] in nvptx libgomp plugin

Hi, The nvptx target PR83589 - "[nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0" is a JIT bug. I've written a workaround for this JIT bug (the second patch in this series). I've only managed to reproduce the JIT bug at JIT optimization level

[PATCH] Fix PR83176

The following enhances chrec_fold_plus_1 to handle a case to avoid ICEing during GRAPHITE code-gen. It teaches us to handle (signed T) { (T) x, +, y } + (signed T) z as (signed T) ( { (T) x, +, y } + (T) (singed T) z ) instead of failing with chrec_not_known. Bootstrapped and tested on

Re: [Patch, fortran] PR37577 - [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15

Hi Jakub, The lateness is indeed embarrassing but couldn't be helped. > Given above my preference would be to keep version an int, and > change rank and type to signed char and attribute to signed short. > That way there will be no padding on either 32-bit or 64-bit targets, > and the structure

[PATCH] Fix PR84000

Committed as obvious. Richard. 2018-01-24 Richard Biener PR middle-end/84000 * tree-cfg.c (replace_loop_annotate): Handle annot_expr_parallel_kind. Index: gcc/tree-cfg.c === ---

Re: [Patch, fortran] PR37577 - [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15

On Wed, Jan 24, 2018 at 10:30:41AM +0200, Janne Blomqvist wrote: > On Tue, Jan 23, 2018 at 10:30 PM, Jakub Jelinek wrote: > > On Tue, Jan 23, 2018 at 07:30:49PM +, Paul Richard Thomas wrote: > >> Janne, Thanks. > >> > >> Jakub, is this OK with you? > > > > It is indeed quite

Re: [Patch, fortran] PR37577 - [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15

On Tue, Jan 23, 2018 at 10:30 PM, Jakub Jelinek wrote: > On Tue, Jan 23, 2018 at 07:30:49PM +, Paul Richard Thomas wrote: >> Janne, Thanks. >> >> Jakub, is this OK with you? > > It is indeed quite late for such large ABI changes, some distributions are > about to start using

Fix more of cases where block is incorrectly marked as cold

Hi, this patch fixes another issue where basic block is incorrectly marked as unlikely which is caught by Martin's hack to bb-reorder to insert trap to all blocks in cold partition. The problem solved here is that I have missed logic to set probabilities to adjusted when doing basic arithmetic on