Re: [PATCH] Fix PR c++/70096 (wrong code for pointer-to-member-function copy)

OK. Jason

Re: Fix 69650, bogus line numbers from libcpp

On 03/21/2016 09:15 PM, David Malcolm wrote: On Mon, 2016-03-14 at 14:20 +0100, Bernd Schmidt wrote: On 03/11/2016 11:09 PM, David Malcolm wrote: + cpp_error (pfile, CPP_DL_ERROR, +"file \"%s\" left but not entered", new_file);

Re: [PATCH, aarch64] Fix target/70120

Richard Henderson writes: > On 03/21/2016 06:40 AM, Jiong Wang wrote: >> On 17/03/16 19:17, Richard Henderson wrote: >>> PR target/70120 >>> * varasm.c (for_each_section): New. >>> * varasm.h (for_each_section): Declare. >>> * config/aarch64/aarch64.c (aarch64_align_code_section):

[PATCH] Fix PR c++/70096 (wrong code for pointer-to-member-function copy)

Given template void foo () { T A::*fptr; } We don't know whether fptr is a pointer-to-member-function or a pointer-to-data-member until we know what T is. But until then, fptr gets the type OFFSET_TYPE. If we later instantiate foo with e.g. T = void() then we know that fptr is a

Re: [PATCH] Fix another -Wnonnull-compare false positive (PR c++/70295)

On 03/21/2016 02:40 PM, Jakub Jelinek wrote: Hi! On the Wnonnull-compare-8.C testcase we emit false positive warning, because the this != NULL artificial comparison appears together with && optimized into &, and so it is gimplified as assignment to temporary instead of GIMPLE_COND.

Re: [PATCH] c++/67376 Comparison with pointer to past-the-end, of array fails inside constant expression

