[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, 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 submitted for c++/78345, which led Jason to add the bit of a

Re: [PATCH] Fix up -fsanitize=address on -fsection-anchors targets (PR sanitizer/85018)

On Wed, 21 Mar 2018, Jakub Jelinek wrote: > Hi! > > I've committed my last patch to unbreak aarch64 and powerpc* bootstrap > in a rush just after watching it passed bootstrap, not waiting for test > results. > Unfortunately, it seems the DECL_INITIAL (decl) = decl; hack wasn't used as > the comme

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

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 > subprogram. This patch does that check, and issues an error > message. > > 2018-0

[PATCH] Fix up -fsanitize=address on -fsection-anchors targets (PR sanitizer/85018)

Hi! I've committed my last patch to unbreak aarch64 and powerpc* bootstrap in a rush just after watching it passed bootstrap, not waiting for test results. Unfortunately, it seems the DECL_INITIAL (decl) = decl; hack wasn't used as the comment suggested only by dw2_force_const_mem, but also by asa

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

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 wrote: > >> > +int a(__attribute__((b((int)__builtin_inf()

[tail-merge, PR84956] Don't merge bbs with bb_has_abnormal_pred

Hi, This fixes a 6/7/8 regression, a P3 ICE in the tail-merge pass. Consider the test-case from the patch. When compiling at -O2, duplicates are found in tail-merge: ... find_duplicates: duplicate of find_duplicates: duplicate of ... So, tail-merge calls replace_block_by (bb7, bb6). Howev

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

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, line 56, function test05 As detailed in the PR, this happens because So

Re: [tail-merge, PR84956] Don't merge bbs with bb_has_abnormal_pred

On Thu, 22 Mar 2018, Tom de Vries wrote: > Hi, > > This fixes a 6/7/8 regression, a P3 ICE in the tail-merge pass. > > > Consider the test-case from the patch. > > When compiling at -O2, duplicates are found in tail-merge: > ... > find_duplicates: duplicate of > find_duplicates: duplicate o

Re: [PATCH] Fix up -fsanitize=address on -fsection-anchors targets (PR sanitizer/85018)

On Wed, Mar 21, 2018 at 09:41:11PM +0100, Jakub Jelinek wrote: > I've committed my last patch to unbreak aarch64 and powerpc* bootstrap > in a rush just after watching it passed bootstrap, not waiting for test > results. > Unfortunately, it seems the DECL_INITIAL (decl) = decl; hack wasn't used as

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

Hi, The new test pr83126.c requires pthread for compiling, this simple patch skips it for bare-metal toolchains. Test checked. Is it OK? Thanks, bin gcc/testsuite 2018-03-22 Bin Cheng * gcc.dg/graphite/pr83126.c: Require pthread for the test.diff --git a/gcc/testsuite/gcc.dg/graphi

Re: [PATCH AArch64]Fix test failure for pr84682-2.c

On Sat, Mar 17, 2018 at 8:54 AM, Richard Sandiford wrote: > Kyrill Tkachov writes: >> Hi Bin, >> >> On 16/03/18 11:42, Bin Cheng wrote: >>> Hi, >>> This simple patch fixes test case failure for pr84682-2.c by returning >>> false on wrong mode rtx in aarch64_classify_address, rather than assert.

[PATCH] PR 85025: libgcc/config/i386/shadow-stack-unwind.h is wrong

The incspp instruction from CET accepts only the value in the range of 0-255. The patch fixes the typo in the loop to handle this. I'm checking in the fix as obvious. Thanks, Igor PR target/85025 * config/i386/shadow-stack-unwind.h: Fix a typo, tmp => 255. Index: libgcc/config/i38

Re: [PATCH] PR 85025: libgcc/config/i386/shadow-stack-unwind.h is wrong

On Thu, Mar 22, 2018 at 4:11 AM, Tsimbalist, Igor V wrote: > The incspp instruction from CET accepts only the value in the range of 0-255. > The patch fixes the typo in the loop to handle this. > > I'm checking in the fix as obvious. > > Thanks, > Igor > >PR target/85025 >* config/

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

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, line 56, function test05

[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)

[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. -

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

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: [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: 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: [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: [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: [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: [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

[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: [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

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: [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

[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: [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

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: 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/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: [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/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 #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/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

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: [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: [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 #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: [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 #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 #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: [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: [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: [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: [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 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

[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: [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

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

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: [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: [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: [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: [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 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: [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: [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: [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: [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: [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: [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 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, 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: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: [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: [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: [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: [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] 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: [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] 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] [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: [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: [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: [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: [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: [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: [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

[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

[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

[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

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

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...")

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

[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: [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

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_

[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] 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

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: [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: [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: [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

[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

[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

  1   2   >