[PATCH] Fix up wrong-code caused by store_expr (PR middle-end/90025)

Hi! In r268957 aka PR66152 fix I've slightly changed the store_expr code which does store_by_pieces for just a part of an array and clear_storage for the rest and since then the following testcase is miscompiled on s390x-linux. I believe one could construct other testcase that would be miscompile

AW: [Patch, fortran] PRs 89843 and 90022 - C Fortran Interop fixes.

Hi Gilles, > > I also found an other potential issue with copy-in. > > If in Fortran, we > > call foo(buf(0,0)) > > then the C subroutine can only access buf(0,0), and other elements such > as buf(1025,1025) cannot be accessed. > > Such elements are valid in buf, but out of bounds in the copy (tha

Re: [PATCH] Fix up wrong-code caused by store_expr (PR middle-end/90025)

On Wed, 10 Apr 2019, Jakub Jelinek wrote: > Hi! > > In r268957 aka PR66152 fix I've slightly changed the store_expr > code which does store_by_pieces for just a part of an array and > clear_storage for the rest and since then the following testcase > is miscompiled on s390x-linux. I believe one

Re: [PATCH][stage1] Support profile (BB counts and edge probabilities) in GIMPLE FE.

On 4/9/19 3:19 PM, Jan Hubicka wrote: >> Hi. >> >> There's updated version that supports profile quality for both counts >> and probabilities. I'm wondering whether ENTRY and EXIT BBs needs to >> have set probability. Apparently, I haven't seen any verifier that >> would complain. > > Well, you do

[aarch64] PR90016 - aarch64: reference to undeclared N in help for command line option

'to N' is now redundant and misleading given the earlier change to use . Removed * config/aarch64/aarch64.opt (msve-vector-bits): Remove redundant and obsolete reference to N. R. diff --git a/gcc/config/aarch64/aarch64.opt b/gcc/config/aarch64/aarch64.opt index 5a1e687091c..3dc76

Re: [Patch] PR rtl-optimization/87763 - generate more bfi instructions on aarch64

On 01/04/2019 18:23, Steve Ellcey wrote: > This is a ping**3 for a patch to fix one of the test failures in PR 877763. > It fixes the gcc.target/aarch64/combine_bfi_1.c failure, but not the other > ones. > > Could one of the Aarch64 maintainers take a look at it? This version of > the patch was o

Re: [PATCH] Add PSTL internal namespace qualifications

On 09/04/19 14:48 -0700, Thomas Rodgers wrote: Committed to trunk. Thanks! For the record, I approved the patch over IRC but I forgot to say so on the list.

[PATCH] Clearly document behaviour of multiple -g options

This copies the wording from the -O options to clearly state what happens if more than one -g option is used. * doc/invoke.texi (Debugging Options): Explicitly state the semantics of using multiple -g options. OK for trunk? commit 9d950d2398b0a01358520a1c0a69bbe46ba7d997 Author

Re: [PATCH] Remove unused DR_GROUP_SAME_DR_STMT

yOn Tue, 9 Apr 2019, Richard Biener wrote: > > While looking at PR90018 I figured DR_GROUP_SAME_DR_STMT is never > set since GCC 4.9. The following removes it to confuse the > occasional reader of the vectorizer code less. > > Bootstrap / regtest in progress on x86_64-unknown-linux-gnu. Testin

PR90030 "Fortran OpenACC subarray data alignment" (was: [PATCH] Fortran OpenMP 4.0 target support)

Hi Jakub! In context of PR90030 "Fortran OpenACC subarray data alignment" (which actually is reproducible for OpenMP with nvptx offloading in the very same way, see below), can you please explain the reason for the seven "[var] = fold_convert (build_pointer_type (char_type_node), [var])" instances

[PATCH] Fix PR90018

The following patch will fix the 527.cam4_r regression on the branch (backport in testing, 2nd patch). The issue is latent on trunk, trunk avoids the offening grouping in more intelligent way. Bootstrap & regtest running on x86_64-unknown-linux-gnu. Richard. 2019-04-10 Richard Biener

Re: [PATCH] Clearly document behaviour of multiple -g options

On 4/10/19 5:18 AM, Jonathan Wakely wrote: This copies the wording from the -O options to clearly state what happens if more than one -g option is used. * doc/invoke.texi (Debugging Options): Explicitly state the semantics of using multiple -g options. OK for trunk? Looks fine to me

Re: [PATCH][Version 3]Come up with -flive-patching master option.

On 20/11/18 09:32 -0600, Qing Zhao wrote: Hi, this is the newest version of the patch. major changes: 1. format fixes raised by Martin; 2. output error when disabled IPA optimizations are turned on explicitly by the user with -flive-patching at the same time. based on Ho

Re: [Patch, libstdc++.exp]Update the usage of cached result, rebuild nlocale wrapper for each variant.

On 11/03/19 11:54 +, Jonathan Wakely wrote: Hi, I've just noticed this in your r266209 change from November: On 16/11/18 10:42 +, Renlin Li wrote: +return [check_v3_target_prop_cached et_parallel_mode { + global cxxflags + global v3-libgomp # If 'make check-paral

[PATCH] Change wording of -fipa-icf documentation

* doc/invoke.texi (Optimize Options): Change "Nevertheless" to "Although" in -fipa-icf documentation. THe old wording doesn't make sense, so committed to trunk as obvious. commit a2a452bc8191a7ec0ec910a44484c1aab89154d6 Author: Jonathan Wakely Date: Wed Apr 10 15:49:50 2019 +0

[PATCH] S/390: Add arch13 pipeline description

Hi, this patch adds the pipeline description and the cpu model number for arch13. Bootstrapped and regtested on s390x. Regards Robin -- gcc/ChangeLog: 2019-04-10 Robin Dapp * config/s390/8561.md: New file. * config/s390/driver-native.c (s390_host_detect_local_cpu): Add ar

Re: [PATCH] D support for RISC-V

On Wed, 10 Apr 2019 at 01:58, Jim Wilson wrote: > > On Tue, Apr 9, 2019 at 10:36 AM Iain Buclaw wrote: > > Any objection if I upstream the non-asm bits? > > Doesn't all of it, except maybe the configure.tgt patch need to go > upstream first? And do you need some paperwork or button click from >

Re: [PATCH] S/390: Add arch13 pipeline description

On 10.04.19 17:19, Robin Dapp wrote: > 2019-04-10 Robin Dapp > > * config/s390/8561.md: New file. > * config/s390/driver-native.c (s390_host_detect_local_cpu): Add arch13 > cpu model. > * config/s390/s390-opts.h (enum processor_type): Likewise. > * config/s390/s390.c (s3

[PATCH] Fix __patchable_function_entries section flags

When -fpatchable-relocation-entry is used, gcc places nops on the prologue of each compiled function and creates a section named __patchable_function_entries which holds relocation entries for the positions in which the nops were placed. As is, gcc creates this section without the proper section fl

Re: [PATCH] Fix __patchable_function_entries section flags

On Wed, Apr 10, 2019 at 03:00:43PM -0300, Joao Moreira wrote: > When -fpatchable-relocation-entry is used, gcc places nops on the > prologue of each compiled function and creates a section named > __patchable_function_entries which holds relocation entries for the > positions in which the nops were

Re: [PATCH][Version 3]Come up with -flive-patching master option.

Hi, Jonathan, thanks for your review on the documentation change for -flive-patching option. > >> --- a/gcc/doc/invoke.texi >> +++ b/gcc/doc/invoke.texi >> @@ -416,6 +416,7 @@ Objective-C and Objective-C++ Dialects}. >> -fipa-bit-cp -fipa-vrp @gol >> -fipa-pta -fipa-profile -fipa-pure-const -

[PATCH] Update documentation regarding bogus memory leaks in libstdc++

* doc/xml/faq.xml: Add information about emergency EH pool. * doc/xml/manual/debug.xml: Update list of memory debugging tools. Move outdated information on mt_allocator to a separate section. * doc/xml/manual/evolution.xml: Clarify that GLIBCXX_FORCE_NEW doe

Re: [PATCH][Version 3]Come up with -flive-patching master option.

On 10/04/19 13:55 -0500, Qing Zhao wrote: Hi, Jonathan, thanks for your review on the documentation change for -flive-patching option. --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -416,6 +416,7 @@ Objective-C and Objective-C++ Dialects}. -fipa-bit-cp -fipa-vrp @gol -fipa-pta -fipa

