Re: [PATCH] Handle BUILT_IN_GOACC_PARALLEL in ipa-pta

On Wed, 16 Dec 2015, Tom de Vries wrote: > On 10/12/15 14:14, Tom de Vries wrote: > > [ copy-pasting-with-quote from > > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00420.html , for some > > reason I didn't get this email ] > > > > > On Thu, 3 Dec 2015, Tom de Vries wrote: > > > > The flag is s

RE: [PATCH, ARM, ping1] Fix gcc.c-torture/execute/loop-2b.c execution failure on cortex-m0

Ping? > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme > Sent: Wednesday, December 16, 2015 5:11 PM > To: gcc-patches@gcc.gnu.org; Richard Earnshaw; Ramana Radhakrishnan; > Kyrylo Tkachov > Subject: [PATCH,

Re: [PATCH 5/5] Fix intransitive comparison in dr_group_sort_cmp

On Sat, 19 Dec 2015, Yuri Gribov wrote: > On Fri, Dec 18, 2015 at 11:20 PM, Yury Gribov wrote: > > On 12/17/2015 03:51 PM, Richard Biener wrote: > >> > >> On Thu, 17 Dec 2015, Yury Gribov wrote: > >> > >>> On 12/17/2015 02:57 PM, Richard Biener wrote: > > On Thu, 17 Dec 2015, Yury Gribo

RE: Fix 61441 [5/5] Disable various transformations for signaling NaN operands

Hi, > If you have access to x86_64-linux, you can easily test it yourself with: > make -C gcc check-gcc RUNTESTFLAGS='--target_board=unix\{-m64,-m32/- > march=i386\} dg.exp=pr61441.c' > > Your patch does help. Thanks, I tested the changes and it worked fine. > issignalling is a GNU extension o

[AArch32][NEON] Implementing vmaxnmQ_ST and vminnmQ_ST intrinsics.

This patch implements the vmaxnmQ_ST and vminnmQ_ST intrinsics. The current builtin registration code is deficient since it can't access standard pattern names, to which vmaxnmQ_ST and vminnmQ_ST map directly. Thus, to enable the vectoriser to have access to these intrinsics, we implement them usi

Re: [PATCH, GCC] Fix PR67781: wrong code generation for partial load on big endian targets

On Tue, 5 Jan 2016, Thomas Preud'homme wrote: > Hi, > > bswap optimization pass generate wrong code on big endian targets when the > result of a bit operation it analyzed is a partial load of the range of > memory > accessed by the original expression (when one or more bytes at lowest address

Re: [PATCH] Fix incorrect gimple_build arguments in gimple-fold.c (PR tree-optimization/69172)

On Thu, 7 Jan 2016, Jakub Jelinek wrote: > Hi! > > gimple_build wants the type after POINTER_PLUS_EXPR, but > gimple_fold_builtin_memory_chk wasn't passing it. > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for > trunk? Oops, yes. Thanks, Richard. > 2016-01-07 Ja

Re: [PATCH] Fix (ab) SSA_NAME issue in gimple folding (PR tree-optimization/69167)

On Thu, 7 Jan 2016, Jakub Jelinek wrote: > Hi! > > Various places check that (ab) SSA_NAMEs that weren't referenced on a stmt > before don't appear on it, but all the checking is done on the gimple tuple > operands, while in this case it is added to operands of a comparison of > COND_EXPR/VEC_CON

Re: [PATCH] Fix ICE with va_arg (PR tree-optimization/69162)

On Thu, 7 Jan 2016, Jakub Jelinek wrote: > Hi! > > The addition of IFN_VA_ARG which is only during stdarg pass lowered > introduced ICE on the following testcase. The problem is that > we expected that the type the first argument of the internal call points > to will remain the one that used to

Re: [PATCH, testsuite] Fix g++.dg/pr67989.C test failure when running with -march or -mcpu

On Thursday, January 07, 2016 10:26:28 AM Richard Earnshaw wrote: > On 07/01/16 09:15, Kyrill Tkachov wrote: > > In this case perhaps we should go the route of just removing the > > target-specific option > > altogether. > > > > Richard, that's the approach you recommended, right? > > Yes. > > I

Re: [RFA] [PATCH][PR tree-optimization/64910] Fix reassociation of binary bitwise operations with 3 operands

On Tue, Dec 22, 2015 at 12:39 AM, Jeff Law wrote: > > As outlined in the BZ, given > > (x & y) & C > > reassociation will turn that into > > (x & C) & y > > Which inhibits bit operations on various targets. > > Associating as > > (x & y) & C > > is what we want. > > My original patch did this for

Re: RFA: Fix ICE compiling gcc.dg/lto/pr55113_0.c for x86/x86_64

On Tue, Dec 22, 2015 at 10:55 AM, Nick Clifton wrote: > Hi Richard, > >>> The patch below is a fix for this problem, although I am not sure if >>> it is the correct fix. The patch selects the corresponding SFmode >>> variant of the DFmode vector type when flag_short_doubles is enabled. >>>

Re: [PATCH, PR target/69010] Fix expand for constant boolean vectors with a scalar mode

On Wed, Dec 23, 2015 at 10:14 AM, Ilya Enkovich wrote: > Hi, > > Currently boolean vector constant is expanded incorrectly when > it has a scalar mode. Generated constant is incorrect and also > its mode (which is VOIDmode) is used for roce_reg which causes > ICE. This patch fixes both problems.

Re: varpool/constpool bug

On Mon, Jan 4, 2016 at 7:53 PM, Jeff Law wrote: > On 01/04/2016 08:57 AM, Nathan Sidwell wrote: >> >> My patch to stop constant pool objects accidentally ending up in the >> varpool caused problems with (at least) powerpc. >> (https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02100.html) Hence reverte

Re: [PATCH, middle-end]: Fix PR68999, gfortran.fortran-torture/execute/save_1.f90 execution failure on alpha

Hello! This patch includes part of [1] that trivially renumbers a return value, so the follow-up part of a patch that fixes aliasing issues can be much smaller and more focused. 2016-01-08 Uros Bizjak * symtab.c (symtab_node::equal_address_to): Return -1 instead of 2 if we can't deter

Re: [PATCH] Fix -Wmisleading indentation false-positive for do-while statement

On Tue, Dec 22, 2015 at 12:33:51PM -0500, Patrick Palka wrote: > We are emitting a bogus warning for the code > > do foo (0); while (flagA); > ^--- NEXT > ^ BODY > ^--- GUARD > > In general I don't think we can get any useful indentation warning out

Re: [PATCH 2/4] Equate MEM_REFs and ARRAY_REFs in tree-ssa-scopedtables.c

On Tue, Jan 5, 2016 at 5:36 PM, Jeff Law wrote: > On 01/05/2016 09:29 AM, Alan Lawrence wrote: >>> >>> Without looking at the patch, ARRAY_REFs can have non-constant indices >>> which get_ref_base_and_extend handles conservative. You should make >>> sure to not regress here. >> >> >> Thanks for t

[PATCH] libitm: Fix HTM fastpath.

This patch fixes a thinko in the HTM fastpath implementation. In a nutshell, we also need to monitor the HTM fastpath control (ie, htm_fastpath) variable from within a HW transaction on the HTM fastpath, so that such a HW transaciton will only execute if the HTM hastpath is still enabled. We move

Re: RFA (tree-cfg): PATCH for 68983 (ICE in copy constructor)

On Fri, Jan 8, 2016 at 8:22 AM, Eric Botcazou wrote: >> But it occurs to me that since the real problem I was trying to catch is >> creation of temporaries of TREE_ADDRESSABLE type in the back end, we >> should guard that instead. So this patch moves the assert into assign_temp. > > FWIW create_t

Re: [PATCH, middle-end]: Fix PR68999, gfortran.fortran-torture/execute/save_1.f90 execution failure on alpha

On Fri, Jan 8, 2016 at 11:41 AM, Uros Bizjak wrote: > Hello! > > This patch includes part of [1] that trivially renumbers a return > value, so the follow-up part of a patch that fixes aliasing issues can > be much smaller and more focused. > > 2016-01-08 Uros Bizjak > > * symtab.c (symtab_n

[PATCH] Fix PR68707

Here's an alternative patch, using the hunk from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707#c16, which 'improves' (heh, we think) on the previous by allowing SLP to proceed where the loads are strided, for example, slp-perm-11.c. Also I fix the testsuite failures (looking for SLP where we'v

Re: [PATCH] Fix PR68707

On Fri, 8 Jan 2016, Alan Lawrence wrote: > Here's an alternative patch, using the hunk from > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707#c16, which 'improves' (heh, > we think) on the previous by allowing SLP to proceed where the loads are > strided, for example, slp-perm-11.c. Also I fix

Re: RFA: PR 68913: Provide weak version of __fread_chk for PR61886 test

Hi Guys, OK - how about this reformulation of the pr61886 test ? The patch changes references to __fread_chk with references to just fread, which I assume will be present in all target runtime libraries. I had to add some preprocessor trickery in order to ensure that __USER_LABEL_PREFIX__

[ARM][PR69194] Fix ICE in in extract_insn

neon_vld1 pattern does not accept eliminable registers and due to this, testcase in PR ICE. The problem is in arm_expand_neon_args, in the NEON_ARG_MEMORY case, where it call force_reg. Since an eliminable reg is already a reg, it just returns that value, and we get the wrong result. It needs to

Re: [ARM][PR69194] Fix ICE in in extract_insn

Hi Kugan, On 08/01/16 12:07, Kugan wrote: neon_vld1 pattern does not accept eliminable registers and due to this, testcase in PR ICE. The problem is in arm_expand_neon_args, in the NEON_ARG_MEMORY case, where it call force_reg. Since an eliminable reg is already a reg, it just returns that valu

Re: [ARM][PR69194] Fix ICE in in extract_insn

On 08/01/16 12:10, Kyrill Tkachov wrote: Hi Kugan, On 08/01/16 12:07, Kugan wrote: neon_vld1 pattern does not accept eliminable registers and due to this, testcase in PR ICE. The problem is in arm_expand_neon_args, in the NEON_ARG_MEMORY case, where it call force_reg. Since an eliminable reg

Re: [ARM][PR69194] Fix ICE in in extract_insn

On Fri, Jan 08, 2016 at 11:07:17PM +1100, Kugan wrote: > gcc/ChangeLog: > > 2016-01-08 Kugan Vivekanandarajah > Jim Wilson > > PR target/69194 > * config/arm/arm-builtins.c (arm_expand_neon_args): Call >copy_to_mode_reg instead of force_reg. The line should be

Re: [C++ PATCH] Fix ICE with bitfields (PR c++/69164)

On 01/07/2016 10:43 PM, Jakub Jelinek wrote: PR c++/69164 * class.c (layout_class_type): Also copy DEC_SIZE_UNIT, DECL_BIT_FIELD and DEC_BIT_FIELD_TYPE. Any reason this isn't using copy_node? Bernd

Re: [C++ PATCH] Fix ICE with bitfields (PR c++/69164)

On Fri, Jan 08, 2016 at 01:46:47PM +0100, Bernd Schmidt wrote: > On 01/07/2016 10:43 PM, Jakub Jelinek wrote: > > > > PR c++/69164 > > * class.c (layout_class_type): Also copy DEC_SIZE_UNIT, DECL_BIT_FIELD > > and DEC_BIT_FIELD_TYPE. > > Any reason this isn't using copy_node? No idea,

Re: RFA: Fix ICE compiling gcc.dg/lto/pr55113_0.c for x86/x86_64

On 01/08/2016 10:41 AM, Richard Biener wrote: On Tue, Dec 22, 2015 at 10:55 AM, Nick Clifton wrote: Hi Richard, The patch below is a fix for this problem, although I am not sure if it is the correct fix. The patch selects the corresponding SFmode variant of the DFmode vector type

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

On 07/01/16 14:00, Kyrill Tkachov wrote: On 07/01/16 13:47, Bernd Schmidt wrote: On 01/07/2016 02:45 PM, Kyrill Tkachov wrote: On 07/01/16 11:52, Bernd Schmidt wrote: I looked and this is indeed the case. Still slightly scary. Should the MEM be rtx_equal_p to TO_RENAME? It would be good to

Re: [patch] libstdc++/69105, 69106, 69114 use std::addressof

On 07/01/16 15:01 +, Jonathan Wakely wrote: A bumper crop of addressof bugs where I was using & but should have used std::addressof. This caused a regression, fixed like so. Tested x86_64-linux, committed to trunk. commit 8f7a4cbf1cdae97578a6b4236af532879be15e9d Author: Jonathan Wakely

Re: [patch] libstdc++/69105, 69106, 69114 use std::addressof

Hi Jonathan, On 08/01/16 13:13, Jonathan Wakely wrote: On 07/01/16 15:01 +, Jonathan Wakely wrote: A bumper crop of addressof bugs where I was using & but should have used std::addressof. This caused a regression, fixed like so. Tested x86_64-linux, committed to trunk. You used "PR l

Re: [patch] libstdc++/69105, 69106, 69114 use std::addressof

On 08/01/16 13:17 +, Kyrill Tkachov wrote: Hi Jonathan, On 08/01/16 13:13, Jonathan Wakely wrote: On 07/01/16 15:01 +, Jonathan Wakely wrote: A bumper crop of addressof bugs where I was using & but should have used std::addressof. This caused a regression, fixed like so. Tested x86_

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

On 01/08/2016 02:11 PM, Kyrill Tkachov wrote: How's this? Hmm. Almost there, but... - if (then_bb && else_bb && !a_simple && !b_simple - && (!bbs_ok_for_cmove_arith (then_bb, else_bb) - || !bbs_ok_for_cmove_arith (else_bb, then_bb))) + rtx orig_x = x; + if (then_bb && else_bb)

prevent "undef var" errors on gcc --help or --version

Hello, self-specs setup with configure --with-specs are allowed to contain %:getenv environment variable references. We are using this capability in a few cases for cross ports. In such configurations, gcc --help or gcc --version fail if the variables aren't defined, like so: gcc --version

[patch] libstdc++/48891 Use ::isinf and ::isnan if libc defines them

Glibc defines obsolete isinf(double) and isnan(double) functions from Unix98. For C99 these are hidden by the type-generic isinf and isnan macros, but in C++11 #undefs those macros, exposing the Unix98 functions. They then conflict with our own std::isinf(double) and std::isnan(double) if users a

Re: [C++ PATCH] Fix ICE with bitfields (PR c++/69164)

On 01/08/2016 07:58 AM, Jakub Jelinek wrote: On Fri, Jan 08, 2016 at 01:46:47PM +0100, Bernd Schmidt wrote: On 01/07/2016 10:43 PM, Jakub Jelinek wrote: PR c++/69164 * class.c (layout_class_type): Also copy DEC_SIZE_UNIT, DECL_BIT_FIELD and DEC_BIT_FIELD_TYPE. Any rea

Re: varpool/constpool bug

On 01/08/16 05:39, Richard Biener wrote: Oh, and I _do_ belive that ultimatively we should have all constant pool entries (and CONST_DECLs) in the varpool. FWIW that certainly seems like the right goal. nathan

[PATCH] arc/gcc: Fix help text for some options.

The following minor patch fixes up the command line option help text for arc. This resolves one test failure in help.exp. I don't have GCC write access, so if this is approved, please could someone apply it for me. Thanks, Andrew --- Add missing period to the end of the sentences for a couple

[ping] fix VXWORKS_LIBGCC_SPEC not to include -lc_internal for shared rtps

Hello, Ping for https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02028.html > * config/vxworks.h (VXWORKS_LIBGCC_SPEC): Don't link shared RTPs with > libc_internal. Thanks in advance, With Kind Regards, Olivier

Re: [ping] fix VXWORKS_LIBGCC_SPEC not to include -lc_internal for shared rtps

On 01/08/16 09:16, Olivier Hainque wrote: Hello, Ping for https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02028.html * config/vxworks.h (VXWORKS_LIBGCC_SPEC): Don't link shared RTPs with libc_internal. Thanks in advance, ok

Re: [ping] fix VXWORKS_LIBGCC_SPEC not to include -lc_internal for shared rtps

> On Jan 8, 2016, at 15:17 , Nathan Sidwell wrote: >>> * config/vxworks.h (VXWORKS_LIBGCC_SPEC): Don't link shared RTPs with >>> libc_internal. > ok Great! Thanks for your prompt feedback Nathan :-)

Re: [PATCH] Fix -Wmisleading indentation false-positive for do-while statement

On 01/08/2016 03:43 AM, Jakub Jelinek wrote: On Tue, Dec 22, 2015 at 12:33:51PM -0500, Patrick Palka wrote: We are emitting a bogus warning for the code do foo (0); while (flagA); ^--- NEXT ^ BODY ^--- GUARD In general I don't think we can get

[patch] Use -std options to test C99 classification macros in C++

The 26_numerics/headers/cmath/c99_classification_macros_c++.cc test was written for C++98 mode (we have a separate test that uses -std=gnu++11) but with the GCC 6 switch to -std=gnu++14 by default we now check it in C++14 mode. That's pointless, as the relevant parts of are equivalent in C++11 an

[patch] Avoid an unwanted decl re-map in copy_gimple_seq_and_replace_locals

Hi, I ran into an ICE when compiling the following function on the HSA branch: foo (int n, int m, int o, int (*a)[m][o]) { int i, j, k; #pragma omp target teams distribute parallel for shared(a) firstprivate(n, m, o) private(i,j,k) for (i = 0; i < n; i++) for (j = 0; j < m; j++) fo

Re: varpool/constpool bug

> On 01/08/16 05:39, Richard Biener wrote: > > >Oh, and I _do_ belive that ultimatively we should have all constant pool > >entries (and CONST_DECLs) in the varpool. > > FWIW that certainly seems like the right goal. Indeed it is on my TODO. I need to make CONST_DECLs to have visibility (so they

[PR ipa/66616] Fix artificial thunk ABI issues

Hi, i386 -m32 failure of the PR 66616 testcase was caused by the fact that, on the callee side, the calling conventions of a thunk are decided according to the properties of the function it is associated with, but on the caller side, the actual thunk is examined. Since they depend on the can_chan

[PATCH] Remove PTX link option

Hi, This patch removes the constraint whereby the PTX emitted was only for sm_30 GPU's. With this removal, the PTX emitted will be targeted for the current context, i.e., attached GPU. Bootstrapped/regtested on x86_64-linux, ok for trunk? Thanks, Jim diff --git a/libgomp/plugin/plugin-nvptx.c b

Re: [PATCH] Remove PTX link option

On Fri, Jan 08, 2016 at 09:24:14AM -0600, James Norris wrote: > This patch removes the constraint whereby the PTX > emitted was only for sm_30 GPU's. With this removal, > the PTX emitted will be targeted for the current > context, i.e., attached GPU. > > Bootstrapped/regtested on x86_64-linux, ok

Re: [PATCH] Remove PTX link option

Jakub, On 01/08/2016 09:30 AM, Jakub Jelinek wrote: On Fri, Jan 08, 2016 at 09:24:14AM -0600, James Norris wrote: This patch removes the constraint whereby the PTX emitted was only for sm_30 GPU's. With this removal, the PTX emitted will be targeted for the current context, i.e., attached GPU.

Re: varpool/constpool bug

On January 8, 2016 4:13:17 PM GMT+01:00, Jan Hubicka wrote: >> On 01/08/16 05:39, Richard Biener wrote: >> >> >Oh, and I _do_ belive that ultimatively we should have all constant >pool >> >entries (and CONST_DECLs) in the varpool. >> >> FWIW that certainly seems like the right goal. >Indeed it i

Re: [PATCH] Remove PTX link option

On Fri, Jan 08, 2016 at 09:39:11AM -0600, James Norris wrote: > On 01/08/2016 09:30 AM, Jakub Jelinek wrote: > >On Fri, Jan 08, 2016 at 09:24:14AM -0600, James Norris wrote: > >>This patch removes the constraint whereby the PTX > >>emitted was only for sm_30 GPU's. With this removal, > >>the PTX em

[PR tree-optimization/64946] Push integer type conversion to ABS_EXPR argument when possible.

Hello, The C/C++ front-ends apply type conversions to expressions using ABS with integral arguments of type smaller than int. This means that, for short x, ABS(x) becomes something like (short)ABS((int)x)). When the argument is the result of memory access, this restricts the vectorizer apparently

Re: RFA (tree-cfg): PATCH for 68983 (ICE in copy constructor)

On 01/08/2016 06:18 AM, Richard Biener wrote: On Fri, Jan 8, 2016 at 8:22 AM, Eric Botcazou wrote: But it occurs to me that since the real problem I was trying to catch is creation of temporaries of TREE_ADDRESSABLE type in the back end, we should guard that instead. So this patch moves the as

Re: [PATCH] Remove PTX link option

Jakub, On 01/08/2016 09:44 AM, Jakub Jelinek wrote: On Fri, Jan 08, 2016 at 09:39:11AM -0600, James Norris wrote: On 01/08/2016 09:30 AM, Jakub Jelinek wrote: On Fri, Jan 08, 2016 at 09:24:14AM -0600, James Norris wrote: This patch removes the constraint whereby the PTX emitted was only for s

[PATCH v2, middle-end]: Fix PR68999, gfortran.fortran-torture/execute/save_1.f90 execution failure on alpha

Hello! Attached patch returns "unknown" from memrefs_conflict_p when realigned decls are processed. This is the same approach as is done at the end of memrefs_conflict_p. We still need early return for AND addresses in base_alias_check. 2016-01-08 Uros Bizjak PR middle-end/68999 * al

Re: [PATCH] Remove PTX link option

On 01/08/2016 04:44 PM, Jakub Jelinek wrote: And CU_JIT_TARGET / CU_TARGET_COMPUTE_30 requests JITting only on sm_30 and nothing else, or just on sm_30 or later, something else? This really should be reviewed by somebody familiar with CUDA more than myself. I'll defer to Nathan whether to ack t

Re: [PATCH] Remove PTX link option

On Fri, Jan 08, 2016 at 10:21:16AM -0600, James Norris wrote: > >And CU_JIT_TARGET / CU_TARGET_COMPUTE_30 requests JITting only on sm_30 and > >nothing else, or just on sm_30 or later, something else? > >This really should be reviewed by somebody familiar with CUDA more than > >myself. > > > > The

Re: [PATCH] Fix PR68707

On 08/01/16 11:45, Richard Biener wrote: > On Fri, 8 Jan 2016, Alan Lawrence wrote: > >> Here's an alternative patch, using the hunk from >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707#c16, which 'improves' >> (heh, >> we think) on the previous by allowing SLP to proceed where the loads ar

C++ PATCH for c++/68449 (segv with compound statement)

An attempt to fix c++/68449. We ICEd because pointer returned from ctx->values->get points to NULL, so checking DECL_P on that is no no. Fixed along the lines Jakub suggested in the PR. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2016-01-08 Marek Polacek PR c++/68449

Re: C PATCH to rectify warning for character types (PR c/23087)

On 01/07/2016 02:19 PM, Joseph Myers wrote: On Thu, 7 Jan 2016, Marek Polacek wrote: This PR points out that we issue a wrong warning message when assigning two pointers when one of them is plain char. In that case, the compiler currently says that pointer targets differ in signedness. But th

Re: [PATCH] Remove PTX link option

On 01/08/2016 10:32 AM, Jakub Jelinek wrote: On Fri, Jan 08, 2016 at 10:21:16AM -0600, James Norris wrote: And CU_JIT_TARGET / CU_TARGET_COMPUTE_30 requests JITting only on sm_30 and nothing else, or just on sm_30 or later, something else? This really should be reviewed by somebody familiar with

Re: C PATCH to rectify warning for character types (PR c/23087)

On 01/07/2016 10:19 PM, Joseph Myers wrote: I don't think it's desirable to raise the warning for this case under different conditions from the warning for other signedness cases. The targets do differ in signedness - it's just that the difference is between "plain" and "signed" or "plain" and

Re: C++ PATCH for c++/68449 (segv with compound statement)

On 01/08/2016 12:48 PM, Marek Polacek wrote: if (tree *p = ctx->values->get (r)) r = *p; - if (DECL_P (r)) + if (r == NULL_TREE || DECL_P (r)) I think it would be a bit better not to change r if *p is null. OK with that change. Jason

[PR 69044] Do not clone for parameter removal when !can_change_signature

Hi, we generally do not have ther ability to propagate constants to and clone CHKP instrumented functions. Therefore we do not propagate stuff into their lattices but since Honza changed cloning for all contexts heuristics a few weeks ago, we might attempt to clone them for unused parameter remov

Re: C PATCH to rectify warning for character types (PR c/23087)

On Fri, Jan 08, 2016 at 06:54:32PM +0100, Bernd Schmidt wrote: > On 01/07/2016 10:19 PM, Joseph Myers wrote: > > >I don't think it's desirable to raise the warning for this case under > >different conditions from the warning for other signedness cases. The > >targets do differ in signedness - it'

Re: C++ PATCH for c++/68449 (segv with compound statement)

On Fri, Jan 08, 2016 at 12:56:15PM -0500, Jason Merrill wrote: > On 01/08/2016 12:48 PM, Marek Polacek wrote: > > if (tree *p = ctx->values->get (r)) > > r = *p; > >- if (DECL_P (r)) > >+ if (r == NULL_TREE || DECL_P (r)) > > I think it would be a bit better not to change r if

[patch] libstdc++/14608 Add C++-conforming wrappers for stdlib.h and math.h

This resolves the longstanding issue that #include uses the C library header, which on most targets doesn't declare the additional overloads required by C++11 26.8 [c.math], and similarly for . With this patch libstdc++ provides its own and wrappers, which are equivalent to or followed by us

Re: [ARM][PR69194] Fix ICE in in extract_insn

Here is a smaller simpler testcase. Only the first four args get passed in regs, so the fifth one has address equal to the virtual incoming args reg which triggers the failure. typedef __simd128_float32_t float32x4_t; float32x4_t sub (float32x4_t a, float32x4_t b, float32x4_t c, float32x4_t d, fl

Re: [ARM][PR69194] Fix ICE in in extract_insn

On Fri, Jan 08, 2016 at 11:43:34AM -0800, Jim Wilson wrote: > Here is a smaller simpler testcase. Only the first four args get > passed in regs, so the fifth one has address equal to the virtual > incoming args reg which triggers the failure. > > typedef __simd128_float32_t float32x4_t; > float32

[PATCH] Fix X % -Y => X % Y optimization (PR tree-optimization/69097, PR middle-end/50865)

Hi! As mentioned in the PRs, the X % -Y to X % Y optimization for signed modulo is not valid unless we can prove that it won't be INT_MIN % -(-1), which is valid, but where INT_MIN % -1 is invalid. The following patch use range info to figure that out. Bootstrapped/regtested on x86_64-linux and i

[PATCH] Fix (ab) SSA_NAME issue in gimple folding (PR tree-optimization/69167, take 2)

Hi! On Fri, Jan 08, 2016 at 10:12:09AM +0100, Richard Biener wrote: > On Thu, 7 Jan 2016, Jakub Jelinek wrote: > > > Hi! > > > > Various places check that (ab) SSA_NAMEs that weren't referenced on a stmt > > before don't appear on it, but all the checking is done on the gimple tuple > > operands

[C++ PATCH] Fix ICE with bitfields (PR c++/69164, take 2)

On Fri, Jan 08, 2016 at 09:02:34AM -0500, Jason Merrill wrote: > On 01/08/2016 07:58 AM, Jakub Jelinek wrote: > >On Fri, Jan 08, 2016 at 01:46:47PM +0100, Bernd Schmidt wrote: > >>On 01/07/2016 10:43 PM, Jakub Jelinek wrote: > >>> > >>> PR c++/69164 > >>> * class.c (layout_class_type): Also cop

Re: [PR ipa/66616] Fix artificial thunk ABI issues

> Hi, > > i386 -m32 failure of the PR 66616 testcase was caused by the fact > that, on the callee side, the calling conventions of a thunk are > decided according to the properties of the function it is associated > with, but on the caller side, the actual thunk is examined. Since > they depend o

[PATCH] Fix ICE due to invalid CONST_INT in DEBUG_INSN (PR target/69071)

Hi! The following testcase ICEs, because move_plus_up attempts to optimize (subreg:HI (plus:SI (...) (const_int 0xff78)) 0) into (plus:HI (subreg:HI (...) 0) (const_int 0xff78)) which is incorrect, HImode CONST_INT with MSB set should be (const_int -136) instead. The patch also punts if the secon

C++ PATCH for c++/69113 (ICE with -fno-weak)

Looking at the second Jason's patch here it seems that we should never set DECL_COMDAT on a decl that is !TREE_PUBLIC. The following test was breaking with -fno-weak, because there we set DECL_COMDAT on something that was !TREE_PUBLIC and

[PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

Hi! As mentioned in the PR, sched1 and reload add NOTE_INSN_DELETED notes that are moved by shrink-wrapping in between some basic blocks and later on we end up with a barrier after the notes. From comments above cleanup_barriers pass I think it isnot invalid, and various other places deal with no

[PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

Hi! This patch fixes FAIL: gcc.target/i386/avx512vl-vmovapd-1.c scan-assembler-times vmovapd[ t]+[^{\\n]*%xmm[0-9]+[^\\n]*){%k[1-7]}(?:\\n|[ t]+#) 1 FAIL: gcc.target/i386/avx512vl-vmovapd-1.c scan-assembler-times vmovapd[ t]+[^{\\n]*%ymm[0-9]+[^\\n]*){%k[1-7]}(?:\\n|[ t]+

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 12:20 PM, Jakub Jelinek wrote: > Hi! > > This patch fixes > FAIL: gcc.target/i386/avx512vl-vmovapd-1.c scan-assembler-times vmovapd[ > t]+[^{\\n]*%xmm[0-9]+[^\\n]*){%k[1-7]}(?:\\n|[ t]+#) 1 > FAIL: gcc.target/i386/avx512vl-vmovapd-1.c scan-assembler-times vmovap

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 08, 2016 at 12:28:43PM -0800, H.J. Lu wrote: > gcc.target/i386/avx512vl-vmovapd-1.c has > > --- > include > > double *p; > volatile __m256d yy, y2; > volatile __m128d xx, x2; > volatile __mmask8 m; > > void extern > avx512vl_test (void) > { > yy = _mm256_mask_mov_pd (yy, m, y2); >

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 12:35 PM, Jakub Jelinek wrote: > On Fri, Jan 08, 2016 at 12:28:43PM -0800, H.J. Lu wrote: >> gcc.target/i386/avx512vl-vmovapd-1.c has >> >> --- >> include >> >> double *p; >> volatile __m256d yy, y2; >> volatile __m128d xx, x2; >> volatile __mmask8 m; >> >> void extern >> a

Re: [PATCH] Fix (ab) SSA_NAME issue in gimple folding (PR tree-optimization/69167, take 2)

On January 8, 2016 9:08:36 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >On Fri, Jan 08, 2016 at 10:12:09AM +0100, Richard Biener wrote: >> On Thu, 7 Jan 2016, Jakub Jelinek wrote: >> >> > Hi! >> > >> > Various places check that (ab) SSA_NAMEs that weren't referenced on >a stmt >> > before don't ap

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 08, 2016 at 12:39:50PM -0800, H.J. Lu wrote: > > p is not misaligned, it has just unknown alignment. > > And it may be 8 byte aligned. Yes. But if you call the routine with just 8 byte aligned p, you invoke undefined behavior. So, there is nothing wrong on the testcase, it tests wha

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 12:44 PM, Jakub Jelinek wrote: > On Fri, Jan 08, 2016 at 12:39:50PM -0800, H.J. Lu wrote: >> > p is not misaligned, it has just unknown alignment. >> >> And it may be 8 byte aligned. > > Yes. But if you call the routine with just 8 byte aligned p, > you invoke undefined beh

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 08, 2016 at 12:46:01PM -0800, H.J. Lu wrote: > On Fri, Jan 8, 2016 at 12:44 PM, Jakub Jelinek wrote: > > On Fri, Jan 08, 2016 at 12:39:50PM -0800, H.J. Lu wrote: > >> > p is not misaligned, it has just unknown alignment. > >> > >> And it may be 8 byte aligned. > > > > Yes. But if you

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On 01/08/2016 09:17 PM, Jakub Jelinek wrote: As mentioned in the PR, sched1 and reload add NOTE_INSN_DELETED notes that are moved by shrink-wrapping in between some basic blocks and later on we end up with a barrier after the notes. From comments above cleanup_barriers pass I think it isnot inva

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 12:48 PM, Jakub Jelinek wrote: > On Fri, Jan 08, 2016 at 12:46:01PM -0800, H.J. Lu wrote: >> On Fri, Jan 8, 2016 at 12:44 PM, Jakub Jelinek wrote: >> > On Fri, Jan 08, 2016 at 12:39:50PM -0800, H.J. Lu wrote: >> >> > p is not misaligned, it has just unknown alignment. >> >>

[PATCH] PR preprocessor/69177 and PR c++/68819: libcpp fallbacks and -Wmisleading-indentation (v2)

On Mon, 2015-12-21 at 14:10 -0700, Jeff Law wrote: > On 12/18/2015 01:21 PM, David Malcolm wrote: > > > I don't think there's a way to fix -Wmisleading-indentation if we're > > in this state, so the first part of the following patch detects if > > this has happened, and effectively turns off -Wmisl

FIx ipa-icf ICE during libreoffice build

Hi, this patch fixes an ICE on artificial VAR_DECL that has no DECL_NAME set. unit size align 16 symtab 0 alias set -1 canonical type 0x2bdd9738 precision 16 min max pointer_to_this reference_to_this > HI size unit size align 16 sym

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On Fri, Jan 08, 2016 at 10:09:37PM +0100, Bernd Schmidt wrote: > On 01/08/2016 09:17 PM, Jakub Jelinek wrote: > >As mentioned in the PR, sched1 and reload add NOTE_INSN_DELETED notes > >that are moved by shrink-wrapping in between some basic blocks and > >later on we end up with a barrier after the

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 08, 2016 at 01:14:04PM -0800, H.J. Lu wrote: > I think the testcase should be changed to > > double __attribute__ ((aligned (32))) *p; No. > > and I am testing a different patch by removing the whole > aligned_mem stuff. That is just wrong and will severely pessimize correct code. P

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 1:23 PM, Jakub Jelinek wrote: > On Fri, Jan 08, 2016 at 01:14:04PM -0800, H.J. Lu wrote: >> I think the testcase should be changed to >> >> double __attribute__ ((aligned (32))) *p; FYI, gcc.target/i386/avx512vl-vmovaps-1.c has float __attribute__ ((aligned (32))) *p; >

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 08, 2016 at 01:27:08PM -0800, H.J. Lu wrote: > > That is just wrong and will severely pessimize correct code. > > Please don't waste time on that. > > > > Do you have an example to show it will pessimize correct code? Anything where the compiler can't figure out alignment info and you

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 1:38 PM, Jakub Jelinek wrote: > On Fri, Jan 08, 2016 at 01:27:08PM -0800, H.J. Lu wrote: >> > That is just wrong and will severely pessimize correct code. >> > Please don't waste time on that. >> > >> >> Do you have an example to show it will pessimize correct code? > > Anyt

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 1:43 PM, H.J. Lu wrote: > On Fri, Jan 8, 2016 at 1:38 PM, Jakub Jelinek wrote: >> On Fri, Jan 08, 2016 at 01:27:08PM -0800, H.J. Lu wrote: >>> > That is just wrong and will severely pessimize correct code. >>> > Please don't waste time on that. >>> > >>> >>> Do you have an

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 1:53 PM, H.J. Lu wrote: > On Fri, Jan 8, 2016 at 1:43 PM, H.J. Lu wrote: >> On Fri, Jan 8, 2016 at 1:38 PM, Jakub Jelinek wrote: >>> On Fri, Jan 08, 2016 at 01:27:08PM -0800, H.J. Lu wrote: > That is just wrong and will severely pessimize correct code. > Please d

Re: [PATCH] Fix memory alignment on AVX512VL masked floating point stores (PR target/69198)

On Fri, Jan 8, 2016 at 1:59 PM, H.J. Lu wrote: > On Fri, Jan 8, 2016 at 1:53 PM, H.J. Lu wrote: >> On Fri, Jan 8, 2016 at 1:43 PM, H.J. Lu wrote: >>> On Fri, Jan 8, 2016 at 1:38 PM, Jakub Jelinek wrote: On Fri, Jan 08, 2016 at 01:27:08PM -0800, H.J. Lu wrote: > > That is just wrong and

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On 01/08/2016 02:23 PM, Jakub Jelinek wrote: 4) compgotos moves things around even further: ... (jump_insn 118 99 91 5 (simple_return) -1 (nil) -> simple_return) ;; succ: EXIT [100.0%] ;; lr out 0 [r0] 2 [r2] 4 [r4] 13 [sp] 14 [lr] ;; live out 0 [r0] 2 [r2] 4 [r4] 13 [s

Re: [PATCH] Handle inter-block notes before BARRIER in rtl merge_blocks (PR target/69175)

On 01/08/2016 10:23 PM, Jakub Jelinek wrote: Now, the merge_if_block caller removes the simple_return from the then_bb in preparation of the merge and expects the two bbs to be merged together, I'd be tempted to remove the barrier as well at this point. It does look like the cfgrtl code tries

  1   2   >