[PATCH] Fix newlib build failure for mips16

The mips64vr-elf target will fail building newlib, particularly the mips16 newlib as we emit bogus assembly code. In particular the compiler will emit something like lwu $2,0($sp) That's invalid in mips16 mode AFAICT. That's emitted by the extendsidi pattern. It's a case where the

Re: [PATCH] Fix fixincludes for canadian cross builds

On 04/12/17 17:58, Yvan Roux wrote: > Hi, > > On 20 February 2017 at 18:53, Bruce Korb wrote: >> On 02/18/17 01:01, Bernd Edlinger wrote: >>> On 02/18/17 00:37, Bruce Korb wrote: On 02/06/17 10:44, Bernd Edlinger wrote: > I tested this change with different

Re: port contrib/download_prerequisites script to macOS

Resending as plain text:  On April 12, 2017 at 3:03:19 PM, Jeff Law (l...@redhat.com(mailto:l...@redhat.com)) wrote:    > >   > > 2017-04-05 Damian Rouson   > >   > > * download_prerequisites (md5_check): New function emulates Linux   > > 'md5 --check' on macOS. Modified script for macOS

Re: [PATCH] Fix PR51513, switch statement with default case containing __builtin_unreachable leads to wild branch

Bah, fixing up my return address. On 4/13/17 3:14 AM, Richard Biener wrote: > To recap the situation (from what I can deciper out of the ppc asm > and the expand RTL) we seem to expand to > > if (cond > 2) > __builtin_unreachable (); // jumps to the jump table data(?) > goto *tbl[cond];

[PATCH] Fix NVPTX offloading with dynamic libcuda.so.1 loading on powerpc

Hi! Finally got to debug why most libgomp offloading tests fail on powerpc64le-linux when configured for NVPTX offloading. The problem is -funsigned-char by default, so if (cuda_lib_inited != -1) was always true. Fixed thusly, bootstrapped/regtested on x86_64-linux and powerpc64le-linux,

Re: [PATCH] Fix another fold-const.c type bug (PR sanitizer/80403)

