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

Hi, Just to update from my side, this patch fixes the issues I had reported in PR83789 and there are no new regression in my testing. Best Regards, Kaushik M. Phatak -Original Message- From: Segher Boessenkool [mailto:seg...@kernel.crashing.org] Sent: Tuesday, March 13, 2018 12:25 AM

Re: [PATCH] PR c/30552 gcc crashes when compiling examples with GNU statement expressions in VLAs

On 03/13/2018 03:56 PM, dave.pa...@oracle.com wrote: > This patch fixes ICE when statement expression used in old-style > function declaration parameter list. See > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30552 > > In c_parser_postfix_expression (), after seeing a left paren followed by >

Re: [PATCH, GCC/testsuite] Fix FAIL display for some scan-*-times directives

On Mar 13, 2018, at 10:12 AM, Thomas Preudhomme wrote: > > scan-assembler-times and scan-tree-dump-times dejagnu directives show a > different output in the summary files depending on whether they PASS or > FAIL. This means that dg-cmp-results would not show a

C++ PATCH for c++/82336, ICE with init-list default arg

As analyzed by Nathan and Paolo, the problem here is that the test conversion in check_default_arg is changing the expression, but then we discard the result. Excessive sharing of CONSTRUCTORs is an ongoing issue, due to past decisions motivated by memory savings. For the time being, we can

Re: [PATCH] Fortran -- clean up KILL

On Tue, Mar 13, 2018 at 09:49:10PM +0200, Janne Blomqvist wrote: > > int val = kill (pid, signal); > return (val == 0): 0 ? errno; > > like it already does for the optional status argument for kill_sub. > Committed as r258511 with your suggested change. -- Steve

[Committed] PR fortran/61775 -- testcase from PR

The issue raised in PR fortran/61775 seemed to be fixed. I've read the tree dump for -fdump-tree-optimized, and gfortran seems to be generating the expected code. Valgrind also finishes without errors. I committed to code as a testcase. 2018-03-13 Steven G. Kargl

Re: C++ PATCH to fix another ICE with stray template code (PR c++/84596)

OK. On Tue, Mar 13, 2018 at 6:18 PM, Marek Polacek wrote: > On Tue, Mar 13, 2018 at 01:33:45PM -0400, Jason Merrill wrote: >> On Tue, Mar 13, 2018 at 11:07 AM, Marek Polacek wrote: >> > Here's another case of a template code leaking into

Re: C++ PATCH to fix another ICE with stray template code (PR c++/84596)

On Tue, Mar 13, 2018 at 01:33:45PM -0400, Jason Merrill wrote: > On Tue, Mar 13, 2018 at 11:07 AM, Marek Polacek wrote: > > Here's another case of a template code leaking into cxx_constant_value. > > While I recently added the require_rvalue_constant_expression check, it > >

[PATCH] PR c/30552 gcc crashes when compiling examples with GNU statement expressions in VLAs

This patch fixes ICE when statement expression used in old-style function declaration parameter list. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30552 In c_parser_postfix_expression (), after seeing a left paren followed by a left curly brace, in addition to checking for existing

Patch to fix PR83712

  This is one more try to fix PR83712: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712   The patch was successfully bootstrapped and tested on x86-64, i686, and ppc64.   Committed as rev. 258504. Index: ChangeLog === ---

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

On 03/13/18 00:56, Andrew Sadek wrote: Ok, so you mean with '-fPIC -mpic-data-text-relative' as I do in my test case ? If all is Ok, execution and compilation shall ideally pass for the test cases. Correct. I want to make sure of two things: -- Your patch doesn't break anything (i.e.,

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

On Tue, Mar 13, 2018 at 04:19:21PM +0100, Martin Liška wrote: > > Yes, see e.g. TARGET_LIBC_HAS_FUNCTION target hook, > > where in particular linux_libc_has_function deals with various C libraries. > > Of course, in this case you need another target hook, that is dependent both > > on the target

[PATCH] Fix -march=bdver1 ICE on int to float conversion (PR target/84844)

Hi! As mentioned in bugzilla, when e.g. sel-sched queries (indirectly) before reload some attributes like get_attr_type that depend on alternatives, GCC attempts to constrain the operands in non-strict mode, which implies that if reg_class_for_constraint doesn't return NO_REGS, it is ok,

[C++ PATCH] Fix ICE with builtin redefinition (PR c++/84843)