Re: [PATCH] Replace direct PSTL uses of assert() with a macro

On 09/04/19 15:23 -0700, Thomas Rodgers wrote: This also replaces calls to __TBB_ASSERT so that there are two macro definitions provided by c++config - __PSTL_ASSERT(_Condition) __PSTL_ASSERT_MSG(_Condition, _Message) * include/bits/c++config: Add

Re: [Patch] PR rtl-optimization/87763 - generate more bfi instructions on aarch64

On Wed, 2019-04-10 at 11:10 +0100, Richard Earnshaw (lists) wrote: > > OK with those changes. > > R. I made the changes you suggested and checked in the patch. Just to be complete, here is the final version of the patch that I checked in. 2018-04-10 Steve Ellcey PR rtl-optimization

Re: [PATCH] Implement std::visit for C++2a (P0655R1)

On 08/04/19 19:54 +0100, Jonathan Wakely wrote: On 08/04/19 17:36 +0100, Jonathan Wakely wrote: On 08/04/19 19:20 +0300, Ville Voutilainen wrote: On Mon, 8 Apr 2019 at 19:12, Ville Voutilainen wrote: On Mon, 8 Apr 2019 at 19:02, Jonathan Wakely wrote: The attached patch implements the same

[PATCH 0/3] OpenRISC floating point support + fixes