On Wed, Apr 12, 2017 at 06:12:57PM +0200, Jakub Jelinek wrote: > @@ -11542,7 +11544,7 @@ fold_ternary_loc (location_t loc, enum t > && (code == VEC_COND_EXPR || !VECTOR_TYPE_P (type))) > return fold_build2_loc (loc, code == VEC_COND_EXPR ? BIT_AND_EXPR >

Re: [wwwdocs,fortran] Update link to CHKSYS

On 04/13/2017 02:13 AM, Arjen Markus wrote: > Hi Gerald, Jerry, > > as the author of this program (and the maintainer of that site) I am > honoured that you refer to this. But I would like to tell you a bit > about the history: > I started CHKSYS in the time that FORTRAN 77 was still the main >

Re: [PR 80293] Don't totally-sRA char arrays

On April 13, 2017 7:41:29 PM GMT+02:00, Martin Jambor wrote: >Hi, > >On Wed, Apr 12, 2017 at 01:55:01PM +0200, Richard Biener wrote: >> On Wed, 12 Apr 2017, Martin Jambor wrote: >> >> > Hi, >> > >> > the patch below is an attempt to deal with PR 80293 as >non-invasively >> > as

Re: [PATCH][PR sanitizer/80414] Fix segfault with -fsanitize=undefined on 32 bit host

On Thu, Apr 13, 2017 at 05:56:56PM +0300, Maxim Ostapenko wrote: > Hi, > > I've applied the patch for Denis in r246909. Also, the issue seems to appear > at least in GCC 6 (and perhaps in 5, I need to check). > Is it OK to apply the patch on branches after testing? Yes. Jakub

Re: [Patch, fortran] PR34360 (Comment 28) - ICE when assigning item of a derived-component to a pointer

Dear Dominique, The attached fixes the problem withPR51218 and bootstraps and regtests on FC23/x86_64 - OK for trunk? Cheers Paul 2017-04-13 Paul Thomas PR fortran/34640 * expr.c (gfc_check_pointer_assign): Exclude pointer array components in test for

patch to fix PR80343

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

Re: [PR 80293] Don't totally-sRA char arrays

Hi, On Wed, Apr 12, 2017 at 01:55:01PM +0200, Richard Biener wrote: > On Wed, 12 Apr 2017, Martin Jambor wrote: > > > Hi, > > > > the patch below is an attempt to deal with PR 80293 as non-invasively > > as possible. Basically, it switches off total SRA scalarization of > > any local

Re: [PATCH][PR sanitizer/80414] Fix segfault with -fsanitize=undefined on 32 bit host

Hi, I've applied the patch for Denis in r246909. Also, the issue seems to appear at least in GCC 6 (and perhaps in 5, I need to check). Is it OK to apply the patch on branches after testing? -Maxim On 13/04/17 17:03, Jakub Jelinek wrote: On Thu, Apr 13, 2017 at 04:55:52PM +0300, Denis

Re: [PATCH] Fix subreg in debug_insn handling issue exposed on mn103

On 04/13/2017 08:06 AM, Jakub Jelinek wrote: On Thu, Apr 13, 2017 at 08:03:48AM -0600, Jeff Law wrote: The mn103 port fails to build newlib/libgcc because it's got a non-simplifyable (subreg (mem)) in a debug insn. reload will call eliminate_regs_1 on the debug insn. It'll see the subreg and

Re: [PATCH] Fix subreg in debug_insn handling issue exposed on mn103

On Thu, Apr 13, 2017 at 08:03:48AM -0600, Jeff Law wrote: > > The mn103 port fails to build newlib/libgcc because it's got a > non-simplifyable (subreg (mem)) in a debug insn. > > reload will call eliminate_regs_1 on the debug insn. It'll see the subreg > and call gen_rtx_SUBREG. That asserts

Re: [PATCH][PR sanitizer/80414] Fix segfault with -fsanitize=undefined on 32 bit host

On Thu, Apr 13, 2017 at 04:55:52PM +0300, Denis Khalikov wrote: > +2017-04-13 Denis Khalikov > + > + PR sanitizer/80414 > + * ubsan.c (ubsan_expand_bounds_ifn): Fix wrong tree val generation > + for 32 bit host. I'd say here instead ...): Pass

[PATCH] Fix subreg in debug_insn handling issue exposed on mn103

The mn103 port fails to build newlib/libgcc because it's got a non-simplifyable (subreg (mem)) in a debug insn. reload will call eliminate_regs_1 on the debug insn. It'll see the subreg and call gen_rtx_SUBREG. That asserts that the subreg is valid. Which (of course) fails. The key here

Re: [PATCH][PR sanitizer/80414] Fix segfault with -fsanitize=undefined on 32 bit host

Thanks for review. I updated the patch. On 04/13/2017 04:10 PM, Jakub Jelinek wrote: On Thu, Apr 13, 2017 at 12:28:40PM +0300, Denis Khalikov wrote: --- /dev/null +++ b/gcc/testsuite/c-c++-common/ubsan/bounds-15.c @@ -0,0 +1,11 @@ +/* { dg-do run } */ +/* { dg-options "-fsanitize=bounds" }

Re: RFC: seeking insight on store_data_bypass_p (recog.c)

On 04/12/2017 06:33 PM, Kelvin Nilsen wrote: > > 1. As input arguments, out_insn represents an rtl expression that > potentially "produces" a store to memory and in_insn represents an rtl > expression that potentially "consumes" a value recently stored to memory. > You have this reversed, the

Re: [PATCH][PR sanitizer/80414] Fix segfault with -fsanitize=undefined on 32 bit host

On Thu, Apr 13, 2017 at 12:28:40PM +0300, Denis Khalikov wrote: > --- /dev/null > +++ b/gcc/testsuite/c-c++-common/ubsan/bounds-15.c > @@ -0,0 +1,11 @@ > +/* { dg-do run } */ > +/* { dg-options "-fsanitize=bounds" } */ > +/* { dg-skip-if "" { *-*-* } { "*" } { "-O0" } } */ > + > +int main() > +{ >

Re: [PATCH][GCC] Simplification of 1U << (31 - x)

Richard Biener wrote: > It is IMHO a valid GIMPLE optimization / canonicalization. > >    movabsq $-9223372036854775808, %rax > > so this should then have been generated as 1<<63? > > At some point variable shifts were quite expensive as well.. Yes I don't see a major difference between

Re: [PATCH][GCC] Simplification of 1U << (31 - x)

On Thu, Apr 13, 2017 at 01:49:01PM +0200, Richard Biener wrote: > It is IMHO a valid GIMPLE optimization / canonicalization. As I said, we can do it as GIMPLE canonicalization, but we should have code to undo it if beneficial at RTL level. And the patch has not included that. > > movabsq

Re: [PATCH][GCC] Simplification of 1U << (31 - x)

On Thu, Apr 13, 2017 at 1:41 PM, Jakub Jelinek wrote: > On Thu, Apr 13, 2017 at 11:33:12AM +, Wilco Dijkstra wrote: >> Jakub Jelinek wrote: >> >> > No. Some constants sometimes even 7 instructions (e.g. sparc64; not >> > talking >> > in particular about 1ULL << 63

Re: [PATCH][GCC] Simplification of 1U << (31 - x)

On Thu, Apr 13, 2017 at 11:33:12AM +, Wilco Dijkstra wrote: > Jakub Jelinek wrote: >   > > No.  Some constants sometimes even 7 instructions (e.g. sparc64; not talking > > in particular about 1ULL << 63 constant), or have one instruction > > that is more expensive than normal small constant

Re: [PATCH][GCC] Simplification of 1U << (31 - x)

Jakub Jelinek wrote:   > No.  Some constants sometimes even 7 instructions (e.g. sparc64; not talking > in particular about 1ULL << 63 constant), or have one instruction > that is more expensive than normal small constant load.  Compare say x86_64 > movl/movq vs. movabsq, I think the latter has

Re: [PATCH] Do not call memcpy with a NULL argument (PR gcov-profile/80413).

On 04/13/2017 07:19 AM, Martin Liška wrote: Hello. As the function is called with argument equal to zero, the memcpy should be done just in case alloc is greater than zero. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. And gcov.exp works on x86_64-linux-gnu. the

Re: [PATCH][GCC] Simplification of 1U << (31 - x)

On Thu, Apr 13, 2017 at 11:16:08AM +, Wilco Dijkstra wrote: > >On Wed, Apr 12, 2017 at 09:29:55AM +, Sudi Das wrote: > > > Hi all > > > > > > This is a fix for PR 80131 > > > Currently the code A << (B - C) is not simplified. > >> However at least a more specific case of 1U << (C -x)

[PATCH] Do not call memcpy with a NULL argument (PR gcov-profile/80413).

Hello. As the function is called with argument equal to zero, the memcpy should be done just in case alloc is greater than zero. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. And gcov.exp works on x86_64-linux-gnu. Ready to be installed? Martin >From

Re: [PATCH][GCC] Simplification of 1U << (31 - x)

>On Wed, Apr 12, 2017 at 09:29:55AM +, Sudi Das wrote: > > Hi all > > > > This is a fix for PR 80131 > > Currently the code A << (B - C) is not simplified. >> However at least a more specific case of 1U << (C -x) where C = >> precision(type) - 1 can be simplified to (1 << C) >> x. > > Is

[patch, gomp4, committed] Adjust copy/copyin/copyout/create for OpenACC 2.5

The behavior of the copy/copyin/copyout/create clauses has been changed in OpenACC 2.5 to be like the present_or_* variants, and the original present_or_* syntax relegated to legacy status. This patch removes the presence of any PRESENT_OR_* symbols, and changes the mapping of the

Re: [PATCH] Fix PR51513, switch statement with default case containing __builtin_unreachable leads to wild branch

On Thu, Apr 13, 2017 at 10:14:51AM +0200, Richard Biener wrote: > now I do not remember the reason why we keep __builtin_unreachable () > at the RTL level -- on GIMPLE we keep it to be able to extract I believe we don't. In RTL __builtin_unreachable () is represented as a basic block without

[PATCH] Fix PR80416

The following hopefully fixes asm constraints (works for ia64 now, still works on x86_64). Richard. 2017-04-13 Richard Biener PR testsuite/80416 * g++.dg/torture/pr79671.C: Fix asm constraints. Index: gcc/testsuite/g++.dg/torture/pr79671.C

Re: [PATCH] Fix dwarf2out ICE with self-inlining (PR debug/80321)

On Fri, Apr 7, 2017 at 11:42 PM, Jakub Jelinek wrote: > Hi! > > The following C and Ada testcases show ICE due to endless recursion in > dwarf2out.c. The problem is that when processing BLOCK_NONLOCALIZED_VARS, > we want to treat all the FUNCTION_DECLs in there as mere

[PATCH][PR sanitizer/80414] Fix segfault with -fsanitize=undefined on 32 bit host

Hello everyone. I have patch to fix segfault with -fsanitize=undefined on 32 bit host. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80414 Can someone please review it. Thanks. commit 3bb53510ae11a9fa1f79ae83469c2650abe81ab4 Author: Denis Khalikov Date:

Re: [wwwdocs,fortran] Update link to CHKSYS

Hi Gerald, Jerry, as the author of this program (and the maintainer of that site) I am honoured that you refer to this. But I would like to tell you a bit about the history: I started CHKSYS in the time that FORTRAN 77 was still the main standard, so much of the tests that are contained in this

Re: [PATCH] Fix PR51513, switch statement with default case containing __builtin_unreachable leads to wild branch

On Wed, 12 Apr 2017, Peter Bergner wrote: > This patch is the second attempt to fix PR51513, namely the generation of > wild branches due to switch case statements that only contain calls to > __builtin_unreachable(). With the first attempt: > >

Re: [PATCH][libgcc, fuchsia]

On 12/04/17 19:02, Josh Conner via gcc-patches wrote: Ping^3? I think this should be very straightforward - it just adds fuchsia target support to libgcc. Please do let me know if there are any concerns... The arm parts look ok to me. You'll still need approval for the other parts though.

Do not accidentally localize symbols when there is a hidden symbol in the same comdat group

Hi, In the testcase for PR (which I do not know how to turn in to a testuiste version becuase it requires LTOed dynamic library) there is comdat group with one hiddena and one global symbol. At LTO we realize that hidden symbol can be brought static, but at that time we also accidentally localize

Re: [Patch, GCC/ARM, gcc-5-branch] Fix PR68390 Incorrect code due to indirect tail call of varargs function with hard float ABI

On Wed, Apr 12, 2017 at 6:55 PM, Christophe Lyon wrote: > Hi, > > It looks like we forgot to backport the fix for PR68390 to gcc-5-branch. > The patch applies cleanly, and fwiw we've had it in the linaro-5 > branch for a while. > > OK to apply to gcc-5-branch? > OK if

Re: [PATCH] Destroy arguments for _Cilk_spawn calling in the child (PR 80038)

On Wed, Apr 12, 2017 at 11:16 PM, Jeff Law wrote: > On 04/07/2017 08:02 AM, Xi Ruoyao wrote: >> >> On 2017-04-06 11:12 -0600, Jeff Law wrote: >> >>> With the likely deprecation in mind, I've only done a cursory review of >>> the changes -- mostly to verify that they hit Cilk+