Re: [PR c++/84789] do not resolve typename into template-independent

On Mar 20, 2018, Jason Merrill wrote: > On Tue, Mar 20, 2018 at 6:07 PM, Alexandre Oliva wrote: >> On Mar 20, 2018, Jason Merrill wrote: >>> that doesn't mean it's wrong to peek. >> Huh? We're referencing members of an unrelated template

Re: [PR c++/71251] out-of-range parms in tmpl arg substitution

On Mar 20, 2018, Jason Merrill wrote: >> + if (id == error_mark_node) >> +return error_mark_node; > Why wait until here to return? There are error returns immediately > above and below your first hunk. QOI. Returning immediately, we then get other errors. We could

Re: [PATCH 2/2] C++: show private field accessor hints with -g and optimization (PR c++/84994)

On Tue, Mar 20, 2018 at 7:37 PM, David Malcolm wrote: > PR c++/84894 reports that the fix-it hints suggesting accessor calls for > private fields doesn't work with -g for -O1 and above. > > The issue is that field_accessor_p requires DECL_SAVED_TREE (fn) to be > a

Re: [PATCH 1/2] C++: show private field accessor hints for const accesses (PR c++/84892)

On Tue, Mar 20, 2018 at 7:37 PM, David Malcolm wrote: > PR c++/84892 reports that we fail to offer fix-it hints about accessor > member functions when complaining about accesses to private fields > through const pointers and references. > > It turns out that field_accessor_p

Re: [PR c++/71251] out-of-range parms in tmpl arg substitution

On Tue, Mar 20, 2018 at 6:51 PM, Alexandre Oliva wrote: > On Mar 20, 2018, Jason Merrill wrote: > >> On Tue, Mar 20, 2018 at 4:15 PM, Alexandre Oliva wrote: >>> Should we aim at rejecting the declaration of U? > >> Yes. > > Like this? > >

Re: [PR c++/84789] do not resolve typename into template-independent

On Tue, Mar 20, 2018 at 6:07 PM, Alexandre Oliva wrote: > On Mar 20, 2018, Jason Merrill wrote: > >> On Fri, Mar 16, 2018 at 5:38 PM, Alexandre Oliva wrote: >>> resolve_typename_type may peek into template types that might still be >>>

[Committed] PR fortran/85001 -- Fix a non non-null pointer issue

The following patch fixes an assign of a valid pointer to to pointer, but what should have been assigned is NULL; 2018-03-20 Steven G. Kargl PR fortran/85001 * interface.c (symbol_rank): Remove bogus null pointer check that crept in when translating

Re: Seeking Release Manager approval for: [PATCH] jit: fix link on OS X and Solaris (PR jit/64089 and PR jit/84288)

On Wed, 2018-03-21 at 00:39 +0100, Rainer Orth wrote: > Hi Malcolm, > > > > I've now tested the patch (together with the one from PR > > > jit/84288 > > > for > > > several remaining issues). I've needed another snippet for > > > Solaris/SPARC which links libkstat into xgcc and needs it in > > >

Re: Seeking Release Manager approval for: [PATCH] jit: fix link on OS X and Solaris (PR jit/64089 and PR jit/84288)

Hi Malcolm, >> I've now tested the patch (together with the one from PR jit/84288 >> for >> several remaining issues). I've needed another snippet for >> Solaris/SPARC which links libkstat into xgcc and needs it in >> libgccjit.so, too. Bootstrapped without regressions on >> i386-pc-solaris2.11

[PATCH 2/2] C++: show private field accessor hints with -g and optimization (PR c++/84994)

PR c++/84894 reports that the fix-it hints suggesting accessor calls for private fields doesn't work with -g for -O1 and above. The issue is that field_accessor_p requires DECL_SAVED_TREE (fn) to be a RETURN_EXPR, but the former is a STATEMENT_LIST, created in start_preparsed_function here:

[PATCH 1/2] C++: show private field accessor hints for const accesses (PR c++/84892)

PR c++/84892 reports that we fail to offer fix-it hints about accessor member functions when complaining about accesses to private fields through const pointers and references. It turns out that field_accessor_p was incorrectly checking for "this" being a "const *T", rather than being a "const

Re: [PR c++/71251] out-of-range parms in tmpl arg substitution

On Mar 20, 2018, Jason Merrill wrote: > On Tue, Mar 20, 2018 at 4:15 PM, Alexandre Oliva wrote: >> Should we aim at rejecting the declaration of U? > Yes. Like this? [PR c++/71251] check tmpl parms in template using decl Check that template using decls