Hello, This is a set of patches to bring FPU support to the OpenRISC backend. The backend also add support for 64-bit floating point operations on 32-bit cores using register pairs, see orfpx64a32 [0]. This depends on binutils patches which have also been submitted per review. [1] The toolchain

[PATCH 1/3] or1k: Initial support for FPU

Or1k only supports ordered compares so we fall back to lib functions for unordered operations. Doubles work on this 32-bit architecture by using register pairing as specified in: https://openrisc.io/proposals/orfpx64a32 Or1k does not support sf/df or df/sf conversions. gcc/ChangeLog: *

[PATCH 2/3] or1k: Allow volatile memory for sign/zero extend loads

Volatile memory does not match the memory_operand predicate. This causes extra extend/mask instructions instructions when reading from volatile memory. On OpenRISC this can be treated the same as regular memory. gcc/ChangeLog: * config/or1k/or1k.md (zero_extendsi2): Update predicate.

[PATCH 3/3] or1k: only force reg for immediates

The force_reg in or1k_expand_compare is hard coded for SImode, which is fine as this used to only be used on SI expands. However, with FP support this will cause issues. In general we should only force the right hand operand to a register if its an immediate. This patch adds an condition to chec

Re: [PATCH 1/3] [ARC] Emit blockage regardless to avoid delay slot scheduling.

* Claudiu Zissulescu [2019-03-25 12:03:11 +0100]: > 1.The delay slot scheduler can reschedule some of the frame related > instructions resulting in having incorect CFI information. This patch > introduces a schedule blockage to avoid this problem. > > 2.There are cases when an interrupt may happ

Re: [PATCH 2/3] [ARC] Refurb eliminate regs.

* Claudiu Zissulescu [2019-03-25 12:03:12 +0100]: > Refurbish eliminable regs howto by introducing a fake > FRAME_POINTER_REGNUM with the purpose to release FP register to be > used freely by the register allocator. > > gcc/ > -xx-xx Claudiu Zissulescu > > * config/arc/arc.c (arc_h

Re: [PATCH 3/3] [ARC] Remove Rs5 constraint.

* Claudiu Zissulescu [2019-03-25 12:03:13 +0100]: > New LRA algorithms require the all the register constraints to be > defined using define_register_constraint keyword. However, Rs5 > constraint was not LRA proof. Remove it and replace it by equivalent > Rcd constraint. > > gcc/ > -xx-xx C

[Patch] [Aarch64] PR rtl-optimization/87763 - this patch fixes gcc.target/aarch64/lsl_asr_sbfiz.c

Here is another patch to fix one of the failures listed in PR rtl-optimization/87763. This change fixes gcc.target/aarch64/lsl_asr_sbfiz.c by adding an alternative version of *ashiftsi_extv_bfiz that has a subreg in it. Tested with bootstrap and regression test run. OK for checkin? Steve Ellcey

Re: [Patch] [Aarch64] PR rtl-optimization/87763 - this patch fixes gcc.target/aarch64/lsl_asr_sbfiz.c

On Wed, 2019-04-10 at 15:03 -0700, Steve Ellcey wrote: > Here is another patch to fix one of the failures > listed in PR rtl-optimization/87763. This change > fixes gcc.target/aarch64/lsl_asr_sbfiz.c by adding > an alternative version of *ashiftsi_extv_bfiz that > has a subreg in it. > > Tested wi

Re: [PATCH] Replace direct PSTL uses of assert() with a macro

Ok, lets try this again. > On 09/04/19 15:23 -0700, Thomas Rodgers wrote: >>This also replaces calls to __TBB_ASSERT so that there are two macro >>definitions provided by c++config - >> __PSTL_ASSERT(_Condition) >> __PSTL_ASSERT_MSG(_Condition, _Message) >> >> * include/

Re: [PATCH] Replace direct PSTL uses of assert() with a macro

On 10/04/19 15:57 -0700, Thomas Rodgers wrote: Ok, lets try this again. On 09/04/19 15:23 -0700, Thomas Rodgers wrote: This also replaces calls to __TBB_ASSERT so that there are two macro definitions provided by c++config - __PSTL_ASSERT(_Condition) __PSTL_ASSERT_MSG(_C

Re: [PATCH] Replace direct PSTL uses of assert() with a macro

On 10/04/19 23:59 +0100, Jonathan Wakely wrote: On 10/04/19 15:57 -0700, Thomas Rodgers wrote: Ok, lets try this again. On 09/04/19 15:23 -0700, Thomas Rodgers wrote: This also replaces calls to __TBB_ASSERT so that there are two macro definitions provided by c++config - __PSTL_AS