Re: [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)

2017-01-20 Thread Jeff Law
On 01/18/2017 10:45 AM, Martin Sebor wrote: On 01/18/2017 01:10 AM, Jakub Jelinek wrote: On Tue, Jan 17, 2017 at 10:59:43PM -0700, Jeff Law wrote: I agree that breaking those applications would be bad. It could be dealt with by adding an option to let them disable the insertion of the trap. W

Re: [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)

2017-01-20 Thread Jeff Law
On 01/18/2017 01:10 AM, Jakub Jelinek wrote: On Tue, Jan 17, 2017 at 10:59:43PM -0700, Jeff Law wrote: I agree that breaking those applications would be bad. It could be dealt with by adding an option to let them disable the insertion of the trap. With the warning, programmers would get a head

[PATCH] Fix Fortran FE -Wformat-security warnings

2017-01-20 Thread Jakub Jelinek
Hi! The Fortran FE has huge amounts of -Wformat-security warnings everywhere, but in the end they are only a result of a few commonly used things: 1) gfc_get_string uses a printf-like format string, so calling it with a variable is something -Wformat-security warns about (and would be a bad bug if

Re: [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)

2017-01-20 Thread Jakub Jelinek
On Fri, Jan 20, 2017 at 04:32:19PM -0700, Jeff Law wrote: > > then the loop does the same thing as will memset (p, 6, 3U * 1024 * 1024 * > > 1024); > > do. On such large objects some operations may not work properly, e.g. > > &p[i] - &p[0] might be negative etc., but that is not something the abo

[PATCH] Some further --with-gcc-major-version-only fixes

2017-01-20 Thread Jakub Jelinek
Hi! I've discovered today that while I've handled all */Makefile* and toplevel, in the */*/Makefile* files there are some cat .../BASE-VER constructs left (for NVPTX offloading testing it actually caused the accel compiler not being found with --with-gcc-major-version-only). The following patch f

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

2017-01-20 Thread Jakub Jelinek
On Fri, Jan 20, 2017 at 01:37:13PM -0700, Jeff Law wrote: > > > Which is best will depend on what the front/mid ends might have done to > > > apply the documented limit. > > > > Here I know not enough to give a decision. In tree the priority_type is > > unsigned short. In varasm priority is an int

Re: [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)

2017-01-20 Thread Jeff Law
On 01/20/2017 04:34 PM, Jakub Jelinek wrote: On Fri, Jan 20, 2017 at 04:32:19PM -0700, Jeff Law wrote: then the loop does the same thing as will memset (p, 6, 3U * 1024 * 1024 * 1024); do. On such large objects some operations may not work properly, e.g. &p[i] - &p[0] might be negative etc., b

Re: [PATCH,rs6000] Correct argument and result types for binary floating point built-in functions

2017-01-20 Thread Segher Boessenkool
On Thu, Jan 19, 2017 at 04:07:47PM -0700, Kelvin Nilsen wrote: > > This patch corrects several errors in a patch originally committed on > 2016-08-10. The following corrections are required to maintain > compliance with "Power Architecture 64-Bit ELF V2 ABI Specification", > also known as "OpenPO

Re: [PATCH 1/6] RISC-V Port: gcc/config/riscv/riscv.c

2017-01-20 Thread Richard Henderson
On 01/11/2017 06:30 PM, Palmer Dabbelt wrote: +/* The largest number of operations needed to load an integer constant. + The worst case is LUI, ADDI, SLLI, ADDI, SLLI, ADDI, SLLI, ADDI, + but we may attempt and reject even worse sequences. */ +#define RISCV_MAX_INTEGER_OPS 32 Why would you

A + B CMP A -> A CMP' CST' match.pd patterns [was [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)]

2017-01-20 Thread Jeff Law
On 01/20/2017 04:30 PM, Jeff Law wrote: Going to work from the self-contained test... Here's a test case that's closer to the one from the bug. It also ends up with the out of bounds memset even at -O1, during PRE. typedef __SIZE_TYPE__ size_t; struct S int *p0, *p1, *p2; size_t size

Re: [PATCH 2/6] RISC-V Port: gcc

2017-01-20 Thread Richard Henderson
On 01/11/2017 06:30 PM, Palmer Dabbelt wrote: +(define_register_constraint "f" "TARGET_HARD_FLOAT ? FP_REGS : NO_REGS" + "A floating-point register (if available).") + I know this is the Traditional Way, but I do wonder if using the new enable attribute on the alternatives would be better. N

Re: [PATCH 2/6] RISC-V Port: gcc

2017-01-20 Thread Richard Henderson
On 01/17/2017 01:16 PM, Andrew Waterman wrote: We went with the /libXX/YY/ approach because, on a multilib system, the system libraries also need to be distinguished by ABI. It seemed most natural to us to handle ld.so and e.g. libc.so in a consistent manner. However, something along the lines

Re: [PATCH 3/6] RISC-V Port: libgcc

2017-01-20 Thread Richard Henderson
On 01/11/2017 06:30 PM, Palmer Dabbelt wrote: +__riscv_save_12: + addi sp, sp, -112 + li t1, 0 + sd s11, 8(sp) + j .Ls10 + +__riscv_save_11: +__riscv_save_10: + addi sp, sp, -112 + li t1, -16 No unwind info? r~

Re: [PR 79108] Put ipa_node_params to GC memory

2017-01-20 Thread Andrew Pinski
On Fri, Jan 20, 2017 at 1:58 PM, Martin Jambor wrote: > Hi, > > when I fixed PR 78365 by streaming types of parameters that might not > have been anywhere else, I forgot that I was holding them in non-GC > memory and so I caused PR 79108. The following patch fixes it by > putting ipa_param_descri

Re: Another cprop trap_if fix, PR79125

2017-01-20 Thread Jeff Law
On 01/20/2017 05:24 AM, Bernd Schmidt wrote: This is essentially the same patch I sent for the previous instance of this problem, but this time applied to local_cprop_pass. Bootstrapped and tested on x86_64-linux, and it seems to fix the testcase with a ppc cross. Ok? Bernd pr79125.diff

<    1   2