Re: [PATCH] PR fortran/42651 -- Fix accepts-invalid

Hi Steve, ping Pong! OK for trunk, and thanks for the patch. Regards Thomas

Re: [PATCH][i386,AVX] Fix PR84783 - backport missing permutexvar to GCC7

Hello Sebastian! On 22 мар 13:01, Peryt, Sebastian wrote: > Hi, > > This patch adds missing permutexvar intrinsics for backporting to GCC 7 to > resolve PR84783. > > 2018-03-22 Sebastian Peryt > > gcc: > PR84783 > * config/i386/avx512vlintrin.h (_mm256_permutexvar_epi64) > (_mm2

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

OK. On Fri, Mar 23, 2018 at 12:04 AM, Alexandre Oliva wrote: > On Mar 22, 2018, Jason Merrill wrote: > >> I think we definitely want to move the check down below the >> cp_parser_commit_to_tentative_parse. > > This worked. Regstrapped on i686- and x86_64-linux-gnu. Ok to install? > > [PR c++/7

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

On Mar 22, 2018, Jason Merrill wrote: > I think we definitely want to move the check down below the > cp_parser_commit_to_tentative_parse. This worked. Regstrapped on i686- and x86_64-linux-gnu. Ok to install? [PR c++/71251] check tmpl parms in template using decl Check that template using d

[PATCH 4/4] ASAN for MIPS: Add gcc port bits for MIPS to support -fsanitize=address.

Attribution to Jean Lee for spotting the right shadow-offset for MIPS and for cheering on. :) See xtensa and rs6000 back-ends for the FRAME_GROWS_DOWNWARD construct. gcc: 2018-03-22 Hans-Peter Nilsson Jean Lee * config/mips/mips.c (mips_asan_shadow_offset): New function

[PATCH 3/4] Enable libsanitizer for 32-bit mips*-*-linux*

If someone has access to a 64-bit mips-linux system to test this (with the obvious edit), that'd be really nice. Until then, best to not introduce possible build failures. libsanitizer: * configure.tgt : Enable build, excluding mips*64*-*-linux*. diff --git a/libsanitizer/config

[PATCH 2/4] ASAN for MIPS: Correct struct_kernel_stat_sz for MIPS and don't use .

As mentioned in the bogus adjustment to 160 from 144 (which is reverted here), is a single-token commit in upstream r301307, an attempt to correct a failed build due to an upstream change to compile the runtime with D_FILE_OFFSET_BITS=64. The corre

[PATCH 1/4] ASAN for MIPS: Add __sanitizer.lock.pad initializer, shutting up a warning

This appears to be present in compiler-rt upstream, but as part of more intrusive changes. For gcc, the lack of this results in a fatal warning (-Werror) at build-time. libsanitizer: * sanitizer_common/sanitizer_atomic_clang_other.h [_MIPS_SIM && _MIPS_SIM == _ABIO32] (lock): Add

[PATCH] Add ax_pthread.m4 for use in binutils-gdb

config/ * ax_pthread.m4: Add file --- config/ax_pthread.m4 | 485 +++ 1 file changed, 485 insertions(+) create mode 100644 config/ax_pthread.m4 diff --git a/config/ax_pthread.m4 b/config/ax_pthread.m4 new file mode 100644 index 000.

[PATCH 0/4] ASAN for MIPS (o32)

All patches are together run through the gcc and g++ test-suites to check ASAN results for mipsisa32r2el-linux-gnu. As of r258635 those results are on par with those for arm-linux-gnueabihf, so without delay I present the current state. Maybe it's non-intrusive enough to be ok for gcc-8? MIPS mai

Re: [PATCH] PR fortran/42651 -- Fix accepts-invalid

ping -- steve On Mon, Mar 19, 2018 at 06:13:58PM -0700, Steve Kargl wrote: > The attached patch fixes an accepts-invalid while enforcing > > C1560 (R1530) If RESULT appears, the function-name shall not appear > in any specification statement in the scoping unit of the function > subprogra

[PATCH] Fix another match_asm_constraints_1 issue (PR PR inline-asm/85034)

Hi! match_asm_constraints_1 verifies that the mode of input and output is the same, with one exception - when input is VOIDmode. It isn't correct to allow that blindly VOIDmode CONST_INT/CONST_DOUBLE is only ok if the output mode is scalar integer mode, on the testcase below output is (reg:SF), wh

[PATCH 4/4] C++: more std header hints; filter on C++ dialect (PR c++/84269)

Jonathan added a bunch more suggestions to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84269#c10 as I was testing my last patch, some of which need C++14 and C++17, and some of which use headers that exist in earlier standards. For example, exists in C++98, but if the user attempts to use std

[PATCH 3/4] C++: suggest missing headers for implicit use of "std" (PR c++/85021)

We provide fix-it hints for the most common "std" names when an explicit "std::" prefix is present, however we don't yet provide fix-it hints for this implicit case: using namespace std; void f() { cout << "test"; } for which we emit: t.cc: In function 'void f()': t.cc:2:13: error: 'cou

[PATCH 2/4] C: Ensure that we print include hints in -Wimplicit-function-declaration

I noticed when testing the previous patch on the C frontend that the fix-it hints weren't always showing up: -Wimplicit-function-declaration wasn't always providing a fix-it hint, but "incompatible implicit declaration of built-in function" was, *if* it warned. Consider e.g.: $ cat t.c void t

[PATCH 0/4] Improvements to #include suggestions

This patch kit adds various improvements to the suggestions we offer for missing #include directives, in response to recent feedback on my blog post. None of these are regressions, but it's a new user-visible feature, so would be nice to fix them for the release, and I believe they're relatively l

[PATCH 1/4] More #include suggestions (PR c++/84269)

PR c++/84269 reports a number of names in the C and C++ standard libraries for which we don't yet offer #include fix-it hints. This patch adds them (up to comment #9). Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. OK for trunk? gcc/c-family/ChangeLog: PR c++/84269

Re: [PATCH,rs6000] GCC -7, no swap optimization for vpermxor instruction

Hi Carl, On Thu, Mar 22, 2018 at 08:48:33AM -0700, Carl Love wrote: > The patch adds UNSPEC_VPERMXOR to the list of instruction to not apply > swap optimization to. A new test case was added to verify the results > with -O2 match the expected results from -O0. > Backport: UNSPEC_VPERMXOR fix from

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

On Mar 22, 2018, Jason Merrill wrote: > On Tue, Mar 20, 2018 at 10:29 PM, Alexandre Oliva wrote: >> 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 >>> abov

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

On Mar 22, 2018, Jakub Jelinek wrote: > On Thu, Mar 22, 2018 at 02:02:01PM -0400, Jason Merrill wrote: >> > To my surprise, with latest Alex' changes tsubst_copy_and_build is still >> > called with FIX_TRUNC_EXPR (the (int) __builtin_inf () expression) >> >> He hadn't yet checked in the relevant

Re: [PATCH] Fix PR85020

> This should then trigger the use of DW_OP_GNU_variable_value but > for the Ada ACATS testcase I was looking at to debug the issue > (c330001, resp. c330001_0-c330001_1.ads) this doesn't work > because the constraints are not met (we're in global context and > the upper bound decl is global as wel

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

On Wed, Mar 21, 2018 at 09:10:38PM -0500, Peter Bergner wrote: > On 3/21/18 7:37 PM, Segher Boessenkool wrote: > > On Wed, Mar 21, 2018 at 12:47:41PM -0500, Peter Bergner wrote: > >> I'll note that GCC 7 does not need any of the changes to rs6000-p8swap.c, > >> since that file doesn't exist and doe

[PATCH] [PR c++/84943] allow folding of array indexing indirect_ref

fn[0]() ICEs because we end up with addr_expr of a decl, and that should only happen for artificial or otherwise special internal functions. For anything else, we should find the decl earlier, but we don't because we build an indirect_ref or an addr_expr and don't cancel them out. Let fold do its

Re: [PATCH,rs6000] GCC -7, no swap optimization for vpermxor instruction

Hi Carl, On Wed, Mar 21, 2018 at 03:16:38PM -0700, Carl Love wrote: > Please let me know if the patch looks OK for the GCC 7 branch. Okay for 7 (and 6 too, if it applies there). Thanks! Segher > 2018-03-21 Carl Love > > * config/rs6000/r6000.c (rtx_is_swappable_p): Add case UNSPEC_

Re: [PATCH], PR target/84914, Fix complex long double multiply/divide on PowerPC -mabi=ieeelongdouble

On Wed, Mar 21, 2018 at 11:42:01AM -0400, Michael Meissner wrote: > +/* Create a decl for either complex long double multiply or complex long > double > + divide when long double is IEEE 128-bit floating point. We can't use > + __multc3 and __divtc3 because the original long double using IBM

[PATCH] Small x86 debug info improvement (PR debug/83157)

Hi! The following patch fixes: -FAIL: gcc.dg/guality/pr41616-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test -FAIL: gcc.dg/guality/pr41616-1.c -O3 -g execution test on x86_64-linux and -FAIL: gcc.dg/guality/pr41616-1.c -O3 -g execution test on i686-linux. The probl

Re: [C++ Patch] PR 84632 ("[8 Regression] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p...")

On Thu, Mar 22, 2018 at 5:39 PM, Paolo Carlini wrote: > ... with patch ;) > > If you are curious where the heck that INDIRECT_REF is coming from, is > coming from the gimplifier, cp_gimpliify_expr, via build_vec_init. Grrr. Hmm, maybe build_vec_init should call itself directly rather than via bui

Re: [C++ Patch] PR 84632 ("[8 Regression] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p...")

... with patch ;) If you are curious where the heck that INDIRECT_REF is coming from, is coming from the gimplifier, cp_gimpliify_expr, via build_vec_init. Grrr. Paolo. /// Index: cp/init.c === --- cp/init.c

Re: [C++ Patch] PR 84632 ("[8 Regression] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p...")

Hi, On 22/03/2018 22:19, Jason Merrill wrote: On Thu, Mar 22, 2018 at 3:35 PM, Paolo Carlini wrote: Hi again, On 22/03/2018 19:58, Paolo Carlini wrote: Nice. While I start implementing the above, any hint about thing like g++.dg/cpp0x/initlist68.C, which we would reject because involves a pl

[C++ PATCH] Fix error-recovery in compute_array_index_type (PR c++/85015)

Hi! We ICE during error-recovery on the following testcase, compute_array_index_type checks size for error_operand_p early (and it is not error operand; it is > where c is of reference type with error_mark_node DECL_INITIAL), then calls mark_rvalue_use (which returns error_mark_node), but we let

[PATCH] Fix alias.c ICE on inline-asm "=m" incomplete operand (PR inline-asm/85022)

Hi! Something I wasn't really aware, apparently we allow extern vars with incomplete types in "m" and "=m" constrained asm. The problem is that incomplete vars have VOIDmode mode and so their MEMs do as well, apparently everything works with it except a 2013-ish assert in alias.c. The following

[PATCH] Fix sanopt -fsanitize=pointer-overflow optimization (PR sanitizer/85029)

Hi! As the testcase shows, we can hit the assertion here (with code that is rejected only later on during expansion). Instead of the assertion, this patch just doesn't try to optimize those, maybe_optimize_ubsan_ptr_ifn is a pure optimization. Bootstrapped/regtested on x86_64-linux and i686-linu

Re: [C++ Patch] PR 84632 ("[8 Regression] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p...")

On Thu, Mar 22, 2018 at 3:35 PM, Paolo Carlini wrote: > Hi again, > > On 22/03/2018 19:58, Paolo Carlini wrote: > > Nice. While I start implementing the above, any hint about thing like > g++.dg/cpp0x/initlist68.C, which we would reject because involves a plain > constructor of type ARRAY_TYPE, no

Re: [C++ Patch] PR 84632 ("[8 Regression] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p...")

Hi again, On 22/03/2018 19:58, Paolo Carlini wrote: Nice. While I start implementing the above, any hint about thing like g++.dg/cpp0x/initlist68.C, which we would reject because involves a plain constructor of type ARRAY_TYPE, not a proper BRACE_ENCLOSED_INITIALIZER_P? Also, less important I

Re: [PATCH] PR fortran/84922 -- Check MODULE prefix is used

On Thu, Mar 22, 2018 at 10:22:48AM +0200, Janne Blomqvist wrote: > On Thu, Mar 22, 2018 at 12:19 AM, Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > If an interface body includes a MODULE prefix on a subroutine > > or function, then the prefix must appear on the contained > > subpr

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/22/2018 10:51 AM, Tom de Vries wrote: > On 03/22/2018 06:24 PM, Cesar Philippidis wrote: >> On 03/22/2018 09:18 AM, Tom de Vries wrote: >> >>> That's obviously not good enough. >>> >>> When I compile this test-case: >>> ... >>> int >>> main (void) >>> { >>>    int a[10]; >>> #pragma acc paral

Re: [C++ Patch] PR 84632 ("[8 Regression] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p...")

Hi, On 22/03/2018 19:08, Jason Merrill wrote: On Thu, Mar 22, 2018 at 4:05 AM, Paolo Carlini wrote: Hi, yesterday I figured out that this issue is in fact orthogonal to possible improvements to maybe_deduce_size_from_array_init, indeed it happens also when we are not deducing the size. The te

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

On 3/21/18 12:47 PM, Peter Bergner wrote: > Kaushik confirmed this is broken on GCC 7 as well. Ok to backport > this patch to GCC 7, assuming regtesting is clean? FYI, bootstrap and regtesting on both powerpc64le-linux and powerpc64-linux (testsuite run in both 32-bit and 64-bit modes) were clean

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

Hello Michael, I have adapted the test cases. Please find the patch below with Change log, description and test results. Description: -- This branch is regarding a new implemented feature in GCC Microblaze that allows Position Independent Code to run using Data Text Relative add

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

On Thu, Mar 22, 2018 at 02:02:01PM -0400, Jason Merrill wrote: > > To my surprise, with latest Alex' changes tsubst_copy_and_build is still > > called with FIX_TRUNC_EXPR (the (int) __builtin_inf () expression) > > He hadn't yet checked in the relevant change, "Disable > auto_is_implicit_function_

Re: [PATCH,rs6000] GCC -7, no swap optimization for vpermxor instruction

On 3/22/18 10:48 AM, Carl Love wrote: > Backport: UNSPEC_VPERMXOR fix from mainline commit 258530: > 2018-03-21  Carl Love   > > * config/rs6000/r6000.c (rtx_is_swappable_p): Add case UNSPEC_VPERMXOR. > > gcc/testsuite/ChangeLog: > > 2018-03-21  Carl Love   > * gcc.target/powerpc/cry

Re: [C++ PATCH] Implement P0962

OK, thanks. On Wed, Mar 21, 2018 at 8:42 PM, Ville Voutilainen wrote: > Tested on Linux-PPC64. > > 2018-03-22 Ville Voutilainen > > gcc/cp/ > > Implement P0962 > * parser.c (cp_parser_perform_range_for_lookup): Change > the condition for deciding whether to use members. > >

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

OK. On Wed, Mar 21, 2018 at 5:52 PM, Alexandre Oliva wrote: > On Mar 20, 2018, Jason Merrill wrote: > >>> -permerror (input_location, >>> - "parenthesized initializer in array new"); >>> +error_at (input_location, >>> +

Re: [C++ Patch] PR 84632 ("[8 Regression] internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p...")

On Thu, Mar 22, 2018 at 4:05 AM, Paolo Carlini wrote: > Hi, > > yesterday I figured out that this issue is in fact orthogonal to possible > improvements to maybe_deduce_size_from_array_init, indeed it happens also > when we are not deducing the size. The testcase is very similar to that > recently

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

On Thu, Mar 22, 2018 at 4:14 AM, Jakub Jelinek wrote: > On Wed, Mar 21, 2018 at 12:01:58PM -0400, Jason Merrill wrote: >> On Wed, Mar 21, 2018 at 4:42 AM, Jakub Jelinek wrote: >> > On Tue, Mar 20, 2018 at 05:00:34PM -0400, Jason Merrill wrote: >> >> On Mon, Mar 19, 2018 at 3:50 PM, Jakub Jelinek

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

On Tue, Mar 20, 2018 at 10:29 PM, Alexandre Oliva wrote: > 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 im

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/22/2018 06:47 PM, Cesar Philippidis wrote: On 03/22/2018 10:39 AM, Tom de Vries wrote: On 03/02/2018 05:55 PM, Cesar Philippidis wrote: +  rtx red_partition; /* Similar to bcast_partition, except for vector +    reductions.  */ Shouldn't this be in "[og7] vector_length extension

Re: [PATCH, PR84660] Fix combine bug with SHIFT_COUNT_TRUNCATED.

On Wed, Mar 21, 2018 at 2:45 AM, Richard Biener wrote: > On Tue, Mar 20, 2018 at 11:10 PM, Jim Wilson wrote: >> This fixes a wrong-code issue on RISC-V, but in theory could be a problem for >> any SHIFT_COUNT_TRUNCATED target. > IMHO the real issue is that SHIFT_COUNT_TRUNCATED is used for > opt

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/22/2018 06:24 PM, Cesar Philippidis wrote: On 03/22/2018 09:18 AM, Tom de Vries wrote: That's obviously not good enough. When I compile this test-case: ... int main (void) {   int a[10]; #pragma acc parallel num_workers (16) #pragma acc loop worker   for (int i = 0; i < 10; i++)     a

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

OK. On Wed, Mar 21, 2018 at 5:41 PM, Alexandre Oliva wrote: > On Mar 20, 2018, Jason Merrill wrote: > >> On Tue, Mar 20, 2018 at 5:57 PM, Alexandre Oliva wrote: >>> On Mar 20, 2018, Jason Merrill wrote: >> Let's put this in cp-tree.h, with warning_sentinel. > >>> + (void)cleanup; > >> There a

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/22/2018 10:39 AM, Tom de Vries wrote: > On 03/02/2018 05:55 PM, Cesar Philippidis wrote: >> +  rtx red_partition; /* Similar to bcast_partition, except for vector >> +    reductions.  */ > > Shouldn't this be in "[og7] vector_length extension part 3: reductions"? Maybe. But keep in

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/02/2018 05:55 PM, Cesar Philippidis wrote: + rtx red_partition; /* Similar to bcast_partition, except for vector + reductions. */ Shouldn't this be in "[og7] vector_length extension part 3: reductions"? Thanks, - Tom

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

In preparing to start work on reorganizing the intermediate address support in PowerPC, I noticed there were some thinkos in the undocumented toc fusion. There are three problems with toc fusion. Now, as I start reworking the address support in general, toc fusion and power9 fusion will likely be

Re: [PATCH] Fix PR85020

On Thu, Mar 22, 2018 at 03:16:22PM +0100, Richard Biener wrote: > the upper bound decl is global as well). Jakub, do you remember > a reason for having any constraints here? I've reworked the I don't, but it has been added in the https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01499.html patch. I