On 03/21/2016 11:54 AM, Jason Merrill wrote: Both b0 and b1 are invalid and should be diagnosed, but only b1 is. b1 isn't because because by the time we see its initializer in constexpr.c it's been transformed into the equivalent of "b1 = (int*)ps" (though we don't see the cast which would also

PING #2 [PATCH] 69517 - [5/6 regression] SEGV on a VLA with excess initializer elements

I'm looking for a review of the patch below. I noticed a piece of commented out code in there. Please assume that I will remove it before the final commit. As a heads up, I'm traveling this Thursday through Sunday and won't have access to email to answer questions or address comments until

Re: [PATCH, C++] Fix 70273

OK. Jason

C++ PATCH for c++/70285 (verify_gimple ICE with ?: and bit-field)

The C++ front end builds COND_EXPR where the arms can have a different type from the combined expression, if they are bit-fields. cp_genericize_r already fixes this up, but now cp_fold needs to handle it too. Tested x86_64-pc-linux-gnu, applying to trunk. commit

Patches to fix GCC’s C++ exception handling on NetBSD/VAX

Hi all, For several years I’ve been eager to find the time to fix the bugs in C++ exceptions on VAX to get them working on NetBSD, because they’ve been broken for many years and it looked like only a few changes were needed to get them working. Without C++ exceptions, the NetBSD test suite

Re: C PATCH for c/70297 (crash with duplicate typedefs and -g)

On March 21, 2016 6:55:28 PM GMT+01:00, Marek Polacek wrote: >This PR points out to a GC problem: when we freed a duplicate typedef, >we were >leaving its type in the variants list, with its TYPE_NAME still >pointing to the >now-freed TYPE_DECL, leading to a crash. I was

Re: [HSA, PATCH] Allocate memory for shadow arg (PR hsa/70337)

On 03/21/2016 07:23 PM, Martin Jambor wrote: This is strange. The pointer to the shadow data structure is, from the HSA perspective, a normal kernel argument and therefore should already be included in the kernel->kernarg_segment_size. Have you checked that the values are indeed off? Hi

Re: [PATCH] Fix self-comparison folding when honoring NaNs (PR tree-optimization/70317)

On Mon, Mar 21, 2016 at 02:43:23PM -0600, Jeff Law wrote: > On 03/21/2016 02:21 PM, Jakub Jelinek wrote: > >Hi! > > > >HONOR_NANS when called on a tree or its type handles properly > >vector/complex element modes, but HONOR_NANS (TYPE_MODE (TREE_TYPE (...))) > >does not. > > > >Fixed thusly,

Re: [PATCH] Fix RTL checking ICE during LRA remove_scratches (PR middle-end/70326)

On 03/21/2016 02:19 PM, Jakub Jelinek wrote: Hi! An instruction with scratches is deleted during LRA inheritance, and we ICE because restore_scratches wants to query its lra_get_insn_recog_data even when it is a NOTE, but insn_extract doesn't work on notes. Fixed thusly, bootstrapped/regtested

Re: [PATCH] Fix self-comparison folding when honoring NaNs (PR tree-optimization/70317)

On 03/21/2016 02:21 PM, Jakub Jelinek wrote: Hi! HONOR_NANS when called on a tree or its type handles properly vector/complex element modes, but HONOR_NANS (TYPE_MODE (TREE_TYPE (...))) does not. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2016-03-21

[PATCH] Fix another -Wnonnull-compare false positive (PR c++/70295)

Hi! On the Wnonnull-compare-8.C testcase we emit false positive warning, because the this != NULL artificial comparison appears together with && optimized into &, and so it is gimplified as assignment to temporary instead of GIMPLE_COND. Unfortunately, this regresses one test in nonnull-1.c,

Re: [RFA][PATCH] Adding missing calls to bitmap_clear

On 03/21/2016 01:10 PM, Bernd Schmidt wrote: On 03/21/2016 08:06 PM, Jeff Law wrote: As noted last week, find_removable_extensions initializes several bitmaps, but doesn't clear them. This is not strictly a leak as the GC system should find dead data, but it's better to go ahead and clear the

[PATCH] Fix self-comparison folding when honoring NaNs (PR tree-optimization/70317)

Hi! HONOR_NANS when called on a tree or its type handles properly vector/complex element modes, but HONOR_NANS (TYPE_MODE (TREE_TYPE (...))) does not. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2016-03-21 Marc Glisse

[PATCH] Fix RTL checking ICE during LRA remove_scratches (PR middle-end/70326)

Hi! An instruction with scratches is deleted during LRA inheritance, and we ICE because restore_scratches wants to query its lra_get_insn_recog_data even when it is a NOTE, but insn_extract doesn't work on notes. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

[PATCH] Fix V64QImode multiplication with AVX512BW (PR target/70329)

Hi! The ix86_expand_vecop_qihi function has been adjusted for AVX512* just by changing i < 32 to i < 64 (where both were sometimes wasteful), but for !full_interleave that is even wrong, swapping the second and third quarter is something that works to undo AVX256 unpacks only, where we want

Re: Fix 69650, bogus line numbers from libcpp

On Mon, 2016-03-14 at 14:20 +0100, Bernd Schmidt wrote: > On 03/11/2016 11:09 PM, David Malcolm wrote: > > > + cpp_error (pfile, CPP_DL_ERROR, > > > + "file \"%s\" left but not entered", > > > new_file); > > > >

[PATCH] Fix ICE with AVX512F and AMD tuning (PR target/70300)

Hi! vec_interleave_lowv4sf only supports =x, x, x alternative, not =v, v, v (which should be supportable for AVX512VL only anyway, but probably stage1 material), without AVX512VL and with ext sse reg input operand we have to either due to interleaving or broadcast in the destination, or disable

[PATCH, i386]: Fix PR 70327, ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with -mavx512ifma and v4ti argument

Hello! We have to expand SSE moves through x86_expand_vector_operand, otherwise unsupported push instructions are generated among other possible troubles. 2016-03-21 Uros Bizjak PR target/70327 * config/i386/i386.md (movxi): Use ix86_expand_vector_move instead

[PATCH, C++] Fix 70273

I'm not sure why the decl must be left on the local_decl list -- the same decl ought to also be in the BIND_EXPR for the function. But it's a fact that the DECL_INITIAL doesn't get processed during clone_body without the local_decl list processing. So in the meantime, set the

Re: [HSA, PATCH] Enhance dump output

On 03/21/2016 06:44 PM, Martin Jambor wrote: ...please remove the added newlines here... >+ if (symbol->m_directive_offset) >+fprintf (f, " /* BRIG offset: %u", symbol->m_directive_offset); ...and I think you are missing an ending "*/" in the string you dump. Sure, fixed.

Re: [RFA][PATCH] Adding missing calls to bitmap_clear

On 03/21/2016 08:06 PM, Jeff Law wrote: As noted last week, find_removable_extensions initializes several bitmaps, but doesn't clear them. This is not strictly a leak as the GC system should find dead data, but it's better to go ahead and clear the bitmaps. That releases the elements back to

[RFA][PATCH] Adding missing calls to bitmap_clear

As noted last week, find_removable_extensions initializes several bitmaps, but doesn't clear them. This is not strictly a leak as the GC system should find dead data, but it's better to go ahead and clear the bitmaps. That releases the elements back to the cache and presumably makes things

Re: [HSA, PATCH] Allocate memory for shadow arg (PR hsa/70337)

Hi, On Mon, Mar 21, 2016 at 01:49:25PM +0100, Martin Liska wrote: > Hello. > > Following patch fixes an invalid write in HSA plug-in. > I've been running bootstrap and regression tests on x86-linux-gnu. > > Ready after it finishes? > Thanks, > Martin > From

Re: [PATCH] Skip static ctors/dtors in IPA ICF (PR ipa/70306)

> Hello. > > Following patch skips static {c,d}tors in IPA ICF. > Patch can bootstrap and survives regtests on x86_64-linux-gnu. OK, (it woudl make more sense to turn them into wrappers that can be easily done, too, but we can do that next stage1) thanks! Honza > > Ready for trunk? > Thanks, >

C PATCH for c/70297 (crash with duplicate typedefs and -g)

This PR points out to a GC problem: when we freed a duplicate typedef, we were leaving its type in the variants list, with its TYPE_NAME still pointing to the now-freed TYPE_DECL, leading to a crash. I was lucky to discover that the exact same problem was fixed in November for the C++ FE, so I

Re: [PATCH] c++/67376 Comparison with pointer to past-the-end, of array fails inside constant expression

On 03/18/2016 01:04 PM, Jeff Law wrote: On 03/17/2016 03:16 PM, Martin Sebor wrote: The difficulty I've run into with detecting these problems in later phases is that some invalid expressions have already been simplified by the front end. The example that applies here (even though this is

Re: [PATCH, aarch64] Fix target/70120

On 03/21/2016 06:40 AM, Jiong Wang wrote: On 17/03/16 19:17, Richard Henderson wrote: PR target/70120 * varasm.c (for_each_section): New. * varasm.h (for_each_section): Declare. * config/aarch64/aarch64.c (aarch64_align_code_section): New. (aarch64_asm_file_end): New.

Re: [HSA, PATCH] Enhance dump output

Hi, On Mon, Mar 21, 2016 at 12:14:19PM +0100, Martin Liska wrote: > Hello. > > Following patch enhances dump output for SBR instructions and > provides a BRIG offset of HSA symbols. The change does not touch any > code generation snippet and I hope it can be installed during the stage4? yes,

Re: [PATCH] Fix PR c++/70204 (ICE in non_const_var_error)

On 03/21/2016 10:38 AM, Patrick Palka wrote: non_const_var_error() does not expect to complain about a decl whose DECL_INITIAL is a constant. But it is not sufficient to check that the DECL_INITIAL is a constant since it could be the case that it was folded to a constant and yet was originally

[PATCH] Skip static ctors/dtors in IPA ICF (PR ipa/70306)

Hello. Following patch skips static {c,d}tors in IPA ICF. Patch can bootstrap and survives regtests on x86_64-linux-gnu. Ready for trunk? Thanks, Martin >From 7a5748b38e173702c88b97420d6b4d8969ae7e85 Mon Sep 17 00:00:00 2001 From: marxin Date: Mon, 21 Mar 2016 13:51:32 +0100

Re: [PATCH PR69042/02]Increase PARAM_IV_CONSIDER_ALL_CANDIDATES_BOUND from 30 to 40

On 03/21/2016 09:14 AM, Bin Cheng wrote: Hi, After patch fixing PR69042 at https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00887.html, GCC hits bound (30) for parameter PARAM_IV_CONSIDER_ALL_CANDIDATES_BOUND in case 173.applu, which causes ~4% regression on AArch64. Since adding more

Re: [PR c/68966] Restore atomic builtins usage in libstdc++-v3

Hi! On Mon, 21 Mar 2016 15:01:49 +, Jonathan Wakely wrote: > On 21/03/16 13:08 +0100, Thomas Schwinge wrote: > >Per my (admittedly, not in-depth) reading of libstdc++-v3 source code, > >the _GLIBCXX_ATOMIC_BUILTINS conditional is only used in combination with > >the

Re: [GCC][ARM] Skip tests that assume target supports arm mode, when testing M profiles

On 21/03/16 10:39, Ramana Radhakrishnan wrote: > On Thu, Mar 17, 2016 at 4:39 PM, Andre Vieira (lists) > wrote: >> Hello, >> >> This patch skips four tests that assume a target supports ARM mode when >> testing M-profiles. >> Tested it by running the four tests for

Re: [ptx] debug info

Hi! On Thu, 10 Mar 2016 16:14:34 +0300 (MSK), Alexander Monakov wrote: > On Thu, 10 Mar 2016, Nathan Sidwell wrote: > > Hm, something must have changed since I found that sorry neccessary. > > As I already said in my opening sentence (not quoted in your response), you >

[PATCH PR69489/02]Handle PHI which can be degenerated to two arguments node in tree ifcvt.

Hi, The second issue revealed by PR69489 is tree ifcvt could not convert PHI nodes with more than 2 arguments. Among these nodes, there is a special kind of PHI which can be handled. Precisely, if the PHI node satisfies below two conditions: 1) Number of PHI arguments with different

