Re: [PATCH] Fortran -- clean up KILL

On Mon, Mar 12, 2018 at 09:05:09PM +0200, Janne Blomqvist wrote: > > Yes, I understand that -fdefault-integer-8 (or whatever the equivalent > option was called on g77) is the original motivation. Like I said, I > don't have any particular opinion on whether we should keep that > restriction or

[PATCH][PR target/84838] Minor grammar fixes for x86 options

This is a patch to correct some minor grammatical errors in the x86 options documentation. "Nor" isn't correct usage in these sentences, and there was a missing definite article (in keeping with the style used elsewhere for that same option). Regards, Dave 2018-03-12 David H. Gutteridge

Re: [PATCH] use attribute exclusion to reject naked vs target_clones conflicts (PR 84723)

Since Jakub has committed an alternate patch that fixes the ICE (below) this change is no longer necessary for GCC 8. It still is in my view the right way to address the main part of the problem so I will resubmit it for GCC 9 in stage 1. https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00285.html

PR target/84743 adjust reassociation widths for power8/power9

Looking at CPU2017 results for different reassociation widths, things have shifted since I last looked at this with CPU2006 in early gcc7 timeframe. Best thing to do seems to be to set reassociation width to 1 for all integer modes, which is what the attached patch does. I also tried setting

Re: Patch ping

OK. On Mon, Mar 12, 2018 at 10:22 AM, Jakub Jelinek wrote: > Hi! > > I'd like to ping the > > http://gcc.gnu.org/ml/gcc-patches/2018-03/msg00238.html > - PR84704 - ICE on a[({ 0; })] op= something with -g > > patch. Thanks. > > Jakub

Re: [C++ PATCH] Fix constexpr.c find_array_ctor_elt (PR c++/84808)

OK. On Mon, Mar 12, 2018 at 4:58 PM, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs, because in code to break up a RANGE_EXPR > we have a reference to a constructor element: > constructor_elt = (*elts)[middle]; > and do conditionally: >

Re: [PATCH] accept attribute nonstring on all narrow characters (PR 84725)

On 03/05/2018 01:54 PM, Martin Sebor wrote: > Attribute nonstring is currently only allowed on arrays and > pointers to plain char, but -Wstringop-truncation triggers > even for strncpy calls whose arguments are arrays of signed > or unsigned char (with or without a cast to char*). > > To help 

[patch] Fix PR lto/84805