Re: [PATCH][ARM][PR target/84826] Fix ICE in extract_insn, at recog.c:2304 on arm-linux-gnueabi

Hi On 22/03/18 16:52, Kyrill Tkachov wrote: On 22/03/18 16:20, Sudakshina Das wrote: Hi Kyrill On 22/03/18 16:08, Kyrill Tkachov wrote: Hi Sudi, On 21/03/18 17:44, Sudakshina Das wrote: Hi The ICE in the bug report was happening because the macro USE_RETURN_INSN (FALSE) was returning diff

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/22/2018 09:18 AM, Tom de Vries wrote: > That's obviously not good enough. > > When I compile this test-case: > ... > int > main (void) > { >   int a[10]; > #pragma acc parallel num_workers (16) > #pragma acc loop worker >   for (int i = 0; i < 10; i++) >     a[i] = i; > >   return 0; > } >

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

On Thu, Mar 22, 2018 at 11:41:48AM -0500, Segher Boessenkool wrote: > On Thu, Mar 22, 2018 at 11:18:05AM -0400, Michael Meissner wrote: > > On Thu, Mar 22, 2018 at 10:03:55AM -0500, Segher Boessenkool wrote: > > > > callers to pass in the RELOAD_REG_VMX class explicitly. > > > > (rs

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/22/2018 07:44 AM, Tom de Vries wrote: > On 03/02/2018 05:55 PM, Cesar Philippidis wrote: >> The attached patch generalizes the worker state propagation and >> synchronization code to handle large vectors. When the vector_length is >> larger than a CUDA warp, the nvptx BE will now use shared-m

Re: [PATCH][ARM][PR target/84826] Fix ICE in extract_insn, at recog.c:2304 on arm-linux-gnueabi

On 22/03/18 16:20, Sudakshina Das wrote: Hi Kyrill On 22/03/18 16:08, Kyrill Tkachov wrote: Hi Sudi, On 21/03/18 17:44, Sudakshina Das wrote: Hi The ICE in the bug report was happening because the macro USE_RETURN_INSN (FALSE) was returning different values at different points in the compil

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

On Thu, Mar 22, 2018 at 11:18:05AM -0400, Michael Meissner wrote: > On Thu, Mar 22, 2018 at 10:03:55AM -0500, Segher Boessenkool wrote: > > > callers to pass in the RELOAD_REG_VMX class explicitly. > > > (rs6000_secondary_reload): Likewise. > > > (rs6000_preferred_reload_class): Likewise. > >

Re: [testsuite] Fix order of dg-do and dg-require-effective-target directives

On 22 March 2018 at 17:33, Kyrill Tkachov wrote: > Hi Christophe, > > On 22/03/18 16:31, Christophe Lyon wrote: >> >> Hi, >> >> I've noticed 3 tests where dg-do appears after >> dg-require-effective-target. >> This small patch fixes that. >> >> OK for stage4? >> > > Ok for the arm tests. > I woul

Re: [PATCH][PR84877]Dynamically align the address for local parameter copy on the stack when required alignment is larger than MAX_SUPPORTED_STACK_ALIGNMENT

Hi H.J. On 22/03/18 12:55, H.J. Lu wrote: On Thu, Mar 22, 2018 at 5:52 AM, H.J. Lu wrote: On Thu, Mar 22, 2018 at 4:56 AM, Renlin Li wrote: Hi all, As described in PR84877. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877 The local copy of parameter on stack is not aligned. For BLKmode p

Re: [testsuite] Fix order of dg-do and dg-require-effective-target directives

Hi Christophe, On 22/03/18 16:31, Christophe Lyon wrote: Hi, I've noticed 3 tests where dg-do appears after dg-require-effective-target. This small patch fixes that. OK for stage4? Ok for the arm tests. I would argue that these changes are obvious though. Thanks, Kyrill Thanks, Christop

[testsuite] Fix order of dg-do and dg-require-effective-target directives

Hi, I've noticed 3 tests where dg-do appears after dg-require-effective-target. This small patch fixes that. OK for stage4? Thanks, Christophe commit 068c140ced3946c477a92b145ced33c0c045b4db Author: Christophe Lyon Date: Thu Mar 22 16:04:39 2018 + [testsuite] Make sure dg-do is befo

Re: [PATCH][ARM][PR target/84826] Fix ICE in extract_insn, at recog.c:2304 on arm-linux-gnueabi

Hi Kyrill On 22/03/18 16:08, Kyrill Tkachov wrote: Hi Sudi, On 21/03/18 17:44, Sudakshina Das wrote: Hi The ICE in the bug report was happening because the macro USE_RETURN_INSN (FALSE) was returning different values at different points in the compilation. This was internally occurring becaus

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/22/2018 04:11 PM, Cesar Philippidis wrote: On 03/22/2018 07:23 AM, Tom de Vries wrote: On 03/02/2018 05:55 PM, Cesar Philippidis wrote: (nvptx_declare_function_name): Emit a .maxntid directive hint and call nvptx_init_oacc_workers. + +  /* Emit a .maxntid hint to help the PTX J

Re: [PATCH][ARM][PR target/84826] Fix ICE in extract_insn, at recog.c:2304 on arm-linux-gnueabi

Hi Sudi, On 21/03/18 17:44, Sudakshina Das wrote: Hi The ICE in the bug report was happening because the macro USE_RETURN_INSN (FALSE) was returning different values at different points in the compilation. This was internally occurring because the function arm_compute_static_chain_stack_bytes (

Re: [PATCH,rs6000] GCC -7, no swap optimization for vpermxor instruction

GCC Maintainers: This is a re-post of the patch which addresses the comments to the commit log by Peter Bergner. The following patch is a back port from mainlin of a fix for define_insn crypto_vpermxor_ in gcc/config/rs6000/crypto.md.  The issue is the vpermxor instruction does not work correctly

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

On 03/21/2018 04:43 PM, Richard Biener wrote: On Wed, 21 Mar 2018, Tom de Vries wrote: On 03/12/2018 01:14 PM, Richard Biener wrote: 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 f

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

Patches #5..8 just add comments and reformat movd{f,d} constraints and attributes so that it is a lot easier to tell which constraints and attributes go together. These do not (or at least should not) change the code generated. Patch #9 does the same thing for mov{sf,sd} when floating point regist

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

Patches #5..8 just add comments and reformat movd{f,d} constraints and attributes so that it is a lot easier to tell which constraints and attributes go together. These do not (or at least should not) change the code generated. Patch #9 does the same thing for mov{sf,sd} when floating point regist

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

Patches #5..8 just add comments and reformat movd{f,d} constraints and attributes so that it is a lot easier to tell which constraints and attributes go together. These do not (or at least should not) change the code generated. Patch #9 does the same thing for mov{sf,sd} when floating point regist

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

Patches #5..8 just add comments and reformat movd{f,d} constraints and attributes so that it is a lot easier to tell which constraints and attributes go together. These do not (or at least should not) change the code generated. Patch #9 does the same thing for mov{sf,sd} when floating point regist

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

On 03/21/2018 04:43 PM, Richard Biener wrote: On Wed, 21 Mar 2018, Tom de Vries wrote: On 03/12/2018 01:14 PM, Richard Biener wrote: 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 f

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

Patches #5..8 just add comments and reformat movd{f,d} constraints and attributes so that it is a lot easier to tell which constraints and attributes go together. These do not (or at least should not) change the code generated. Patch #9 does the same thing for mov{sf,sd} when floating point regist

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

On Thu, Mar 22, 2018 at 10:03:55AM -0500, Segher Boessenkool wrote: > Hi! > > On Thu, Mar 22, 2018 at 08:16:36AM -0400, Michael Meissner wrote: > > This match renames the d-form mode support function and makes it more > > general. > > It was originally written to test whether we have the ISA 3.0

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/22/2018 07:23 AM, Tom de Vries wrote: > On 03/02/2018 05:55 PM, Cesar Philippidis wrote: > >> (nvptx_declare_function_name): Emit a .maxntid directive hint and >> call nvptx_init_oacc_workers. > >> + >> +  /* Emit a .maxntid hint to help the PTX JIT emit SYNC branches.  */ >> +  if

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

Hi! On Thu, Mar 22, 2018 at 08:16:36AM -0400, Michael Meissner wrote: > This match renames the d-form mode support function and makes it more general. > It was originally written to test whether we have the ISA 3.0 new D*-form > instruction, but I believe in the future, I will want to use it also

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/02/2018 05:55 PM, Cesar Philippidis wrote: The attached patch generalizes the worker state propagation and synchronization code to handle large vectors. When the vector_length is larger than a CUDA warp, the nvptx BE will now use shared-memory to spill-and-fill vector state when transitioni

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

Hi Mike, On Thu, Mar 22, 2018 at 08:11:52AM -0400, Michael Meissner wrote: > This patch renames the mode_supports_vsx_dform_quad function and changes all > of > the callers. I'm thinking about enhancing the addressing parts in the > secondary reload support, and I wanted a more logical naming sc

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/22/2018 06:43 AM, Tom de Vries wrote: > On 03/22/2018 04:59 AM, Cesar Philippidis wrote: >> On 03/21/2018 10:10 AM, Tom de Vries wrote: >>> Changing the code generation scheme for workers is fine, but obviously >>> that should be a minimal, separate patch that we can bisect back to. >> >> Th

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

On 14 March 2018 at 23:01, Jonathan Wakely wrote: > Here's a very different patch. This gets rid of the __ptr_rel_ops and > just puts the special handling for pointers directly in the > std::less<_Tp*> etc. specializations. Then std::less uses > std::less for some pointer type P*. I've also added a

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/02/2018 05:55 PM, Cesar Philippidis wrote: (nvptx_declare_function_name): Emit a .maxntid directive hint and call nvptx_init_oacc_workers. + + /* Emit a .maxntid hint to help the PTX JIT emit SYNC branches. */ + if (lookup_attribute ("omp target entrypoint", DECL_ATTR

Re: [v3] xfail experimental/memory_resource/resource_adaptor.cc on 32-bit Solaris/x86 (PR libstdc++/77691)

On 22 March 2018 at 13:42, Rainer Orth wrote: > Hi Jonathan, > >> On 22/03/18 11:03 +0100, Rainer Orth wrote: >>>experimental/memory_resource/resource_adaptor.cc currently FAILs on >>>32-bit Solaris/x86: >>> >>>Assertion failed: aligned(p), file >>> /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuit

[PATCH] Fix PR85020

The following fixes profiledbootstrap with LTO for Ada where we end up with references to later optimized out decls in the early debug parts. The fix is to avoid running into /* Try harder to get a rtl. If this symbol ends up not being emitted in the current CU, resolve_addr will remove

Re: [og7] vector_length extension part 2: Generalize state propagation and synchronization

On 03/22/2018 04:59 AM, Cesar Philippidis wrote: On 03/21/2018 10:10 AM, Tom de Vries wrote: On 03/02/2018 05:55 PM, Cesar Philippidis wrote: In addition, nvptx_cta_sync and the corresponding nvptx_barsync insn, have been extended to take a barrier ID and a thread count. The idea here is to ass

Re: [v3] xfail experimental/memory_resource/resource_adaptor.cc on 32-bit Solaris/x86 (PR libstdc++/77691)

Hi Jonathan, > On 22/03/18 11:03 +0100, Rainer Orth wrote: >>experimental/memory_resource/resource_adaptor.cc currently FAILs on >>32-bit Solaris/x86: >> >>Assertion failed: aligned(p), file >> /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/experimental/memory_resource/resource_adaptor.cc, >>

Re: [Aarch64] Fix conditional branches with target far away.

Hi Sameera On 22/03/18 02:07, Sameera Deshpande wrote: Hi Sudakshina, As per the ARMv8 ARM, for the offset range (-1048576 ,1048572), the far branch instruction offset is inclusive of both the offsets. Hence, I am using <=||=> and not <||>= as it was in previous implementation. I have to admi

[PATCH][i386,AVX] Fix PR84783 - backport missing permutexvar to GCC7

Hi, This patch adds missing permutexvar intrinsics for backporting to GCC 7 to resolve PR84783. 2018-03-22 Sebastian Peryt gcc: PR84783 * config/i386/avx512vlintrin.h (_mm256_permutexvar_epi64) (_mm256_permutexvar_epi32, _mm256_permutex_epi64): New intrinsics. gcc/testsuite:

Re: [PATCH][PR84877]Dynamically align the address for local parameter copy on the stack when required alignment is larger than MAX_SUPPORTED_STACK_ALIGNMENT

On Thu, Mar 22, 2018 at 5:52 AM, H.J. Lu wrote: > On Thu, Mar 22, 2018 at 4:56 AM, Renlin Li wrote: >> Hi all, >> >> As described in PR84877. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877 >> The local copy of parameter on stack is not aligned. >> >> For BLKmode paramters, a local copy on the

Re: [PATCH][PR84877]Dynamically align the address for local parameter copy on the stack when required alignment is larger than MAX_SUPPORTED_STACK_ALIGNMENT

On Thu, Mar 22, 2018 at 4:56 AM, Renlin Li wrote: > Hi all, > > As described in PR84877. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877 > The local copy of parameter on stack is not aligned. > > For BLKmode paramters, a local copy on the stack will be saved. > There are three cases: > 1) argum

Re: [PATCH][PR84877]Dynamically align the address for local parameter copy on the stack when required alignment is larger than MAX_SUPPORTED_STACK_ALIGNMENT

On Thu, Mar 22, 2018 at 4:56 AM, Renlin Li wrote: > Hi all, > > As described in PR84877. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877 > The local copy of parameter on stack is not aligned. > > For BLKmode paramters, a local copy on the stack will be saved. > There are three cases: > 1) argum

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

This patch extends the other mode_supports* function to take an optional second argument to specificy particular reload register class, and it defaults to REG_RELOAD_ANY which says some reload register supports the feature. I have built bootstrap compilers with the first 4 patches including this p

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

This match renames the d-form mode support function and makes it more general. It was originally written to test whether we have the ISA 3.0 new D*-form instruction, but I believe in the future, I will want to use it also for GPR and tradiational floating point registers. I have built bootstrap co

Re: Deprecate not defining NO_IMPLICIT_EXTERN_C

On 03/21/2018 05:28 PM, Joseph Myers wrote: > My list from 2005 of targets not defining NO_IMPLICIT_EXTERN_C then is > . Thanks for the link. I see you floated inverting the sense of the switch -- which would be good, as it appears we still can

Re: [PATCH testsuite]Fix pr83126.c failure for bare-metal toolchains

On Thu, Mar 22, 2018 at 12:04 PM, Bin Cheng wrote: > Hi, > The new test pr83126.c requires pthread for compiling, this simple patch > skips it > for bare-metal toolchains. > > Test checked. Is it OK? OK. > Thanks, > bin > > gcc/testsuite > 2018-03-22 Bin Cheng > > * gcc.dg/graphite/

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

This patch just moves two of the mode_supports_* functions so they are all together. I have built bootstrap compilers with the first 4 patches including this patch on both big and little endian power8 systems. There were no regressions. 2018-03-21 Michael Meissner * config/rs6000/rs6

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

This patch renames the mode_supports_vsx_dform_quad function and changes all of the callers. I'm thinking about enhancing the addressing parts in the secondary reload support, and I wanted a more logical naming scheme. There will be mode_supports_d_form for offsettable addresses of any form, and

[RFC Patch], PowerPC memory support pre-gcc9, Version 2

I will be submitting reworked patches for the stuff I want to do in GCC 9. The initial patches are mostly initial cleanup and slight rework of the support functions. These patches will be limited to changing one thing at a time, instead of larger patches like I did in the first set of patches. -

[PATCH][PR84877]Dynamically align the address for local parameter copy on the stack when required alignment is larger than MAX_SUPPORTED_STACK_ALIGNMENT

Hi all, As described in PR84877. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877 The local copy of parameter on stack is not aligned. For BLKmode paramters, a local copy on the stack will be saved. There are three cases: 1) arguments passed partially on the stack, partially via registers. 2)

  1   2   >