[PATCH PR69042/02]Increase PARAM_IV_CONSIDER_ALL_CANDIDATES_BOUND from 30 to 40

Hi, After patch fixing PR69042 at https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00887.html, GCC hits bound (30) for parameter PARAM_IV_CONSIDER_ALL_CANDIDATES_BOUND in case 173.applu, which causes ~4% regression on AArch64. Since adding more candidates is inevitable (Well, we might be able to

Re: [PATCH 4/4] [RS6000] Allow saving of fixed regs.

On Mon, Mar 21, 2016 at 9:08 AM, Alan Modra wrote: > As I noted a long time ago in the comment on fixed_reg_p, the real > problem with saving fixed/global regs is that exception frame > unwinding might restore them. So don't emit eh_frame info for any > such reg, and the

Re: [PATCH][CilkPlus] Allow parenthesized initialization in for-loops

On Mon, Mar 21, 2016 at 05:45:52PM +0300, Ilya Verbin wrote: > www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm > says: > In C++, the control variable shall be declared and initialized within the > initialization clause of the _Cilk_for loop. The

Re: [PR c/68966] Restore atomic builtins usage in libstdc++-v3 (was: [PATCH] c/68966 - atomic_fetch_* on atomic_bool not diagnosed)

On 21/03/16 13:08 +0100, Thomas Schwinge wrote: Per my (admittedly, not in-depth) reading of libstdc++-v3 source code, the _GLIBCXX_ATOMIC_BUILTINS conditional is only used in combination with the _Atomic_word data type, which in libstdc++-v3/doc/xml/manual/concurrency_extensions.xml is

Re: Fix 69650, bogus line numbers from libcpp

Ping. Bernd On 03/14/2016 02:20 PM, Bernd Schmidt wrote: On 03/11/2016 11:09 PM, David Malcolm wrote: + cpp_error (pfile, CPP_DL_ERROR, + "file \"%s\" left but not entered", new_file); Although it looks like

Re: [PATCH 3/4] [RS6000] Split SAVRES_STRATEGY

On Mon, Mar 21, 2016 at 9:07 AM, Alan Modra wrote: > No functional change here. A single bit becomes two bits, which > always have the same value at the moment. In preparation for the > next patch. > > * config/rs6000/rs6000.c (SAVRES_MULTIPLE): Replace with.. >

[PATCH] Fix PR c++/70204 (ICE in non_const_var_error)

non_const_var_error() does not expect to complain about a decl whose DECL_INITIAL is a constant. But it is not sufficient to check that the DECL_INITIAL is a constant since it could be the case that it was folded to a constant and yet was originally initialized by a non-constant expression. So

Re: [PATCH 2/4] [RS6000] PR69645, -ffixed-reg ignored

On Mon, Mar 21, 2016 at 9:06 AM, Alan Modra wrote: > Treat -ffixed-reg as we do for global asm regs. The only slightly > complicated part of this patch is that the rs6000 backend itself sets > fixed_regs[RS6000_PIC_OFFSET_TABLE_REGNUM] in some cases, which means > we can't

Re: [PATCH 1/4] [RS6000] Simplify setting of fixed_regs[RS6000_PIC_OFFSET_TABLE_REGNUM]

On Mon, Mar 21, 2016 at 9:06 AM, Alan Modra wrote: > This makes the conditions look the same as other places that deal with > RS6000_PIC_OFFSET_TABLE_REGNUM, eg. first_reg_to_save. No functional > changes. > > * config/rs6000/rs6000.c

[PATCH][CilkPlus] Allow parenthesized initialization in for-loops

Hi! www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm says: In C++, the control variable shall be declared and initialized within the initialization clause of the _Cilk_for loop. The variable shall have automatic storage duration. The variable shall

Re: [PATCH] Fix rs6000 vector builtin macro handling if it is followed by a fn-like macro without arguments (PR target/70296)

On Fri, Mar 18, 2016 at 10:34:49PM +0100, Jakub Jelinek wrote: > Hi! > > The following testcase is diagnosed as errorneous, because the preprocessor > mishandles > > #define c(x) x > vector c; > > and > > #define int(x) x > vector int n; > > The thing is if a function-like macro is not

Re: [PATCH, i386, AVX-512] Fix PR target/70325.

On Mon, 21 Mar 2016, Kirill Yukhin wrote: > Hello, > 1s in mask in i386.c/builtin_description enables > built-ins for corresponding bits. > So, actually if there're 2 1s in it - any bit set > enables built-in. > > AVX-512VL exploits mask in opposite way. > E.g.: > { OPTION_MASK_ISA_AVX512BW |

[PATCH, i386, AVX-512] Fix PR target/70325.

Hello, 1s in mask in i386.c/builtin_description enables built-ins for corresponding bits. So, actually if there're 2 1s in it - any bit set enables built-in. AVX-512VL exploits mask in opposite way. E.g.: { OPTION_MASK_ISA_AVX512BW | OPTION_MASK_ISA_AVX512VL,

[PATCH] Fix PR70310

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2016-03-21 Richard Biener PR tree-optimization/70310 * tree-vect-generic.c (expand_vector_condition): Fold the built condition. * gcc.dg/torture/pr70310.c: New

Re: [PATCH 0/7] ira.c tidies

On 03/21/2016 02:37 AM, Alan Modra wrote: This series tidies some of the early ira code, in the process making a tiny improvement to register pressure. Patches 1 to 3 are fairly simple tidies, with zero impact on generated code. Patch 4 also is mainly a tidy, but could see some extra REG_EQUIV

Re: [PATCH, aarch64] Fix target/70120

On 17/03/16 19:17, Richard Henderson wrote: PR target/70120 * varasm.c (for_each_section): New. * varasm.h (for_each_section): Declare. * config/aarch64/aarch64.c (aarch64_align_code_section): New. (aarch64_asm_file_end): New. (TARGET_ASM_FILE_END):

Re: [PATCH, aarch64] Fix target/70120

On 03/17/2016 08:17 PM, Richard Henderson wrote: With -g, and a code section that ends unaligned, the assembler complains of "unaligned opcodes detected". Except there are no such unaligned opcodes, nor dwarf2 code ranges covering the end of the section, which arguably makes this an assembler

[PATCH 4/4] [RS6000] Allow saving of fixed regs.

As I noted a long time ago in the comment on fixed_reg_p, the real problem with saving fixed/global regs is that exception frame unwinding might restore them. So don't emit eh_frame info for any such reg, and the unwinder won't restore them. Also, tidy rs6000_savres_strategy. Delaying some

[PATCH 3/4] [RS6000] Split SAVRES_STRATEGY

No functional change here. A single bit becomes two bits, which always have the same value at the moment. In preparation for the next patch. * config/rs6000/rs6000.c (SAVRES_MULTIPLE): Replace with.. (SAVE_STRATEGY, REST_STRATEGY): ..this. Renumber and sort enum. Update

[PATCH 2/4] [RS6000] PR69645, -ffixed-reg ignored

Treat -ffixed-reg as we do for global asm regs. The only slightly complicated part of this patch is that the rs6000 backend itself sets fixed_regs[RS6000_PIC_OFFSET_TABLE_REGNUM] in some cases, which means we can't simply test fixed_regs[] to determine whether a reg appeared as -ffixed-reg.

[PATCH 1/4] [RS6000] Simplify setting of fixed_regs[RS6000_PIC_OFFSET_TABLE_REGNUM]

This makes the conditions look the same as other places that deal with RS6000_PIC_OFFSET_TABLE_REGNUM, eg. first_reg_to_save. No functional changes. * config/rs6000/rs6000.c (rs6000_conditional_register_usage): Remove redundant PIC_OFFSET_TABLE_REGNUM test. Replace with

[RS6000] PR69645, -ffixed-reg

This series of patches makes the rs6000 backend properly honour -ffixed-reg in that compiler generated code should never write them, even when restoring saved copies of registers. Patch 1 and 2 are the bugfix. Patch 3 and 4 allow saving regs using stmw or out-of-line save functions, even when

RE: [PATCH] __FILE__, line directives, and non-printable characters

I realized I didn't make the necessary edits for gfortran. gcc/fortran/ChangeLog - 2016-03-21 Daniel Sabogal PR preprocessor/51259 * cpp.c (print_line): Allow replacement when calling "cpp_quote_string". (pp_dir_change): Allow replacement

[HSA, PATCH] Allocate memory for shadow arg (PR hsa/70337)

Hello. Following patch fixes an invalid write in HSA plug-in. I've been running bootstrap and regression tests on x86-linux-gnu. Ready after it finishes? Thanks, Martin >From 2674ceb5fddeaeb26ff87d26a43bddaf40060ea2 Mon Sep 17 00:00:00 2001 From: marxin Date: Mon, 21 Mar 2016

Re: [i386] Support .lbss etc. sections with Solaris as (PR target/59407)

Uros Bizjak writes: > On Thu, Mar 17, 2016 at 11:40 PM, Rainer Orth > wrote: >> gcc.target/i386/pr58218.c currently FAILs on 64-bit Solaris/x86 with the >> native assembler: >> >> FAIL: gcc.target/i386/pr58218.c (test for excess errors) >> >>

[PR c/68966] Restore atomic builtins usage in libstdc++-v3 (was: [PATCH] c/68966 - atomic_fetch_* on atomic_bool not diagnosed)

Hi! On Tue, 22 Dec 2015 21:46:19 -0700, Martin Sebor wrote: > The attached patch rejects invocations of atomic fetch_op intrinsics > on objects of _Bool type as discussed in the context of PR c/68908. > > Tested on x86_64. I'd noticed something "strange". ;-) For reference:

Re: [PATCH 1/4, libgomp] Resolve deadlock on plugin exit

On 2016/3/21 07:01 PM, Alexander Monakov wrote: > Hi, > > I'd like to note that I have a small patch on gomp-nvptx branch that deals > with the worst user-visible regression in a non-intrusive manner: > > https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01109.html > > Alexander > That error

[HSA, PATCH] Enhance dump output

Hello. Following patch enhances dump output for SBR instructions and provides a BRIG offset of HSA symbols. The change does not touch any code generation snippet and I hope it can be installed during the stage4? Patch can bootstrap on x86_64-linux-gnu and survives make check-target-libgomp.

Re: [PATCH 1/4, libgomp] Resolve deadlock on plugin exit

Hi, I'd like to note that I have a small patch on gomp-nvptx branch that deals with the worst user-visible regression in a non-intrusive manner: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01109.html Alexander

Re: [PATCH, i386, AVX-512] Fix for PR target/70293.

On 21 Mar 11:37, Richard Biener wrote: > On Mon, 21 Mar 2016, Kirill Yukhin wrote: > > > Hello, > > > > Attached patch blocks third alternative of broadcast pattern > > when compiled w/ -mavx512vl. > > Issue is that third alternative is subject for subsequent splitting. > > AVX-512VL allows

Re: [PATCH][ARM] Reduce size of arm1020e automaton

On Mon, Feb 29, 2016 at 4:08 PM, Kyrill Tkachov wrote: > Hi all, > > I've had this one sitting in my tree for some time. > The arm1020e automaton has no business being as large as it is (3185 > states). > Most of the bloat is due to overly large reservation durations

Re: [PATCH][ARM] PR driver/70132: Avoid double fclose in driver-arm.c

On Fri, Mar 11, 2016 at 3:32 PM, Kyrill Tkachov wrote: > Hi all, > > As reported in the PR we can end up calling fclose twice on a file, causing > an error. > This patch fixes that by reorganising the logic a bit to ensure we return > after closing > the file the

Re: [GCC][ARM] Skip tests that assume target supports arm mode, when testing M profiles

On Thu, Mar 17, 2016 at 4:39 PM, Andre Vieira (lists) wrote: > Hello, > > This patch skips four tests that assume a target supports ARM mode when > testing M-profiles. > Tested it by running the four tests for A-profiles and M-profiles. > > Is this ok? OK. Ramana

Re: [PATCH, i386, AVX-512] Fix for PR target/70293.

On Mon, 21 Mar 2016, Kirill Yukhin wrote: > Hello, > > Attached patch blocks third alternative of broadcast pattern > when compiled w/ -mavx512vl. > Issue is that third alternative is subject for subsequent splitting. > AVX-512VL allows higher XMM regnums (than SSE), so split generate > AVX2

Re: [PATCH] Retry to emit global variables in HSA (PR hsa/70234)

On 03/17/2016 07:21 PM, Martin Jambor wrote: > Hopefully the linear search in m_global_symbols never becomes > prohibitively expensive. But it is only necessary when > is_in_global_vars is true, so at least we could do something like: > > if (is_in_global_vars && !sym->m_emitted_to_brig) >

[PATCH 4/4, libgomp] Resolve deadlock on plugin exit, intelmic plugin parts

Hi Jakub, your earlier concern about the return after abort was naturally resolved after the gomp_target_fini changes. Thanks, Chung-Lin * plugin/libgomp-plugin-intelmic.cpp (offload): Change return type to bool, adjust return code. (GOMP_OFFLOAD_init_device): Likewise.

[PATCH 2/4, libgomp] Resolve deadlock on plugin exit, nvptx plugin parts

As attached. Thanks, Chung-Lin * plugin/plugin-nvptx.c (CUDA_CALL_ERET): New convenience macro. (CUDA_CALL): Likewise. (CUDA_CALL_ASSERT): Likewise. (map_init): Change return type to bool, use CUDA_CALL* macros. (map_fini): Likewise.

[PATCH 3/4, libgomp] Resolve deadlock on plugin exit, HSA plugin parts

Hi Martin, I think you're the one to CC for this, as I mentioned in the first email, this has been build tested, however I did not know if I could test this without a Radeon card. If convenient, could you or anyone familiar with the setup do a make check-target-libgomp with this patch series?

[PATCH 1/4, libgomp] Resolve deadlock on plugin exit

Hi, this is the set of patches from https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01411.html revised again, this time also with audits for the HSA plugin. The changes are pretty minor, mainly that the unload_image hook now receives similar error handling treatment. Tested again without

[PATCH, i386, AVX-512] Fix for PR target/70293.

Hello, Attached patch blocks third alternative of broadcast pattern when compiled w/ -mavx512vl. Issue is that third alternative is subject for subsequent splitting. AVX-512VL allows higher XMM regnums (than SSE), so split generate AVX2 broadcast insns, which will use XMMN, N>15. We have

[PATCH, C++, PR70290] Fix type checks for vector conditional expr

Hi, This patch makes an integer vector type to always be used for type checks when building a vector conditional expression. With no this patch we may get a type of vector comparison which may have non-vector mode and different size in case of scalar masks usage. Bootstrapped and regetsted on

Re: [PATCH][PR rtl-optimization/69307] Handle hard registers in modes that span more than one register properly

On 14.03.2016 21:39, Jeff Law wrote: On 03/14/2016 03:56 AM, Andrey Belevantsev wrote: Thank you for checking this in. I've also tested this patch in the similar way (forcing selective scheduling for 2nd and both schedulers) both on x86-64 and ia64. I've posted the patches for remaining