Hi! If we return olddecl on an (invalid) builtin function redefinition rather than redeclaration, we ICE shortly afterwards, because we assume we have non-NULL DECL_INITIAL on whatever is returned (except for error_mark_node). The following patch errors unconditionally for definitions of builtin

Re: [C++ PATCH] Fix ICE with builtin redefinition (PR c++/84843)

OK. On Tue, Mar 13, 2018 at 4:17 PM, Jakub Jelinek wrote: > Hi! > > If we return olddecl on an (invalid) builtin function redefinition rather > than redeclaration, we ICE shortly afterwards, because we assume we have > non-NULL DECL_INITIAL on whatever is returned (except for

[PATCH] Fix ptr-overflow sanopt optimization (PR sanitizer/83392)

Hi! The sanopt maybe_optimize_ubsan_ptr_ifn optimization behaves differently on 32-bit and on 64-bit targets when using similar arguments maximum or minimum of ptrdiff_t or values close to it. The problem is that UHWI is 64-bit, regardless of whether addresses are 64-bit or 32-bit, so for 32-bit

C++ PATCH for c++/82565, ICE with concepts and generic lambda

Here, trying to evaluate the constraints of the test::visit template led us to instantiating the generic lambda function; this ends up with us trying to instantiate it with processing_template_decl still set. A simple way to fix this case in GCC 8 is to not treat the lambda as a nested function,

Re: [PATCH] Fortran -- clean up KILL

On Tue, Mar 13, 2018 at 6:08 AM, Steve Kargl wrote: > 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

C++ PATCH for c++/84839, ICE with decltype of parameter pack

The comment says that the parameter pack is being used in an unevaluated context, but at the point where we're substituting the pack, we aren't necessarily actually in that unevaluated context, so let's set the flag here. Tested x86_64-pc-linux-gnu, applying to trunk. commit

C++ PATCH for c++/84720, ICE with rvalue ref template parameter

In this testcase, we were crashing because we decided that the int&& template parameter wasn't a valid argument for itself, which is wrong. It's unclear to me that it is ever possible to instantiate a template taking an rvalue ref parameter, but I guess we might as well handle it properly. Tested

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

Avoid issuing a bogus warning when the source of strncpy is bound by a constant known to be less than the minimum size of the destination. Changes from v1: - Use range-info instead of the MIN_EXPR hack - Get the minimum size of dst and check for NULL_TREE return The patch bootstraps

Re: [PATCH] PR c/46921 Lost side effect when struct initializer expression uses comma operator

Thanks, committed. -- Joseph S. Myers jos...@codesourcery.com

Re: C++ PATCH to fix another ICE with stray template code (PR c++/84596)

On Tue, Mar 13, 2018 at 11:07 AM, Marek Polacek wrote: > Here's another case of a template code leaking into cxx_constant_value. > While I recently added the require_rvalue_constant_expression check, it > doesn't help here, because the problem is that we have a MODOP_EXPR (a >

[PATCH, GCC/testsuite] Fix FAIL display for some scan-*-times directives

Hi, scan-assembler-times and scan-tree-dump-times dejagnu directives show a different output in the summary files depending on whether they PASS or FAIL. This means that dg-cmp-results would not show a regression because it would not see a connection between the two output. The difference comes

Re: [PATCH] PR libstdc++/70664 Set failbit and read zero on stream reading negative value into unsigned type

On 13 March 2018 at 15:55, Jean-Baptiste Daval wrote: > Hi, > > Currently when a value is extracted from a stream into a unsigned type, > there is no test to check if the value is negative, in which case there > is an overflow and failbit is not set (the correct behavior would be to > read a zero

Re: PR libstdc++/78420 Make std::less etc. yield total order for pointers

On 9 March 2018 at 00:41, Jonathan Wakely wrote: > In order to meet the total order requirements of [comparisons] p2 we > need to cast unrelated pointers to uintptr_t before comparing them. > Those casts aren't allowed in constant expressions, so only cast > when __builtin_constant_p says the

Re: PR target/84743 adjust reassociation widths for power8/power9

On Mon, Mar 12, 2018 at 08:02:39PM -0500, Aaron Sawdey wrote: > 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

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

On Mon, 2018-03-12 at 14:44 +0100, Svante Signell wrote: > 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 > >

[PATCH] PR libstdc++/70664 Set failbit and read zero on stream reading negative value into unsigned type

Hi, Currently when a value is extracted from a stream into a unsigned type, there is no test to check if the value is negative, in which case there is an overflow and failbit is not set (the correct behavior would be to read a zero and set failbit). This patch add a condition to check when we are

C++ PATCH for c++/84798, ICE with auto in abstract function declarator

It doesn't make sense to use an 'auto' parameter type outside of an implicit template declaration; conveniently, default_arg_ok_p already tracks whether we are in a suitable context. As Jakub points out in the PR, this extension really shouldn't be silently accepted, given that it still isn't

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

Hi, On Tue, 13 Mar 2018, Andreas Krebbel wrote: > Leaving history aside don't you agree that it would have been more > sensible to require a -m option only if you want to build for an ABI > different from what is currently mandated by the personality setting? I agree with you. But we can't

[PATCH, rs6000] Remove unused (and incorrect) code for internal store and load operations

While working to assure rs6000 documentation of built-in functions is consistent with the implementation of built-in functions, I discovered some apparent typographic errors in the definitions of the ST_INTERNAL_4sf and ST_INTERNAL_2df built-in functions. As I endeavored to fix these definitions

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

On 03/12/2018 05:13 PM, Jeff Law wrote: 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

Re: Richard Sandiford appointed SVE maintainer in AArch64 port.

Ramana Radhakrishnan writes: > I am pleased to announced that the GCC Steering Committee has > appointed Richard Sandiford as SVE maintainer in the AArch64 port. > > Please join me in congratulating Richard on his additional role. > > Richard, please update your listing

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

On 03/13/2018 09:32 AM, Jakub Jelinek wrote: On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote: On 03/12/2018 10:39 AM, Marc Glisse wrote: 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

C++ PATCH to fix another ICE with stray template code (PR c++/84596)

Here's another case of a template code leaking into cxx_constant_value. While I recently added the require_rvalue_constant_expression check, it doesn't help here, because the problem is that we have a MODOP_EXPR (a template code), whose op1 is a TRUNC_DIV_EXPR without a type, so it's considered

[PATCH] Fix PR84830

This should fix the endless PRE antic iterations for good. OK, it's somewhat of a hack but unless I fix another two or three parts of the antic algorithm to not prune values that may later re-appear I see no other way to guarantee this. And this isn't the time to fiddle with PRE further...

[Patch AArch64] Turn on -fasynchronous-unwind-tables and -funwind-tables by default.

Jakub commented here that https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01325.html we don't turn on fasynchronous-unwind-tables for AArch64. I note that x86_64 turns on funwind-tables as well. Thus this patch turns on both. Note that this doesn't increase code size but will likely increase binary

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

On Tue, Mar 13, 2018 at 04:59:58AM -0700, H.J. Lu wrote: > >> The testcase still ICEs on i686-linux (preexisting bug, ICEs the same > >> without this patch or even before the previous patch), will handle that > >> tomorrow. > I got: See the above? Or do you get this with -m64 too, rather than

[PATCH] Redirect reference in the symbol table (PR ipa/84833).

Hi. This fixed issue where we have an ifunc function called from another ifunc function. One needs to properly make a reference redirection. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. MVC tests on x86_64 also work fine. Ready for trunk? Thanks, Martin

Re: GCC 6 backports

On 03/10/2018 07:28 PM, H.J. Lu wrote: On Wed, Mar 7, 2018 at 1:41 AM, Martin Liška wrote: Hi. Sending GCC 6 branch backports. Patches can bootstrap on ppc64le-redhat-linux and survives regression tests. I'm going to install the patches. Martin I am going to backport:

[PATCH] Handle -fno-guess-branch-probability properly in predict.c (PR ipa/84825).

Hi. This is a fix for situation where we use -fno-guess-branch-probability and fnsplit happens. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ready for trunk? Thanks, Martin gcc/ChangeLog: 2018-03-13 Martin Liska PR ipa/84825

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

On Tue, Mar 13, 2018 at 5:02 AM, Jakub Jelinek wrote: > On Tue, Mar 13, 2018 at 04:59:58AM -0700, H.J. Lu wrote: >> >> The testcase still ICEs on i686-linux (preexisting bug, ICEs the same >> >> without this patch or even before the previous patch), will handle that >> >>

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

On Tue, Mar 13, 2018 at 12:55 AM, Uros Bizjak wrote: > On Mon, Mar 12, 2018 at 10:10 PM, Jakub Jelinek wrote: >> Hi! >> >> As Martin reported, the same testcase added recently ICEs differently >> with different options on x86_64-linux, the problem is that we

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

On Tue, Mar 13, 2018 at 9:32 AM, Jakub Jelinek wrote: > On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote: >> On 03/12/2018 10:39 AM, Marc Glisse wrote: >> > On Mon, 12 Mar 2018, Martin Liška wrote: >> > >> > > This is fix for the PR that introduces a new target

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

On 03/12/2018 06:50 PM, Jakub Jelinek wrote: > 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

Re: [patch] Fix PR lto/84805

On Tue, Mar 13, 2018 at 12:06 AM, Eric Botcazou wrote: > 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

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

On Monday 12 March 2018 03:26 PM, Richard Biener wrote: > Please use tree_int_cst_lt (rhs1, dstsize) instead. > >> + { >> + gimple_set_no_warning (stmt, true); > > Why this? There's only a single bit -- where do we warn from if you > don't do this here? I incorrectly

[PATCH] Fix __builtin_round{,f,l} ICE on x86 (PR target/84827)

Hi! Since r237074 the 387 rounding insns are guarded with (flag_fp_int_builtin_inexact || !flag_trapping_math), and the round2 expander is enabled for 387 fancy math whenever flag_unsafe_math_optimizations; as the testcase shows, the latter doesn't imply the former, so this patch adds another

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

On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote: > On 03/12/2018 10:39 AM, Marc Glisse wrote: > > 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

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

On 03/12/2018 10:39 AM, Marc Glisse wrote: 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

[PATCH] Properly redirect alias for MVC (PR ipa/84722).

Hi. When having a weak alias that points to a multi-versioning function, one needs to redirect the alias properly. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ready for trunk? Thanks, Martin gcc/ChangeLog: 2018-03-12 Martin Liska PR

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

On 03/12/2018 11:06 AM, Richard Biener wrote: 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

Re: PR target/84743 adjust reassociation widths for power8/power9

On Mon, 12 Mar 2018, Aaron Sawdey wrote: > 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

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

On Mon, 12 Mar 2018, Jakub Jelinek wrote: > 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

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

On Mon, 12 Mar 2018, Jakub Jelinek wrote: > 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

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

Ok, so you mean with '-fPIC -mpic-data-text-relative' as I do in my test case ? If all is Ok, execution and compilation shall ideally pass for the test cases. But I have noticed that there are some output pattern checks done in some test cases and this may fail since the output assembly is

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

On Mon, Mar 12, 2018 at 10:10 PM, Jakub Jelinek wrote: > 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 >

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

On Mon, Mar 12, 2018 at 9:52 PM, Jakub Jelinek wrote: > 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

Re: [PATCH] Fix __builtin_round{,f,l} ICE on x86 (PR target/84827)

On Mon, Mar 12, 2018 at 10:14 PM, Jakub Jelinek wrote: > Hi! > > Since r237074 the 387 rounding insns are guarded with > (flag_fp_int_builtin_inexact || !flag_trapping_math), and the > round2 expander is enabled for 387 fancy math whenever > flag_unsafe_math_optimizations; as

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

Fixed invoke.texi. Here is the new version. gcc/ * config.gcc (icelake-client, icelake-server): New. (icelake): Remove. * config/i386/i386.c (initial_ix86_tune_features): Extend to 64 bit. (initial_ix86_arch_features): Ditto.

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

On 03/12/18 23:10, Andrew Sadek wrote: _Command for running testsuite:_ /make -k check-gcc RUNTESTFLAGS="-v --target_board=microblaze-qemu CFLAGS_FOR_TARGET='-include /home/andrew/qemu/common.h -L/home/andrew/qemu/lib -Wl,--start-group,-lxil,-lgcc,-lc,--end-group -mlittle-endian' "/ _Quick

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

*Command for running testsuite:* *make -k check-gcc RUNTESTFLAGS="-v --target_board=microblaze-qemu CFLAGS_FOR_TARGET='-include /home/andrew/qemu/common.h -L/home/andrew/qemu/lib -Wl,--start-group,-lxil,-lgcc,-lc,--end-group -mlittle-endian' "* *Quick Details:* 1) common.h: Here I define