Re: [PATCH] Fix VEC_DUPLICATE simplification (PR rtl-optimization/84989)

On 03/20/2018 02:46 PM, Jakub Jelinek wrote: > Hi! > > On the following testcase, simplify_unary_operation is called on > VEC_DUPLICATE from (vec_duplicate:V4SF something:SF) to V8SFmode, > and simplify_unary_operation_1 tries an optimization usable for most > unary operations, in particular it

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

On 03/12/2018 08:56 PM, David H. Gutteridge wrote: > 2018-03-12 David H. Gutteridge > > PR target/84838 > * Minor grammar fixes for x86 options. > THanks. Installed. jeff

Re: [Patch] test_summary: handle single quotes

On 02/28/2018 02:30 AM, 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: > [...] >

[PATCH, PR84660] Fix combine bug with SHIFT_COUNT_TRUNCATED.

This fixes a wrong-code issue on RISC-V, but in theory could be a problem for any SHIFT_COUNT_TRUNCATED target. The testcase computes 46 or 47 (0x2e or 0x2f), then ANDs the value with 0xf, and then SHIFTs the value. On a SHIFT_COUNT_TRUNCATED target, the AND can get optimized away because for a

Re: [PR c++/84789] do not resolve typename into template-independent

On Mar 20, 2018, Jason Merrill wrote: > On Fri, Mar 16, 2018 at 5:38 PM, Alexandre Oliva wrote: >> resolve_typename_type may peek into template types that might still be >> specialized. In some cases, e.g. g++.dg/template/friend48.C or >>

Re: [PATCH] [PR c++/84610,84642] recover from implicit template parms gracefully

On Tue, Mar 20, 2018 at 5:57 PM, Alexandre Oliva wrote: > On Mar 20, 2018, Jason Merrill wrote: > >>> While debugging this, I first tried another patch, that avoids the same >>> ICEs. I thought this one was a more complete solution, and it renders >>> the

Re: [PR c++/84729] convert new init to array elt type

On Tue, Mar 20, 2018 at 5:56 PM, Alexandre Oliva wrote: > On Mar 20, 2018, Jason Merrill wrote: > >> On Sat, Mar 10, 2018 at 6:57 AM, Alexandre Oliva wrote: >>> A parenthesized initializer is only accepted when new()ing an array in >>>

[PATCH] Fix trunk failing to build for msp430-elf

Trunk doesn't build for msp430 due to an ICE whilst building libstdc++. The following patch proposed a while ago fixes the issue, but hasn't been applied: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01433.html I don't have write access, so if the patch is acceptable I would appreciate if

Re: [PATCH] [PR c++/71965] silence multi-dim array init sorry without tf_error