Hi, this is an ICE in LTO mode on code violating the ODR rule: get_odr_type checks that there is a sensible internal order between base, type and derived types but this can be easily messed up by incomplete types. Hence the attached fixlet (no testcase because the -Wodr warnings have a

[PATCH] PR libstdc++/84773 use aligned alloc functions for FreeBSD and MinGW cross-compilers

Cross-compilers for FreeBSD and MinGW do not currently check for aligned_alloc, posix_memalign, _aligned_malloc etc which are used by native compilers when available. This omission caused bootstrap failures for FreeBSD cross-compilers, and caused ABI differences for MinGW due to a different

[Ada] Fix PR ada/82813

-Wstringop-overflow is supposed to be a C-family warning but it is somehow issued in Ada too and can warn on bogus cases so let's just kill it. Tested on x86-64/Linux, applied on the mainline and 7 branch. 2018-03-12 Eric Botcazou PR ada/82813 *

Re: [PATCH] Fix spelling of -mclflushopt in manual

On 12 March 2018 at 22:31, Jonathan Wakely wrote: > Committed as obvious. To trunk and the active branches.

[PATCH] Fix spelling of -mclflushopt in manual

Committed as obvious. commit f242fcfe46b7bb82fcfe6cc536031d6d7af56c63 Author: Jonathan Wakely Date: Mon Mar 12 22:28:47 2018 + Fix spelling of -mclflushopt in manual * doc/invoke.texi (-mclflushopt): Fix spelling of option. diff --git

[PATCH] Fix another CONSTRAINT_LEN related bug (PR middle-end/84831)

Hi! I thought the vregs pass is the first one to analyze constraints, but I was wrong, already before that parse_{output,input}_constraint are called, already during GIMPLE passes. They don't really fail miserably if , appears in the middle of multi-letter constraint (unlike e.g. the RA), which

[C++ PATCH] Fix constexpr.c find_array_ctor_elt (PR c++/84808)

Hi! The following testcase ICEs, because in code to break up a RANGE_EXPR we have a reference to a constructor element: constructor_elt = (*elts)[middle]; and do conditionally: vec_safe_insert (CONSTRUCTOR_ELTS (ary), middle, e); and later: e.value =

[PATCH] Fix -march=knl wrong-code (PR target/84786)

Hi! For TARGET_AVX512F && !TARGET_AVX512VL, the RA ensures that 128-bit and 256-bit vectors aren't allocated in %xmm16+ registers, but not so for scalar modes. In that case we use avx512vl isa attribute, or TARGET_AVX512VL guards, or Yv constraint. The following patch does the last one for

Re: [PATCH] S/390: Set ABI default based on uname

On Mon, Mar 12, 2018 at 06:42:15PM +0100, Andreas Krebbel wrote: > On 03/12/2018 06:31 PM, Jakub Jelinek wrote: > > On Mon, Mar 12, 2018 at 06:28:09PM +0100, Andreas Krebbel wrote: > >> Currently the default ABI option for a GCC built on a 64 bit system is > >> always -m64. This is inconvenient

Re: [patch][x86] Split-up march icelake on march=icelake-server and march=icelake-client

On Mon, 12 Mar 2018, Koval, Julia wrote: > Hi, > This patch introduces separate client and server arch options instead of > -march=icelake. Ok for trunk? I don't see any invoke.texi updates here to document what these two options mean (including, presumably, different lists of features for

[PATCH] Fix match.pd ICEs on COMPLEX_CSTs (PR middle-end/84834)

Hi! The following two match.pd spots assume that integer_pow2p will return true only for INTEGER_CSTs (it uses wi::to_wide on it), but as the testcase shows, that is not always the case, we can get there with COMPLEX_CSTs. Fixed by requiring that it is both INTEGER_CST and integer_pow2p,

[og7] Backport PR74048 and PR81352 nvptx fixes

I've applied this patch to openacc-gcc-7-branch which backports Tom's nvptx bug fixes for PR74048 and PR81352. For some reason, I thought the test case for pr84028 was triggering a new PTX JIT bug. But it turned out to be failing because og7 is more verbose than trunk when it detects unused

[PATCH] Fix another reg-stack recovery bug (PR target/84828)

Hi! As Martin reported, the same testcase added recently ICEs differently with different options on x86_64-linux, the problem is that we sometimes emit insns before a CODE_LABEL of the next bb rather than after the last insn in the previous bb, and expect we can just fix up BB_END of the previous

[patch][x86] Split-up march icelake on march=icelake-server and march=icelake-client

Hi, This patch introduces separate client and server arch options instead of -march=icelake. Ok for trunk? Thanks, Julia gcc/ * config.gcc (icelake-client, icelake-server): New. (icelake): Remove. * config/i386/i386.c (initial_ix86_tune_features): Extend to 64 bit.

Re: [PATCH] Fortran -- clean up KILL

On Mon, Mar 12, 2018 at 7:37 PM, Steve Kargl wrote: > On Mon, Mar 12, 2018 at 06:56:24PM +0200, Janne Blomqvist wrote: >> On Sun, Mar 11, 2018 at 10:42 PM, Steve Kargl >> > I suppose we could remove the restriction to INTEGER(4) and >> > INTEGER(8), but I don't

[PATCHv2] PR libstdc++/84654 Do not use __float128 if it is disabled by the compiler

Changes since v1: - Completely rewrite of the patch to set ENABLE_FLOAT128 at libstdc++ build time and undef _GLIBCXX_USE_FLOAT128 when building user code. --- 8< --- In order to use __float128 in C++ it's necessary to check if the compiler enabled its support too when building user code.

Re: [PATCH, rs6000] Fix PR83789: __builtin_altivec_lvx fails for powerpc for altivec-4.c

Hi! On Sun, Mar 11, 2018 at 10:23:02AM -0500, Peter Bergner wrote: > PR83789 shows a problem in the builtin expansion code not calling the correct > define_insn, given the correct mode (32-bit versus 64-bit). One could add > tests in this code to call the correct pattern, but it's easier to

Re: [PATCH,rs6000] Add vec_permxor support.

Hi Carl, On Mon, Mar 12, 2018 at 08:21:08AM -0700, Carl Love wrote: > The following patch add support for the vec_permxor builtins.   > > Note the change in file rs6000-p8swap.c is actually a fix for the > existing define_insn "crypto_vpermxor in crypto.md. The fix disables > swap optimization

Re: [PATCH] S/390: Set ABI default based on uname

On 03/12/2018 06:31 PM, Jakub Jelinek wrote: > On Mon, Mar 12, 2018 at 06:28:09PM +0100, Andreas Krebbel wrote: >> Currently the default ABI option for a GCC built on a 64 bit system is >> always -m64. This is inconvenient when e.g. building 32 bit libraries >> on a 64 bit system. The usual way

Re: [PATCH] Fortran -- clean up KILL

On Mon, Mar 12, 2018 at 06:56:24PM +0200, Janne Blomqvist wrote: > On Sun, Mar 11, 2018 at 10:42 PM, Steve Kargl > > I suppose we could remove the restriction to INTEGER(4) and > > INTEGER(8), but I don't see any reason to do so. INTEGER(1) > > is too limited given that at least on FreeBSD the

Re: [PATCH] S/390: Set ABI default based on uname

On Mon, Mar 12, 2018 at 06:28:09PM +0100, Andreas Krebbel wrote: > Currently the default ABI option for a GCC built on a 64 bit system is > always -m64. This is inconvenient when e.g. building 32 bit libraries > on a 64 bit system. The usual way to do this is to set the personality > to s390 (32

Patch ping

Hi! I'd like to ping the http://gcc.gnu.org/ml/gcc-patches/2018-03/msg00238.html - PR84704 - ICE on a[({ 0; })] op= something with -g patch. Thanks. Jakub

[PATCH] S/390: Set ABI default based on uname

Currently the default ABI option for a GCC built on a 64 bit system is always -m64. This is inconvenient when e.g. building 32 bit libraries on a 64 bit system. The usual way to do this is to set the personality to s390 (32 bit) and let the configure script do the right thing. Having a GCC which

[PATCH] rs6000: sysv: Don't pass SFmode in varargs in FPRs

This makes the float32-basic.c testcase work on sysv (32-bit Linux). "float" is promoted to "double" for varargs. The ABI also only defines the use of double precision in varargs. But _Float32 is not promoted. Since there is no way of passing single-precision float in FPRs we should pass SFmode

Re: [PATCH] Fortran -- clean up KILL

On Sun, Mar 11, 2018 at 10:42 PM, Steve Kargl wrote: > On Sun, Mar 11, 2018 at 10:16:01PM +0200, Janne Blomqvist wrote: >> On Sun, Mar 11, 2018 at 6:52 PM, Steve Kargl >> wrote: >> > The attach patch cleans up KILL to match

[PATCH] combine: Fix PR84780 (more LOG_LINKS trouble)

There still are situations where we have stale LOG_LINKS. This causes combine to try two-insn combinations I2->I3 where the register set by I2 is used before I3 as well. Not good. This patch fixes it by checking for this situation in can_combine_p (similar to what we already do for three and

[PATCH,rs6000] Add vec_permxor support.

GCC maintainers: The following patch add support for the vec_permxor builtins.   Note the change in file rs6000-p8swap.c is actually a fix for the existing define_insn "crypto_vpermxor in crypto.md. The fix disables swap optimization for the vpermxor instruction. Without this fix optimization

Re: [PATCH] replace ICE with error for failed template deduction (PR 84355)

On Mon, Mar 5, 2018 at 7:05 PM, Martin Sebor wrote: > On 02/23/2018 07:32 PM, Jason Merrill wrote: >> On Sun, Feb 18, 2018 at 11:39 PM, Jason Merrill wrote: >>> On Fri, Feb 16, 2018 at 4:33 PM, Martin Sebor wrote: On 02/16/2018 07:04

Re: [PATCH] [Microblaze]: PIC Data Text Relative

On 03/12/18 06:19, Andrew Sadek wrote: On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager > wrote: On 03/02/2018 08:12 AM, Andrew Sadek wrote: Hello Michael, I tried running the whole GCC test suite on the current head

Re: [PATCH][AArch64] Remove aarch64_frame_pointer_required

Wilco Dijkstra writes: > Richard Sandiford wrote: >> But there's the third question of whether the frame pointer is available >> for general allocation.  By removing frame_pointer_required, we're saying >> that the frame pointer is always available for general use.  > >

Re: [Patch] test_summary: handle single quotes

ping? On 28 February 2018 at 10:30, Christophe Lyon wrote: > Hi, > > We happen to build GCC with '~' in the src and build dirs, leading to > single quotes around the configure path in config.status. For example: > [...] >

Re: PATCH: Hurd port of go to gcc-8 (gcc-8-8-20180310+) 16 patches

On Mon, 2018-03-12 at 13:29 +0100, Svante Signell wrote: > The patches really changed are only four: > src_libgo_runtime.diff > src_libgo_go_go_build_syslist.go.diff > src_libgo_go_runtime.diff > src_libgo_build.diff Correction: five: add-gnu-to-libgo-headers.diff

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On Mon, Mar 12, 2018 at 09:57:09AM +0100, Martin Liška wrote: > Hi. > > This is fix for the PR that introduces a new target macro. Using the macro > one can say that a target has a fast mempcpy and thus it's preferred to be > used > if possible. > > Patch can bootstrap on ppc64le-redhat-linux

[PATCH] Add a testcase for PR 84821

This was introduced by r258390 and fixed by r258415. I am checking in this to add a testcase for PR 84821. H.J. 00 * g++.dg/pr84821.C: New test. --- gcc/testsuite/ChangeLog| 4 +++ gcc/testsuite/g++.dg/pr84821.C | 55 ++ 2 files changed,

[PATCH] Add a testcase for PR 84799

This is introduced by r258390 and fixed by r258415. I am checking in this patch to add a testcase for PR 84799. H.J. --- * gcc.dg/pr84799.c: New test. --- gcc/testsuite/ChangeLog| 4 gcc/testsuite/gcc.dg/pr84799.c | 29 + 2 files changed, 33

Re: [PATCH] [Microblaze]: PIC Data Text Relative

On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager wrote: > On 03/02/2018 08:12 AM, Andrew Sadek wrote: > >> Hello Michael, >> >> I tried running the whole GCC test suite on the current head (without my >> patch) along with 'microblaze-qemu' but I have the following problems: >> >>

C++ PATCH for c++/84802, ICE capturing uninstantiated class

If A isn't instantiated by the time we build the capture proxy VAR_DECL, it gets no DECL_SIZE. So make sure it is. Tested x86_64-pc-linux-gnu, applying to trunk. commit e979dc834d91e52c0c568f85c2b62ec67dac3cdc Author: Jason Merrill Date: Mon Mar 12 01:01:14 2018 -0400

[PATCH] Fix PR84803

The following fixes PR84803 where we have a memory reference data-reference analysis thought it's not worth handling. This properly guards the access. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2018-03-12 Richard Biener PR

Re: [parloops, PR83126], Use cached affine_ivs canonicalize_loop_ivs

On Thu, 22 Feb 2018, Tom de Vries wrote: > Hi, > > this patch fixes an ICE in the parloops pass. > > The ICE (when compiling the test-case in attached patch) follows from the fact > that here in gen_parallel_loop the call to canonicalize_loop_ivs fails to > "base all the induction variables in

Re: [PATCH] Diagnose earlier invalid inline asm constraints (PR inline-asm/84742)

On Mon, Mar 12, 2018 at 4:18 AM, H.J. Lu wrote: > On Thu, Mar 8, 2018 at 10:19 AM, Jakub Jelinek wrote: >> Hi! >> >> We have many loops that use CONSTRAINT_LEN to skip over various constraint >> characters, but we assume the constraints have valid length

Re: [PATCH] Diagnose earlier invalid inline asm constraints (PR inline-asm/84742)

On Thu, Mar 8, 2018 at 10:19 AM, Jakub Jelinek wrote: > Hi! > > We have many loops that use CONSTRAINT_LEN to skip over various constraint > characters, but we assume the constraints have valid length and don't walk > the individual characters to double check this. > > If that

RE: [PATCH][GCC][ARM] Fix can_change_mode_class for big-endian

Ping > -Original Message- > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- > ow...@gcc.gnu.org] On Behalf Of Tamar Christina > Sent: Monday, March 5, 2018 16:52 > To: gcc-patches@gcc.gnu.org > Cc: nd ; Ramana Radhakrishnan > ; Richard

Re: [PR84682] disregard address constraints on non-addresses

On Fri, Mar 9, 2018 at 6:45 AM, Alexandre Oliva wrote: > LRA gets very confused when non-addresses are passed as operands to > asms with address contraints. Even if other constraints are > available, and the operand is a perfect fit for them, we'd still > attempt to process

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On Mon, Mar 12, 2018 at 9:57 AM, Martin Liška wrote: > Hi. > > This is fix for the PR that introduces a new target macro. Using the macro Don't add new target macros, use target hooks. > one can say that a target has a fast mempcpy and thus it's preferred to be > used > if

Re: [PATCH] Fix PTA info in IPA ICF (PR ipa/84658).

On Mon, Mar 12, 2018 at 9:42 AM, Martin Liška wrote: > Hi. > > This is what I was recommended in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658#c18. > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Ready to be installed? Please do not remove

Re: [PATCH] Fix bogus strncpy source length warning on source bound by constant

On Sun, Mar 11, 2018 at 4:22 PM, Siddhesh Poyarekar wrote: > Avoid issuing a bogus warning when the source of strncpy is bound by a > constant and is known to be less than the size of the destination. > > Testsuite run is underway (not complete yet, but no new errors so

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

On Mon, 12 Mar 2018, Martin Liška wrote: This is fix for the PR that introduces a new target macro. Using the macro one can say that a target has a fast mempcpy and thus it's preferred to be used if possible. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. I also

[committed] Add testcase for already fixed PR c++/84813

Hi! This PR got fixed in r251433 which I'm afraid is not backportable, we were trying to register local specialization during dwarf2out_type_decl. I've committed the testcase as obvious to trunk, so that we don't regress on it again: 2018-03-12 Jakub Jelinek PR

[PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

Hi. This is fix for the PR that introduces a new target macro. Using the macro one can say that a target has a fast mempcpy and thus it's preferred to be used if possible. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. I also tested on x86_64-linux-gnu. Ready to be

[PATCH] Fix PTA info in IPA ICF (PR ipa/84658).

Hi. This is what I was recommended in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658#c18. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ready to be installed? Martin gcc/ChangeLog: 2018-03-12 Martin Liska PR ipa/84658. *