On Tue, Mar 20, 2018 at 5:55 PM, Alexandre Oliva wrote: > On Mar 20, 2018, Jason Merrill wrote: > >> On Sat, Mar 17, 2018 at 8:11 AM, Alexandre Oliva wrote: >>> - sorry >>> - ("cannot initialize multi-dimensional

Re: [C++ PATCH] Fix ICE with inline asm and MODIFY_EXPR/preinc/predec in output operand (PR c++/84961)

On Tue, Mar 20, 2018 at 5:04 PM, Jakub Jelinek wrote: > Hi! > > While in C, x = 10 or ++x or --x aren't lvalues and so we reject such > expressions in inline asm output operands (and inputs that only allow > memory, not registers), in C++ they apparently are lvalues; for output

Re: [PATCH] [PR c++/84610,84642] recover from implicit template parms gracefully

On Mar 20, 2018, Jason Merrill wrote: >> While debugging this, I first tried another patch, that avoids the same >> ICEs. I thought this one was a more complete solution, and it renders >> the other unnecessary, but I still though it might be useful to disable >>

Re: [PR c++/84729] convert new init to array elt type

On Mar 20, 2018, Jason Merrill wrote: > On Sat, Mar 10, 2018 at 6:57 AM, Alexandre Oliva wrote: >> A parenthesized initializer is only accepted when new()ing an array in >> permissive mode. We were not careful, however, to convert the >> TREE_LIST

Re: [PATCH] [PR c++/71965] silence multi-dim array init sorry without tf_error

On Mar 20, 2018, Jason Merrill wrote: > On Sat, Mar 17, 2018 at 8:11 AM, Alexandre Oliva wrote: >> - sorry >> - ("cannot initialize multi-dimensional array with initializer"); > This shouldn't even be a sorry anymore > Let's make it a

Re: [PATCH] relax -Wclass-memaccess for class members (PR 84850)

OK. On Mon, Mar 19, 2018 at 10:06 PM, Martin Sebor wrote: > The -Wclass-memaccess warning makes an exception for ctors and > dtors of non-trivial classes with no bases to avoid triggering > for uses of raw memory functions with this as the destination. > All other members as

Re: [PATCH] Fix compile-time hog in MPX boundary checking (PR target/84988).

Jeff Law writes: > On 03/20/2018 01:36 PM, Martin Liška wrote: >> Hi. >> >> This is a work-around to not iterate all members of array that can be huge. >> As MPX will be removed in GCC 9.x, I hope it's acceptable. I don't want >> to come >> up with a new param for it. >> >>

Re: Results for 8.0.1 20180316 (experimental) [trunk revision 258610] (GCC) libstdc++ testsuite on x86_64-pc-linux-gnu

On 20 March 2018 at 21:02, François Dumont wrote: > On 20/03/2018 19:20, Jonathan Wakely wrote: >> >> On 17 March 2018 at 09:01, Jonathan Wakely wrote: >>> >>> Native configuration is x86_64-pc-linux-gnu >>> >>> === libstdc++ tests === >>> >>> >>> Running target

[C++ PATCH] Fix ICE with inline asm and MODIFY_EXPR/preinc/predec in output operand (PR c++/84961)

Hi! While in C, x = 10 or ++x or --x aren't lvalues and so we reject such expressions in inline asm output operands (and inputs that only allow memory, not registers), in C++ they apparently are lvalues; for output operands we ICE in the gimplifier on this, because in the generic code MODIFY_EXPR

Re: [PATCH/testsuite] Skip vect-strided-shift-1.c on MIPS with -mpaired-single option.

On 03/14/2018 12:29 AM, Paul Hua wrote: > Hi: > > The vect-strided-shift-1.c test fails on MIPS target. > > FAIL: gcc.dg/vect/vect-strided-shift-1.c -mpaired-single > scan-tree-dump-times vect "vectorized 1 loops in function" 1 (found 0 > times) > FAIL: gcc.dg/vect/vect-strided-shift-1.c -flto

Re: Results for 8.0.1 20180316 (experimental) [trunk revision 258610] (GCC) libstdc++ testsuite on x86_64-pc-linux-gnu

On 20/03/2018 19:20, Jonathan Wakely wrote: On 17 March 2018 at 09:01, Jonathan Wakely wrote: Native configuration is x86_64-pc-linux-gnu === libstdc++ tests === Running target unix/-std=gnu++11/-D_GLIBCXX_ASSERTIONS === libstdc++ Summary for

Re: [PATCH] Add test-case (PR ipa/84805).

On 03/14/2018 11:23 AM, Martin Liška wrote: > Hi. > > This is a new test-case isolated from libreoffice. > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > I'm going to install it. > > Martin > > gcc/testsuite/ChangeLog: > > 2018-03-14 Martin Liska

Re: [C++ PATCH] Fix FIX_TRUNC_EXPR instantiation (PR c++/84942)

On Mon, Mar 19, 2018 at 3:50 PM, Jakub Jelinek wrote: > +int a(__attribute__((b((int)__builtin_inf() * 1ULL / auto; This seems like another situation like 84610 and 84642 that Alex sent a patch for, of 'auto' in an attribute wrongly being treated as an implicit template

Re: [Patch] Document __builtin_extend_pointer

On 03/20/2018 06:08 AM, Tom de Vries wrote: > On 02/20/2018 06:33 PM, Steve Ellcey wrote: >> +@deftypefn {Built-in Function} Pmode __builtin_extend_pointer (void * x) >> +On targets where the user visible pointer size is different than the >> size >> +of an actual hardware address this function

Re: [PATCH] Remove superfluous return statement (PR ipa/84963).

On 03/20/2018 01:40 PM, Martin Liška wrote: > Hi. > > I'm sending removal of a stupid mistake where I installed a patch that > contained > a debugging 'return' statement. Fixed that and added condition to > inspect only > functions with SSA. > > Patch can bootstrap on ppc64le-redhat-linux and

[PATCH] Fix VEC_DUPLICATE simplification (PR rtl-optimization/84989)

Hi! On the following testcase, simplify_unary_operation is called on VEC_DUPLICATE from (vec_duplicate:V4SF something:SF) to V8SFmode, and simplify_unary_operation_1 tries an optimization usable for most unary operations, in particular it attempts to do (vec_duplicate:V8SF (unary:SF

Re: [PATCH] Don't RTL DCE REG_CFA_RESTORE noop moves (PR debug/84875)

On 03/15/2018 01:20 PM, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs on s390x-linux, because we have 2 registers > saved in prologue, but only one of them modified in one path and then > both restored there; cprop_hardreg propagates the saving register into the > REG_CFA_RESTORE

[PATCH] Fix up handling of bool BIT_NOT_EXPRs in store-merging (PR tree-optimization/84982)

Hi! Boolean !x is often expanded as ^ 1, but store merging it actually merges as ^ 255 (for 8-bit bool), which is incorrect. The following patch fixes it to do that ^ 1 instead. Bootstrapped/regtested on x86_64-linux and i686-linux and checked on the testcase with -> powerpc64-linux cross, ok

Re: [PR c++/71251] out-of-range parms in tmpl arg substitution

On Tue, Mar 20, 2018 at 4:15 PM, Alexandre Oliva wrote: > On Mar 20, 2018, Jason Merrill wrote: > >> On Sat, Mar 17, 2018 at 8:13 AM, Alexandre Oliva wrote: >>> As we go through each of the template parameters, substituting it with >>>

Re: C++ PATCH for c++/71638, ICE with NSDMI and reference

OK. On Tue, Mar 20, 2018 at 3:50 PM, Marek Polacek wrote: > This extends my previous fix for c++/84927 in that it also updates > the ctor's flags when we replace an element. > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > 2018-03-20 Marek Polacek

Re: [RFC Patch], PowerPC memory support pre-gcc9, patch #1

On Tue, Mar 20, 2018 at 08:01:57AM -0500, Segher Boessenkool wrote: > Hi! Some comments... > > On Wed, Mar 14, 2018 at 06:54:08PM -0400, Michael Meissner wrote: > > The first patch in the series moves most of the reg_addr structure from > > rs6000.c to rs6000-protos.h, so that in the next patch,

Re: [PR c++/84789] do not resolve typename into template-independent

On Fri, Mar 16, 2018 at 5:38 PM, Alexandre Oliva wrote: > resolve_typename_type may peek into template types that might still be > specialized. In some cases, e.g. g++.dg/template/friend48.C or > g++.dg/template/decl2.C, that is exactly the right thing to do. In > others,

Re: [RFC Patch], PowerPC memory support pre-gcc9, patch #2

On Tue, Mar 20, 2018 at 08:30:57AM -0500, Segher Boessenkool wrote: > On Thu, Mar 15, 2018 at 01:04:30PM -0400, Michael Meissner wrote: > > This is patch #2 of my series for improving the PowerPC internal memory > > support. It assumes patch #1 has been applied. > > > > This patch moves the

Re: [PATCH] Fix PR84512

Hi Tom, > On 03/19/2018 10:11 AM, Richard Biener wrote: >> On Fri, 16 Mar 2018, Tom de Vries wrote: >> >>> On 03/16/2018 12:55 PM, Richard Biener wrote: On Fri, 16 Mar 2018, Tom de Vries wrote: > On 02/27/2018 01:42 PM, Richard Biener wrote: >> Index:

Re: [PR c++/71251] out-of-range parms in tmpl arg substitution

On Mar 20, 2018, Jason Merrill wrote: > On Sat, Mar 17, 2018 at 8:13 AM, Alexandre Oliva wrote: >> As we go through each of the template parameters, substituting it with >> corresponding template arguments, an incorrect argument list might >> cause us to

Re: [PATCH PR84969]Don't reorder builtin memsets if they set different rhs values

On 03/20/2018 07:18 PM, Bin Cheng wrote: Hi, As noted in PR84969, fuse_memset_builtins breaks dependence between different memsets. Specifically, it reorders different builtin memset partitions though it doesn't merge them in the end. This simple patch fixes this wrong code issue by checking

C++ PATCH for c++/71638, ICE with NSDMI and reference

This extends my previous fix for c++/84927 in that it also updates the ctor's flags when we replace an element. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2018-03-20 Marek Polacek PR c++/71638, ICE with NSDMI and reference. * constexpr.c

Re: [PATCH ] PR 844422 Fix FCTID, FCTIW with -mcpu=power7

On 3/16/18 5:51 PM, Segher Boessenkool wrote: > But fctiw is an ISA 1.xx instruction already (and fctid is as well, > but explicitly undefined for 32-bit implementations until some 2.xx, > I forgot which, 2.02 I think?) > > Requiring power8 for it is weird and surprising. power8-vector doubly

Re: [PR c++/84610,84642] recover from implicit template parms gracefully

On Sat, Mar 10, 2018 at 6:57 AM, Alexandre Oliva wrote: > If we get a parse error during an attempted fully implicit function > template parse, and need to skip to the end of the statement or block, > we may discard the function parms scope rather than the enclosing > injected

Re: Seeking Release Manager approval for: [PATCH] jit: fix link on OS X and Solaris (PR jit/64089 and PR jit/84288)

On Tue, 2018-03-20 at 09:38 +0100, Rainer Orth wrote: > Hi David, > > > Release managers: > > > > I'd like to apply FX's patch here: > > https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00881/patch > > to trunk, to fix the build of jit on OS X, and to make it easier to > > fix > > it on Solaris.

[PATCH] Remove superfluous return statement (PR ipa/84963).

Hi. I'm sending removal of a stupid mistake where I installed a patch that contained a debugging 'return' statement. Fixed that and added condition to inspect only functions with SSA. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Thanks, Martin gcc/ChangeLog:

Re: [PATCH] Fix compile-time hog in MPX boundary checking (PR target/84988).

On 03/20/2018 01:36 PM, Martin Liška wrote: > Hi. > > This is a work-around to not iterate all members of array that can be huge. > As MPX will be removed in GCC 9.x, I hope it's acceptable. I don't want > to come > up with a new param for it. > > Survives tests on x86_64-linux-gnu. > > Martin

[PATCH] Fix compile-time hog in MPX boundary checking (PR target/84988).

Hi. This is a work-around to not iterate all members of array that can be huge. As MPX will be removed in GCC 9.x, I hope it's acceptable. I don't want to come up with a new param for it. Survives tests on x86_64-linux-gnu. Martin gcc/ChangeLog: 2018-03-20 Martin Liska

Re: [PATCH][AARCH64] PR target/84521 Fix frame pointer corruption with -fomit-frame-pointer with __builtin_setjmp

On 19/03/18 12:11, James Greenhalgh wrote: On Wed, Mar 14, 2018 at 05:40:49PM +, Sudi Das wrote: Hi This patch is another partial fix for PR 84521. This is adding a definition to one of the target hooks used in the SJLJ implemetation so that AArch64 defines the hard_frame_pointer_rtx as

Re: Deprecate some C++ extensions

On 03/20/2018 12:37 PM, Nathan Sidwell wrote: This patch deprecates 2 sets of extensions 1)  'T v (init) __attribute__ ((ignored))' That attribute placement has had no effect since the new parser (2002, I think gcc 3.3).  Now we're more noisy about it. 2) anonymous struct or union members

Desire to allocate bit in DT_PARM bitmask for DEC FORMAT compatibility purposes

Codethink has several more changes that improve gfortran's ability to handle legacy codebases, particularly those which rely on DEC extensions. Most are strictly compiler side issues. However, one touches on the runtime. Specifically, as an extension, DEC Fortran allows omitting the width in

Deprecate some C++ extensions

This patch deprecates 2 sets of extensions 1) 'T v (init) __attribute__ ((ignored))' That attribute placement has had no effect since the new parser (2002, I think gcc 3.3). Now we're more noisy about it. 2) anonymous struct or union members could be things other than public non-static

[og7] backport fix for PR84952

I've applied this patch to openacc-gcc-7-branch which backports Tom's fix for the nvptx bar.sync placement bug in PR84952. This patch also reverts some changes I introduced in git revision 7445a4d40. Tom's patch didn't apply cleanly because of the recent I renamed nvptx_wsync to nvptx_cta_sync so

Re: [PR c++/84647] undeclared fn called in auto default arg in ptr decl

On Sat, Mar 10, 2018 at 6:57 AM, Alexandre Oliva wrote: > We ICEd when attempting to convert a default arg for an auto parm, the > default arg amounting to a call to an undeclared function, in a > declaration of a pointer to function variable. This seems to have been fixed by

[PATCH PR84969]Don't reorder builtin memsets if they set different rhs values

Hi, As noted in PR84969, fuse_memset_builtins breaks dependence between different memsets. Specifically, it reorders different builtin memset partitions though it doesn't merge them in the end. This simple patch fixes this wrong code issue by checking if any two builtin memsets set the same

Re: [PR middle-end/70359] uncoalesce IVs outside of loops

On Tue, Mar 20, 2018 at 5:56 PM, Richard Biener wrote: > On March 20, 2018 6:11:53 PM GMT+01:00, "Bin.Cheng" > wrote: >>On Mon, Mar 19, 2018 at 5:08 PM, Aldy Hernandez >>wrote: >>> Hi Richard. >>> >>> As discussed in the PR,

Re: [PR c++/84729] convert new init to array elt type

On Sat, Mar 10, 2018 at 6:57 AM, Alexandre Oliva wrote: > A parenthesized initializer is only accepted when new()ing an array in > permissive mode. We were not careful, however, to convert the > TREE_LIST initializer to the array element type in this extension. > This patch

Re: C++ PATCH for c++/84978, ICE with NRVO

On Tue, Mar 20, 2018 at 11:55 AM, Jason Merrill wrote: > On Tue, Mar 20, 2018 at 9:32 AM, Marek Polacek wrote: >> We started crashing on this test with r258592 which added >> cp_get_callee_fndecl >> in in cp_genericize_r. >> >> This ICE apparently depends

Re: [PR middle-end/70359] uncoalesce IVs outside of loops

On March 20, 2018 6:11:53 PM GMT+01:00, "Bin.Cheng" wrote: >On Mon, Mar 19, 2018 at 5:08 PM, Aldy Hernandez >wrote: >> Hi Richard. >> >> As discussed in the PR, the problem here is that we have two >different >> iterations of an IV live outside of a

Re: [PATCH, rs6000] Finish implementation of __builtin_atlivec_lvx_v1ti

On 3/14/18 4:27 PM, Kelvin Nilsen wrote: > @@ -14452,6 +14452,7 @@ altivec_expand_lv_builtin (enum insn_code icode, t > LVXL and LVE*X expand to use UNSPECs to hide their special behavior, > so the raw address is fine. */ >if (icode == CODE_FOR_altivec_lvx_v2df_2op > + ||

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

On 3/20/18 11:42 AM, Segher Boessenkool wrote: > On Mon, Mar 19, 2018 at 09:12:08PM -0500, Peter Bergner wrote: >> Looking at mu build dirs insn-modes.h, I don't see HAVE_V8HFmode being >> defined on either my LE or BE builds. What am I missing? > > Nothing, I just was confused (we always define

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

Hi, On Tue, 20 Mar 2018, Andreas Krebbel wrote: > On 03/13/2018 04:53 PM, Michael Matz wrote: > > 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

[PATCH][arm] PR target/82518: Return false in ARRAY_MODE_SUPPORTED_P for BYTES_BIG_ENDIAN

Hi all, This PR shows that we get the load/store_lanes logic wrong for arm big-endian. It is tricky to get right. Aarch64 does it by adding the appropriate lane-swapping operations during expansion. I'd like to do the same on arm eventually, but we'd need to port and validate the

Re: [PR middle-end/70359] uncoalesce IVs outside of loops

On Mon, Mar 19, 2018 at 5:08 PM, Aldy Hernandez wrote: > Hi Richard. > > As discussed in the PR, the problem here is that we have two different > iterations of an IV live outside of a loop. This inhibits us from using > autoinc/dec addressing on ARM, and causes extra lea's on

Re: [PR c++/71251] out-of-range parms in tmpl arg substitution

On Sat, Mar 17, 2018 at 8:13 AM, Alexandre Oliva wrote: > As we go through each of the template parameters, substituting it with > corresponding template arguments, an incorrect argument list might > cause us to index argument vectors past their length (or fail in the >

Re: [PR c++/71965] silence multi-dim array init sorry without tf_error

On Sat, Mar 17, 2018 at 8:11 AM, Alexandre Oliva wrote: > We shouldn't substitute templates into short-circuited-out concepts > constraints, but we do, and to add insult to injury, we issue a > sorry() error when a concept that shouldn't even have been substituted > attempts to

Re: deprecate ignored attributes?

On Tue, Mar 20, 2018 at 10:37 AM, Nathan Sidwell wrote: > Jason, in parser.c > /* The old parser allows attributes to appear after a parenthesized > initializer. Mark Mitchell proposed removing this functionality > on the GCC mailing lists on 2002-08-13. This parser

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

On Mon, Mar 19, 2018 at 09:12:08PM -0500, Peter Bergner wrote: > On 3/12/18 1:55 PM, Segher Boessenkool wrote: > >> #ifdef HAVE_V8HFmode > >> - else if (mode == V8HFmode) > >> - stvx = TARGET_64BIT > >> -? gen_altivec_stvx_v8hf_1op (src_exp, memory_address) > >> -:

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

On 03/13/2018 04:53 PM, Michael Matz wrote: > 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

Re: [PR c++/84962] ICE with anon-struct member

On Tue, Mar 20, 2018 at 9:55 AM, Nathan Sidwell wrote: > This fixes the 84962 ICE, which is where we name a member function of an > anon-struct in the width specifier of a bitfield. The problem is that when > permissive we allow some of this strangeness. Prior to my lookup

Re: [RFC Patch], PowerPC memory support pre-gcc9, patch #1

On Fri, Mar 16, 2018 at 07:01:18PM -0400, Michael Meissner wrote: > In patch #4, I mentioned that the spec 2006 benchmark 'tonto' generated > different with the patches applied. I tracked it down, and it was due to the > call I inserted in rs6000_debug_reg_print to update the conditional register

Re: [RFC Patch], PowerPC memory support pre-gcc9, patch #4

Hi Mike, On Fri, Mar 16, 2018 at 12:50:45PM -0400, Michael Meissner wrote: > --- gcc/config/rs6000/rs6000-output.c (revision 258576) > +++ gcc/config/rs6000/rs6000-output.c (working copy) > @@ -162,7 +162,13 @@ rs6000_output_move_64bit (rtx operands[] > >/* Moves to SPRs. */ >

Re: C++ PATCH for c++/84978, ICE with NRVO

On Tue, Mar 20, 2018 at 9:32 AM, Marek Polacek wrote: > We started crashing on this test with r258592 which added cp_get_callee_fndecl > in in cp_genericize_r. > > This ICE apparently depends on whether we perform NRVO or not. If the size of > S is <=16B we pass it in

[PR c++/84970] lookup marking

This is another case of lookups escaping into template bodies, without being marked. In this case an initializer list. in the non-template case, we try and recycle these lookup nodes immediately. But for templates we have to mark lookups, so we don't try and mutate them via the binding.

Re: [PATCH] Fix typos (PR other/84819).

On 03/20/2018 04:28 PM, Gerald Pfeifer wrote: > On Tue, 20 Mar 2018, Martin Liška wrote: >> There's patch for couple of documentation issues reported in the PR. > > Looks good to me, thanks! > > Just, should there be an "a" in "use jump table"? Looks good. And 'an indirect jump.' ? Martin >

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

Hi Andrew -- I just do a visual check. The script can help. On 03/20/2018 07:13 AM, Andrew Sadek wrote: Many Thanks Michael for the updates .. I was actually looking for something similar for my test case .. I m currently revising the Gnu code conventions on the patches then will send them

Re: [PATCH] Fix typos (PR other/84819).

On Tue, 20 Mar 2018, Martin Liška wrote: > There's patch for couple of documentation issues reported in the PR. Looks good to me, thanks! Just, should there be an "a" in "use jump table"? Geralddiff --git a/gcc/calls.c b/gcc/calls.c index 4dcfef77a5a..9eb0467311b 100644 --- a/gcc/calls.c +++

Re: Use SCEV information when aligning for vectorisation (PR 84005)

Richard Biener writes: > On Mon, Mar 19, 2018 at 10:27 PM, Richard Sandiford > wrote: >> Richard Biener writes: >>> On Sat, Mar 17, 2018 at 11:45 AM, Richard Sandiford >>> wrote:

Re: PING: [PATCH] x86: Force __x86_indirect_thunk_reg for function call via GOT

On Tue, Mar 20, 2018 at 7:48 AM, Jan Hubicka wrote: >> On Tue, Feb 27, 2018 at 11:39 AM, H.J. Lu wrote: >> > For x86 targets, when -fno-plt is used, external functions are called >> > via GOT slot, in 64-bit mode: >> > >> > [bnd] call/jmp

Re: PING: [PATCH] x86: Force __x86_indirect_thunk_reg for function call via GOT

> On Tue, Feb 27, 2018 at 11:39 AM, H.J. Lu wrote: > > For x86 targets, when -fno-plt is used, external functions are called > > via GOT slot, in 64-bit mode: > > > > [bnd] call/jmp *foo@GOTPCREL(%rip) > > > > and in 32-bit mode: > > > > [bnd] call/jmp

deprecate ignored attributes?

Jason, in parser.c /* The old parser allows attributes to appear after a parenthesized initializer. Mark Mitchell proposed removing this functionality on the GCC mailing lists on 2002-08-13. This parser accepts the attributes -- but ignores them. */ if

Re: [PATCH] Fix PR84859

On Tue, Mar 20, 2018 at 01:42:04PM +0100, Richard Biener wrote: > 2018-03-20 Richard Biener > > * testsuite/libgomp.graphite/force-parallel-4.c: XFAIL one > parallelizable loop. > > Index: libgomp/testsuite/libgomp.graphite/force-parallel-4.c >

[PATCH] Fix typos (PR other/84819).

Hi. There's patch for couple of documentation issues reported in the PR. Ready for trunk? Thanks, Martin gcc/ChangeLog: 2018-03-20 Martin Liska PR other/84819 * calls.c (initialize_argument_information): Fix trailing space. * common.opt: Fix typo and

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

Many Thanks Michael for the updates .. I was actually looking for something similar for my test case .. I m currently revising the Gnu code conventions on the patches then will send them again. I m actually running the 'check_GNU_Style' in contrib folder,, is this the correct way ? Is it enough ?

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

> On 03/13/2018 01:13 PM, Martin Liška wrote: > > 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 > >

[PR c++/84962] ICE with anon-struct member

This fixes the 84962 ICE, which is where we name a member function of an anon-struct in the width specifier of a bitfield. The problem is that when permissive we allow some of this strangeness. Prior to my lookup changes, we only added TYPE_FIELDS and we still do that. Trouble is that now

Re: Use SCEV information when aligning for vectorisation (PR 84005)

On Mon, Mar 19, 2018 at 10:27 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Sat, Mar 17, 2018 at 11:45 AM, Richard Sandiford >> wrote: >>> Index: gcc/tree-data-ref.c >>>

Re: [PATCH] Fix PR84986

The way i originally made the code was going through ix86_rtx_costs and factoring out/simplifying logic that translates directly to trees. With NOP_EXPR I probably only tought of subgregs and other free stuff which truly_noop_* probably simulates quite well. ix86_rtx_costs understand how to zero

Re: [PATCH] Fix ICE in match_asm_constraints_1 (PR inline-asm/84941)

Hi, On Tue, 20 Mar 2018, Jakub Jelinek wrote: > It is very common that input is one of the above cases, during x86_64-linux > and i686-linux bootstraps+regtests I got: > 13201x CONST_INT, 1959x MEM, 114x SUBREG, 110x SYMBOL_REF, > 2x PLUS (the new testcase only) > and most of those were actually

Re: [PR middle-end/70359] uncoalesce IVs outside of loops

On Mon, Mar 19, 2018 at 6:08 PM, Aldy Hernandez wrote: > Hi Richard. > > As discussed in the PR, the problem here is that we have two different > iterations of an IV live outside of a loop. This inhibits us from using > autoinc/dec addressing on ARM, and causes extra lea's on

Re: [PATCH] Fix PR84986

On Tue, Mar 20, 2018 at 11:41:01AM +0100, Richard Biener wrote: > If the precision matches the mode maybe. But I thought we try to > avoid using %al (HImode) or %ax (QImode) operands in the end? Yes, but we try to do that only on the level of the emitted assembly, sometimes we simply emit a

C++ PATCH for c++/84978, ICE with NRVO

We started crashing on this test with r258592 which added cp_get_callee_fndecl in in cp_genericize_r. This ICE apparently depends on whether we perform NRVO or not. If the size of S is <=16B we pass it in registers and it compiles fine. But if the size of S is >16B, then we pass in memory, and

Re: [RFC Patch], PowerPC memory support pre-gcc9, patch #2

On Thu, Mar 15, 2018 at 01:04:30PM -0400, Michael Meissner wrote: > This is patch #2 of my series for improving the PowerPC internal memory > support. It assumes patch #1 has been applied. > > This patch moves the rs6000_move_128bit function from rs6000.c to a new file, > rs6000-output.c. > >

Re: [PATCH] Remove ICEing test-case.

On Tue, Mar 20, 2018 at 9:08 AM, Martin Liška wrote: > Hi. > > The CHKP test-case ICEs for me and as CHKP will be removed in next stage1, > I would like to remove the test-case. Will it be possible? OK. > Martin > > gcc/testsuite/ChangeLog: > > 2018-03-19 Martin Liska

Re: [wwwdocs] Update gcc-8/changes.html for some IPA and x86 canges

> On Mon, 19 Mar 2018, Jan Hubicka wrote: > > > Hi, > > this patch adds some documentation for what is new in IPA and x86. > > For lto we should mention early-debug. Richard, perhaps you can suggest > > wording? > > I have committed the following (will happily edit if necessary). Great thanks

  1   2   >