Re: [PATCH] nvptx: Cache stacks block for OpenMP kernel launch

On 2020/10/27 9:17 PM, Julian Brown wrote: And, in which context are cuStreamAddCallback registered callbacks run? E.g. if it is inside of asynchronous interrput, using locking in there might not be the best thing to do. The cuStreamAddCallback API is documented here: https://docs.nvidia.com

Re: [PATCH]AArch64 Fix overflow in memcopy expansion on aarch64.

Hi, On Mon, 26 Oct 2020 at 13:44, Richard Sandiford via Gcc-patches wrote: > > Tamar Christina writes: > > Hi Richard, > > > > The 10/26/2020 11:29, Richard Sandiford wrote: > >> Tamar Christina writes: > >> >/* We can't do anything smart if the amount to copy is not constant. > >> > */ >

Re: [r11-4427 Regression] FAIL: gfortran.dg/vect/pr83232.f90 -O scan-tree-dump-times slp1 "vectorizing stmts using SLP" 3 on Linux/x86_64

On Tue, 27 Oct 2020, sunil.k.pandey wrote: > On Linux/x86_64, > > 5af1e827bbb624eb28f80d2c5e0da46185af3708 is the first bad commit > commit 5af1e827bbb624eb28f80d2c5e0da46185af3708 > Author: Richard Biener > Date: Tue Oct 27 11:03:27 2020 +0100 > > Avoid uniform lane BB vectorization > >

Re: [patch, shared coarrays, committed] Make header use more consistent

Hi Nicolas, Thomas, are you planing to also rename the directory and library name from "nca" to "shared_caf" or the like? Regards, Andre On Tue, 27 Oct 2020 17:18:21 -0400 David Edelsohn via Fortran wrote: > The current COARRAYS branch correctly bootstraps on AIX. Thanks for > correct

Re: [PATCH 2/2] combine: Don't turn (mult (extend x) 2^n) into extract

On 27/10/2020 17:31, Segher Boessenkool wrote: > On Tue, Oct 27, 2020 at 10:35:59AM +, Alex Coplan wrote: > > On 26/10/2020 12:43, Segher Boessenkool wrote: > > > I do not like handling both mult and ashift in one case like this, it > > > complicates things for no good reason. Write it as two

PING [Patch] x86: Enable GCC support for Intel AVX-VNNI extension

Hongyu Wang 于2020年10月14日周三 上午11:27写道： > > Hi: > > This patch is about to support Intel AVX-VNNI instructions. > > AVX-VNNI is an equivalent to AVX512-VNNI with VEX encoding. The instructions > are same, but with extra {vex} prefix to distinguish from AVX512-VNNI > instructions in assembler. > >

[committed] wide-int: Fix up set_bit_large

On Tue, Oct 27, 2020 at 05:46:42PM +, Richard Sandiford via Gcc wrote: > >> and proceeds to call > >> > >> wide_int new_lb = wi::set_bit (r.lower_bound (0), 127) > >> > >> and creates the value: > >> > >> p new_lb > >> { = {val = {-65535, -1, 0}, len = 2, precision = 128}, > >> static is_sig

Re: [PING] [PATCH] S/390: Do not turn maybe-uninitialized warnings into errors

On Mon, Oct 05, 2020 at 02:02:57PM +0200, Stefan Schulze Frielinghaus via Gcc-patches wrote: > On Tue, Sep 22, 2020 at 02:59:30PM +0200, Andreas Krebbel wrote: > > On 15.09.20 17:02, Stefan Schulze Frielinghaus wrote: > > > Over the last couple of months quite a few warnings about uninitialized >

[committed] openmp: Implicitly discover declare target for variants of declare variant calls

Hi! This marks all variants of declare variant also declare target if the base functions are called directly in target regions or declare target functions. Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk. 2020-10-28 Jakub Jelinek * omp-offload.c (omp_declare

[PATCH] value-range: Give up on POLY_INT_CST ranges [PR97457]

This PR shows another problem with calculating value ranges for POLY_INT_CSTs. We have: ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]> where the VQ coefficient is unsigned but is effectively acting as a negative number. We wrongly give the POLY_INT_CST the range: [9, INT_MAX] and t

[committed] openmp: Parsing and some semantic analysis of OpenMP allocate clause

Hi! This patch adds parsing of OpenMP allocate clause, but still ignores it during OpenMP lowering where we should for privatized variables with allocate clause use the corresponding allocators rather than allocating them on the stack. Bootstrapped/regtested on x86_64-linux and i686-linux, commit

Re: libgo patch committed: Additional BSD-specific syscall wrappers

Hi Ian, > This libgo patch by Nikhil Benesch imports additional code from > upstream for handing system calls on BSD systems. This makes the > syscall package on NetBSD complete enough to compile the standard > library. Boostrapped and ran Go testsuite on x86_64-pc-linux-gnu. > Committed to mainl

Re: PING [PATCH] Enable GCC support for Intel Key Locker extension

Hi Uros, Thanks for the example. We've update the patterns with new expanders and predicates like vzeroall. Now the generated insn for "encodekey128u32" is like (insn 7 6 8 2 (parallel [ (set (reg:SI 84 [ ]) (unspec_volatile:SI [ (reg:SI 85)

Re: testsuite: Enable and adjust powerpc fold-vec-extract/insert testcases

git commit badeac77f552 changed expected number of addi instructions, causing these fails on powerpc-linux. gcc.target/powerpc/fold-vec-insert-int-p9.c: \\maddi\\M found 12 times FAIL: gcc.target/powerpc/fold-vec-insert-int-p9.c scan-assembler-times \\maddi\\M 8 gcc.target/powerpc/fold-vec-extrac

Re: [PATCH] SLP vectorize across PHI nodes

On Tue, 27 Oct 2020 at 13:18, Richard Biener wrote: > > This makes SLP discovery detect backedges by seeding the bst_map with > the node to be analyzed so it can be picked up from recursive calls. > This removes the need to discover backedges in a separate walk. > > This enables SLP build to handl

Re: [PATCH, 1/3, OpenMP] Target mapping changes for OpenMP 5.0, front-end parts

Hi Jakub, Thank you for the review. On 2020/10/13 9:01 PM, Jakub Jelinek wrote: gcc/c-family/ * c-common.h (c_omp_adjust_clauses): New declaration. * c-omp.c (c_omp_adjust_clauses): New function. Besides the naming, I wonder why is it done in a separate function and s

Re: [PATCH, 2/3, OpenMP] Target mapping changes for OpenMP 5.0, middle-end parts and compiler testcases

On 2020/10/13 9:31 PM, Jakub Jelinek wrote: +/* Implement OpenMP 5.x map ordering rules for target directives. There are + several rules, and with some level of ambiguity, hopefully we can at least + collect the complexity here in one place. */ + +static void +omp_target_reorder_clauses (tre

Re: [PATCH, 3/3, OpenMP] Target mapping changes for OpenMP 5.0, libgomp parts [resend]

On 2020/9/1 9:37 PM, Chung-Lin Tang wrote: his patch is the changes to libgomp and testcases. There is now (again) a need to indicate OpenACC/OpenMP and an 'enter data' style directive, so the associated changes to 'enum gomp_map_vars_kind'. There is a slight change in the logic of gomp_attach_

Re: [PATCH] tree-optimization/97428 - split SLP groups for loop vectorization

Richard Biener writes: > On Tue, 27 Oct 2020, Richard Sandiford wrote: > >> Sorry for the very late comment (was out last week)? >> >> Richard Biener writes: >> > This enables SLP store group splitting also for loop vectorization. >> > For the existing testcase gcc.dg/vect/vect-complex-5.c this

Re: [PATCH] SLP vectorize across PHI nodes

On Wed, 28 Oct 2020 at 11:27, Christophe Lyon wrote: > > On Tue, 27 Oct 2020 at 13:18, Richard Biener wrote: > > > > This makes SLP discovery detect backedges by seeding the bst_map with > > the node to be analyzed so it can be picked up from recursive calls. > > This removes the need to discover

Re: [RS6000] Do not define builtins that overload disabled builtins

commit 25ffd3d34e means we no longer define an overloaded __builtin_byte_in_set for -m32, so the more informative "__builtin_byte_in_set is not supported in this compiler configuration" is not reported. Regression tested powerpc64-linux biarch. OK? PR bootstrap/92661 * gcc.target

[RS6000] float128-type-2.c unsupported

>From e7ce33cef478a826a2fe4e110b43b49586ef2438 Mon Sep 17 00:00:00 2001 From: Alan Modra Date: Wed, 28 Oct 2020 15:57:57 +1030 Subject: I noticed this test is unsupported on power10 when looking through test logs. There seems no reason why that should be the case, ie. likely the target test was

[RS6000] Don't be too clever with dg-do run and dg-do compile

Otherwise some versions of dejagnu go ahead and run the vsx tests below when they should not. To best cope with older dejagnu, put "run" before "compile", the idea being that if the second dg-do always wins then that won't cause fails. The altivec tests also need -save-temps for the scan-assemble

[FYI,Ada,PR97504] riscv needs wraplf for aux_long_long_float too

riscv is another platform on which GNAT maps Long_Long_Float to double rather than long double, so we have to explicitly avoid the long double intrinsics. for gcc/ada/ChangeLog PR ada/97504 * Makefile.rtl (LIBGNAT_TARGET_PAIRS> : Use wraplf version of Aux_Long_Long_Flo

[PATCH V4] aarch64: Add bfloat16 vldN_lane_bf16 + vldNq_lane_bf16 intrisics

Richard Sandiford writes: [...] >> Hi Richard, >> >> I had a look a little more closely and just moving the #undefs to the >> end of the file is not viable as these macros are: defined, undefined, >> redefined and finally undefined to generate the intrinsic and theier 'q' >> variants. >> >> In t

Re: [PATCH 2/2] combine: Don't turn (mult (extend x) 2^n) into extract

On 28/10/2020 09:09, Alex Coplan via Gcc-patches wrote: > On 27/10/2020 17:31, Segher Boessenkool wrote: > > On Tue, Oct 27, 2020 at 10:35:59AM +, Alex Coplan wrote: > > > On 26/10/2020 12:43, Segher Boessenkool wrote: > > > > I do not like handling both mult and ashift in one case like this, i

Re: [PATCH V4] aarch64: Add bfloat16 vldN_lane_bf16 + vldNq_lane_bf16 intrisics

Andrea Corallo writes: > Richard Sandiford writes: > > [...] > >>> Hi Richard, >>> >>> I had a look a little more closely and just moving the #undefs to the >>> end of the file is not viable as these macros are: defined, undefined, >>> redefined and finally undefined to generate the intrinsic and

[PATCH V3] aarch64: Add vstN_lane_bf16 + vstNq_lane_bf16 intrinsics

Andrea Corallo via Gcc-patches writes: > Hi all, > > Second version of the patch here implementing the bfloat16_t neon > related store intrinsics: vst2_lane_bf16, vst2q_lane_bf16, > vst3_lane_bf16, vst3q_lane_bf16 vst4_lane_bf16, vst4q_lane_bf16. > > Please see refer to: > ACLE

Re: [PATCH V4] aarch64: Add bfloat16 vldN_lane_bf16 + vldNq_lane_bf16 intrisics

Richard Sandiford writes: [...] > OK for both. Thanks for doing this. > > Richard Welcome, installed into master as 44e570d9fb0. Will follow-up for the backport. Thanks! Andrea

Re: [PATCH V3] aarch64: Add vstN_lane_bf16 + vstNq_lane_bf16 intrinsics

Andrea Corallo via Gcc-patches writes: [...] > Hi all, > > third version of this patch following the suggestions got for its sister > patch > > Regtested and bootstrapped. > > Okay for trunk and 10? > > Thanks! > > Andrea Ins

Re: [PATCH] nvptx: Cache stacks block for OpenMP kernel launch

On Wed, 28 Oct 2020 15:25:56 +0800 Chung-Lin Tang wrote: > On 2020/10/27 9:17 PM, Julian Brown wrote: > >> And, in which context are cuStreamAddCallback registered callbacks > >> run? E.g. if it is inside of asynchronous interrput, using locking > >> in there might not be the best thing to do.

Re: [PATCH V3] aarch64: Add vstN_lane_bf16 + vstNq_lane_bf16 intrinsics

Andrea Corallo writes: > Andrea Corallo via Gcc-patches writes: > >> Hi all, >> >> Second version of the patch here implementing the bfloat16_t neon >> related store intrinsics: vst2_lane_bf16, vst2q_lane_bf16, >> vst3_lane_bf16, vst3q_lane_bf16 vst4_lane_bf16, vst4q_lane_bf16. >> >> Please see r

Re: PING [PATCH] Enable GCC support for Intel Key Locker extension

On Wed, Oct 28, 2020 at 10:54 AM Hongyu Wang wrote: > > Hi Uros, > > Thanks for the example. We've update the patterns with new expanders > and predicates like vzeroall. > Now the generated insn for "encodekey128u32" is like > > (insn 7 6 8 2 (parallel [ > (set (reg:SI 84 [ ]) >

[committed] libstdc++: Make std::span layout-compatible with struct iovec [PR 95609]

This change reorders the data members of std::span so that span is layout-compatible with common implementations of struct iovec. This will allow span to be used directly in places that use a struct iovec to do scatter-gather I/O. It's important to note that POSIX doesn't specify the order of memb

[committed] libstdc++: Fix name clash with _Cosh in QNX headers [PR 95592]

This replaces unqualified names like _Cosh with struct std::_Cosh to ensure there is no ambiguity with other entities with the same name. libstdc++-v3/ChangeLog: PR libstdc++/95592 * include/bits/valarray_after.h (_DEFINE_EXPR_UNARY_OPERATOR) (_DEFINE_EXPR_BINARY_OPERATOR,

Re: Avoid typeless storage in trailing wide ints

On Tue, Oct 27, 2020 at 11:49 PM Jan Hubicka wrote: > > Hi, > this patch avoid typeless storage in trailing_wide_ints. This improves > TBAA disambiguation rate on cc1plus by 7%. > > Bootstrapped/regtested x86_64-linux, OK? OK. I guess if uint8_t would be a separate type from unsigned char that

Re: move sincos after pre

On Wed, Oct 28, 2020 at 4:18 AM Alexandre Oliva wrote: > > On Oct 27, 2020, Richard Biener wrote: > > > For trapping math SRC may be a constant? Better be safe > > and guard against TREE_CODE (src) != SSA_NAME. > > *nod* > > > You also want to guard against SSA_NAME_OCCURS_IN_ABNORMAL_PHI (src)

Re: [PATCH] value-range: Give up on POLY_INT_CST ranges [PR97457]

On Wed, Oct 28, 2020 at 10:44 AM Richard Sandiford via Gcc-patches wrote: > > This PR shows another problem with calculating value ranges for > POLY_INT_CSTs. We have: > > ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]> > > where the VQ coefficient is unsigned but is effectively acting >

[PATCH] Change the way we split stores in BB vectorization

The following fixes missed optimizations due to the strange way we split stores in BB vectorization. The solution is to split at the failure boundary and not re-align that to the initial piece chosen vector size. Also re-analyze any larger matching rest. Bootstrapped / tested on x86_64-unknown-l

[PATCH] dump reason for throwing away SLP instance

This adds dumping to vect_slp_analyze_node_alignment when it fails an SLP instance due to shared vector type conflicts. Bootstrapped / tested on x86_64-unknwon-linux-gnu, pushed. 2020-10-28 Richard Biener * tree-vect-data-refs.c (vect_slp_analyze_node_alignment): Dump when vec

Re: [PATCH] value-range: Give up on POLY_INT_CST ranges [PR97457]

On 10/28/20 5:43 AM, Richard Sandiford via Gcc-patches wrote: This PR shows another problem with calculating value ranges for POLY_INT_CSTs. We have: ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]> where the VQ coefficient is unsigned but is effectively acting as a negative number. W

[committed] libstdc++: Add comment to nothrow new explaining catch (...)

The decision to not rethrow a __forced_unwind exception is deliberate, so add a comment explaining it. libstdc++-v3/ChangeLog: * libsupc++/new_opnt.cc (new): Add comment about forced unwind exceptions. Tested powerpc64le-linux. Committed to trunk. commit c227d96feb0030d63efad352

Re: This is my patch for fstream to fix the performance issue on Windows.

On 02/10/20 23:04 +0100, Jonathan Wakely wrote: On 01/10/20 03:29 +, sotrdg sotrdg via Libstdc++ wrote: From fb8d644a4c315058af141a3e84fcc083d665c8b9 Mon Sep 17 00:00:00 2001 From: ejsvifq_mabmip Date: Wed, 30 Sep 2020 23:26:47 -0400 Subject: [PATCH] Fix a long term performance issue of fst

Re: testsuite: Enable and adjust powerpc fold-vec-extract/insert testcases

On Wed, Oct 28, 2020 at 6:26 AM Alan Modra wrote: > > git commit badeac77f552 changed expected number of addi instructions, > causing these fails on powerpc-linux. > > gcc.target/powerpc/fold-vec-insert-int-p9.c: \\maddi\\M found 12 times > FAIL: gcc.target/powerpc/fold-vec-insert-int-p9.c scan-as

Re: [PATCH] SLP vectorize across PHI nodes

On Wed, 28 Oct 2020, Christophe Lyon wrote: > On Wed, 28 Oct 2020 at 11:27, Christophe Lyon > wrote: > > > > On Tue, 27 Oct 2020 at 13:18, Richard Biener wrote: > > > > > > This makes SLP discovery detect backedges by seeding the bst_map with > > > the node to be analyzed so it can be picked up

Re: [RS6000] float128-type-2.c unsupported

On Wed, Oct 28, 2020 at 6:48 AM Alan Modra wrote: > > From e7ce33cef478a826a2fe4e110b43b49586ef2438 Mon Sep 17 00:00:00 2001 > From: Alan Modra > Date: Wed, 28 Oct 2020 15:57:57 +1030 > Subject: > > I noticed this test is unsupported on power10 when looking through > test logs. There seems no re

[PATCH] vect: Fix load costs for SLP permutes

For the following test case (compiled with load/store lanes disabled locally): void f (uint32_t *restrict x, uint8_t *restrict y, int n) { for (int i = 0; i < n; ++i) { x[i * 2] = x[i * 2] + y[i * 2]; x[i * 2 + 1] = x[i * 2 + 1] + y[i * 2]; } } we have a re

[PATCH] Fix gcc.dg/vect/bb-slp-5[89].c

I forgot a vect_double check. Testing in progress. 2020-10-28 Richard Biener * gcc.dg/vect/bb-slp-58.c: Require vect_double. * gcc.dg/vect/bb-slp-59.c: Likewise. --- gcc/testsuite/gcc.dg/vect/bb-slp-58.c | 1 + gcc/testsuite/gcc.dg/vect/bb-slp-59.c | 1 + 2 files changed, 2 i

Re: [PATCH] vect: Fix load costs for SLP permutes

On Wed, Oct 28, 2020 at 2:39 PM Richard Sandiford via Gcc-patches wrote: > > For the following test case (compiled with load/store lanes > disabled locally): > > void > f (uint32_t *restrict x, uint8_t *restrict y, int n) > { > for (int i = 0; i < n; ++i) > { > x[i * 2] = x

[PATCH] tree-optimization/97615 - avoid creating externals from patterns

The previous change missed to check for patterns again, the following corrects that. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. 2020-10-28 Richard Biener PR tree-optimization/97615 * tree-vect-slp.c (vect_build_slp_tree_2): Do not build an external

[PATCH] Fix iteration over loads in SLP optimize

I've made a typo when refactoring the iteration over all loads in the SLP graph. Fixed. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. 2020-10-28 Richard Biener * tree-vect-slp.c (vect_optimize_slp): Fix iteration over all loads. --- gcc/tree-vect-slp.c | 2 +

RE: [PATCH 1/2] Enable OpenMP efficient performance profiling via ITT tracing

Hi Jakub, Thanks for your comments! Please see my reply below. > > In order to optimize OpenMP workloads, it is quite important to have a > dedicated performance analysis tool familiar with the OpenMP runtime > specifics. The typical OpenMP performance issues are: > > - Not all the performance-cr

Re: [PATCH 1/X] libsanitizer: Tie the hwasan library into our build system

Hi Richard, I've done most of the updates you suggested, but have a few questions to ensure I have the right end of the stick before making the remaining changes. There are also a few clarifications I'd like to make where I hadn't explained the rationale for certain bits of the original code, and

[patch] vxworks: Fix conditional inclusion guard in gthr-vxworks-thread.c

This change fixes the name of the macro used to condition the inclusion of an actual implementation of some of the gthread support services for VxWorks, to agree with the side defining that macro based on tests against the targetted VxWorks version major. Tested by verifying the desired effect of

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

Hi, Richard, In order to be consistent with other flags in flag-types.h, for example, “sanitize_code”, I didn’t use namespace, instead making the name more specific as following: /* Different settings for zeroing subset of registers. */ enum zero_regs_flags { ZERO_REGS_UNSET = 0, ZERO_REGS

[PATCH] Ignore ignored operands in vect_get_and_check_slp_defs

This passes down skip_args to vect_get_and_check_slp_defs to skip ignored ops there, too and not fail SLP discovery. This fixes gcc.target/aarch64/sve/reduc_strict_5.c Bootstrap & regtest running on x86_64-unknown-linux-gnu. 2020-10-28 Richard Biener * tree-vect-slp.c (vect_get_and_c

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

Qing Zhao writes: > Hi, Richard, > > In order to be consistent with other flags in flag-types.h, for example, > “sanitize_code”, > I didn’t use namespace, instead making the name more specific as following: > > /* Different settings for zeroing subset of registers. */ > enum zero_regs_flags { >

[PATCH] openmp: Implicit 'declare target' for C++ static initializers

Hello OpenMP 5.0 has a new feature for implicitly marking variables and functions that are referenced in the initializers of static variables and functions that are already marked 'declare target'. Support was added in the commit 'openmp: Implement discovery of implicit declare target to claus

[patch] vxworks: Fix the logic conditioning VX_ENTER/LEAVE_TLS_DTOR

This change fixes a basic #if/#ifdef confusion exposed by the wider range of testing we’re running for the forthcoming introduction of additional support for VxWorks 7r2, which comes together with a few organizational changes to keep supporting older versions. Committing as obvious after checking

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

Okay, I will change it to namespace. Qing > On Oct 28, 2020, at 9:19 AM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >> Hi, Richard, >> >> In order to be consistent with other flags in flag-types.h, for example, >> “sanitize_code”, >> I didn’t use namespace

Re: [PING] [PATCH] S/390: Do not turn maybe-uninitialized warnings into errors

On 10/28/20 3:38 AM, Stefan Schulze Frielinghaus via Gcc-patches wrote: > On Mon, Oct 05, 2020 at 02:02:57PM +0200, Stefan Schulze Frielinghaus via > Gcc-patches wrote: >> On Tue, Sep 22, 2020 at 02:59:30PM +0200, Andreas Krebbel wrote: >>> On 15.09.20 17:02, Stefan Schulze Frielinghaus wrote: >

Re: [RS6000] Do not define builtins that overload disabled builtins

On Wed, Oct 28, 2020 at 6:46 AM Alan Modra wrote: > > commit 25ffd3d34e means we no longer define an overloaded > __builtin_byte_in_set for -m32, so the more informative > "__builtin_byte_in_set is not supported in this compiler > configuration" is not reported. > > Regression tested powerpc64-lin

Re: [PATCH 1/X] libsanitizer: Tie the hwasan library into our build system

I have the feeling that I've picked the most awkward of each binary choice here, sorry… Matthew Malcomson writes: > - Parametrising the tag size is pretty easy towards less bits, the current > code > handles this quite nicely using HWASAN_TAG_SIZE and in fact I've already done > that for a WIP b

[PATCH] libstdc++: Fix arithmetic bug in year_month_weekday conversion [PR96713]

The conversion function year_month_weekday::operator sys_days computes the number of days to offset from the first weekday of the month with: days{(index()-1)*7} ^ type 'unsigned' We'd like the above to yield -7d when index() is 0u, but our 'days' alias is based on long instea

Re: [RS6000] Don't be too clever with dg-do run and dg-do compile

On Wed, 2020-10-28 at 21:20 +1030, Alan Modra via Gcc-patches wrote: > Otherwise some versions of dejagnu go ahead and run the vsx tests > below when they should not. To best cope with older dejagnu, put > "run" before "compile", the idea being that if the second dg-do always > wins then that won'

[PATCH v4] builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

I am repeating the "changelog" from v3 here because v4 is just one bugfix. I also tested on BE systems for v4. Changes since v3[1]: - Fixed fegetround bug on powerpc64 (big endian) that Segher spotted; Changes since v2[2]: - Added documentation for the new optabs; - Remove use of non po

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

Hi, Richard, I changed the “enum” to “namespace”. There is no issue for C++ compilation. However, flag-types.h header file is also included by C modules and compiled with gcc, then I got a lot of following compilation errors: make[4]: Entering directory '/home/qinzhao/Work/x86-build/x86_64-p

c++: Refactor push_template_decl

Sadly I need to wander into push_template_decl again. But here's a piece of RAII goodness first. gcc/cp/ * pt.c (push_template_decl): Refactor for some RAII. pushing to trunk nathan -- Nathan Sidwell diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c index 3c0f2546489..0d2946fd7c4 100644

Re: [PATCH] libstdc++: Fix arithmetic bug in year_month_weekday conversion [PR96713]

On Wed, 28 Oct 2020, Patrick Palka wrote: > The conversion function year_month_weekday::operator sys_days computes > the number of days to offset from the first weekday of the month with: > > days{(index()-1)*7} > ^ type 'unsigned' > > We'd like the above to yield -7d when in

[PATCH] dump when SLP analysis fails due to shared vectype mismatch

This adds another one. Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed. 2020-10-28 Richard Biener * tree-vect-slp.c (vect_slp_analyze_node_operations_1): Dump when shared vectype update fails. --- gcc/tree-vect-slp.c | 8 +++- 1 file changed, 7 insertions(+), 1

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

Qing Zhao writes: > Hi, Richard, > > I changed the “enum” to “namespace”. > > There is no issue for C++ compilation. However, flag-types.h header file is > also included by C modules and compiled with gcc, then I got a lot of > following compilation errors: > > make[4]: Entering directory > '/

Re: deprecations in OpenMP 5.0

Hello I found this almost two-year old thread while looking for how the OpenMP 5.0 deprecations were to be handled. E.g. if somebody tries hard to write portable OpenMP code and has: omp_lock_t lock; #if __OPENMP__ >= 201811L omp_init_lock_with_hint (&lock, omp_sync_hint_contended); #

Re: Materialize clones on demand

> > > > However main problem is > > > > cfg.c:202 (connect_src) 5745k: 0.2% > > > > 271M: 1.9% 1754k: 0.0% 1132k: 0.2% 7026k > > > > cfg.c:212 (connect_dest) 6307k: 0.2% > > > > 281M: 2.0%10129k: 0.2%

Re: [PATCH] libstdc++: Fix arithmetic bug in year_month_weekday conversion [PR96713]

On 28/10/20 11:04 -0400, Patrick Palka via Libstdc++ wrote: The conversion function year_month_weekday::operator sys_days computes the number of days to offset from the first weekday of the month with: days{(index()-1)*7} ^ type 'unsigned' We'd like the above to yield -7d when

Re: [PATCH] libstdc++: Fix arithmetic bug in year_month_weekday conversion [PR96713]

On 28/10/20 11:21 -0400, Patrick Palka via Libstdc++ wrote: On Wed, 28 Oct 2020, Patrick Palka wrote: The conversion function year_month_weekday::operator sys_days computes the number of days to offset from the first weekday of the month with: days{(index()-1)*7} ^ type 'un

Re: deprecations in OpenMP 5.0

On Wed, Oct 28, 2020 at 03:41:25PM +, Kwok Cheung Yeung wrote: > I found this almost two-year old thread while looking for how the OpenMP 5.0 > deprecations were to be handled. > > > E.g. if somebody tries hard to write portable OpenMP code and has: > > omp_lock_t lock; > > #if __OPENMP__

Re: [PATCH] libstdc++: Fix arithmetic bug in year_month_weekday conversion [PR96713]

On Wed, 28 Oct 2020, Jonathan Wakely wrote: > On 28/10/20 11:21 -0400, Patrick Palka via Libstdc++ wrote: > > On Wed, 28 Oct 2020, Patrick Palka wrote: > > > > > The conversion function year_month_weekday::operator sys_days computes > > > the number of days to offset from the first weekday of the

Re: [PATCH v4] builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

On Wed, Oct 28, 2020 at 12:09:54PM -0300, Raoni Fassina Firmino wrote: > * builtins.c (expand_builtin_fegetround): New function. > (expand_builtin_feclear_feraise_except): New function. > (expand_builtin): Add cases for BUILT_IN_FEGETROUND, > BUILT_IN_FECLEAREXCEPT a

Re: [patch, shared coarrays, committed] Make header use more consistent

Hi Andre, I'll make another pass after I'm done implementing stat & errmsg to remove any reference to native coarrays I find. Kind regards, Nicolas On 28/10/2020 09:25, Andre Vehreschild wrote: Hi Nicolas, Thomas, are you planing to also rename the directory and library name from "nca" t

Re: [RS6000] Don't be too clever with dg-do run and dg-do compile

On Wed, Oct 28, 2020 at 10:05:14AM -0500, will schmidt wrote: > On Wed, 2020-10-28 at 21:20 +1030, Alan Modra via Gcc-patches wrote: > > Otherwise some versions of dejagnu go ahead and run the vsx tests > > below when they should not. To best cope with older dejagnu, put > > "run" before "compile"

Re: [RS6000] Don't be too clever with dg-do run and dg-do compile

On Wed, Oct 28, 2020 at 09:20:56PM +1030, Alan Modra wrote: > Otherwise some versions of dejagnu go ahead and run the vsx tests > below when they should not. To best cope with older dejagnu, put > "run" before "compile", the idea being that if the second dg-do always > wins then that won't cause f

Re: [PING] [PATCH] S/390: Do not turn maybe-uninitialized warnings into errors

On Wed, Oct 28, 2020 at 08:39:41AM -0600, Jeff Law wrote: > > On 10/28/20 3:38 AM, Stefan Schulze Frielinghaus via Gcc-patches wrote: > > On Mon, Oct 05, 2020 at 02:02:57PM +0200, Stefan Schulze Frielinghaus via > > Gcc-patches wrote: > >> On Tue, Sep 22, 2020 at 02:59:30PM +0200, Andreas Krebbel

Re: [PING] [PATCH] S/390: Do not turn maybe-uninitialized warnings into errors

On 10/28/20 11:29 AM, Stefan Schulze Frielinghaus wrote: > On Wed, Oct 28, 2020 at 08:39:41AM -0600, Jeff Law wrote: >> On 10/28/20 3:38 AM, Stefan Schulze Frielinghaus via Gcc-patches wrote: >>> On Mon, Oct 05, 2020 at 02:02:57PM +0200, Stefan Schulze Frielinghaus via >>> Gcc-patches wrote: >>>

Re: [PATCH] arm: Fix multiple inheritance thunks for thumb-1 with -mpure-code

On 27/10/2020 15:42, Richard Earnshaw via Gcc-patches wrote: > On 26/10/2020 10:52, Christophe Lyon via Gcc-patches wrote: >> On Thu, 22 Oct 2020 at 17:22, Richard Earnshaw >> wrote: >>> >>> On 22/10/2020 09:45, Christophe Lyon via Gcc-patches wrote: On Wed, 21 Oct 2020 at 19:36, Richard Earn

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

On Wed, Oct 28, 2020 at 01:26:53AM -0400, Jason Merrill via Gcc-patches wrote: > On 10/24/20 7:40 PM, Marek Polacek wrote: > > On Fri, Oct 23, 2020 at 09:33:38PM -0400, Jason Merrill via Gcc-patches > > wrote: > > > On 10/23/20 3:01 PM, Marek Polacek wrote: > > > > This patch implements the -Wvexi

Re: [PATCH v2] c++: Prevent warnings for value-dependent exprs [PR96742]

On Tue, Oct 27, 2020 at 01:36:30PM -0400, Jason Merrill wrote: > On 10/24/20 6:52 PM, Marek Polacek wrote: > > Here, in r11-155, I changed the call to uses_template_parms to > > type_dependent_expression_p_push to avoid a crash in C++98 in > > value_dependent_expression_p on a non-constant expressi

[PATCH] c++: Deprecate arithmetic convs on different enums [PR97573]

I noticed that C++20 P1120R0 deprecated certain arithmetic conversions as outlined in [depr.arith.conv.enum], but we don't warn about them. In particular, "If one operand is of enumeration type and the other operand is of a different enumeration type or a floating-point type, this behavior is depr

[PATCH] c++: GCC accepts junk before fold-expression [PR86773]

Here we accept a bogus expression before a left fold: Recall that a fold expression looks like: fold-expression: ( cast-expression fold-operator ... ) ( ... fold-operator cast-expression ) ( cast-expression fold-operator ... fold-operator cast-expression ) but here we have ( ca

[PATCH] c++: Implement CWG 625: Use of auto as template-arg [PR97479]

This patch implements CWG 625 which prohibits using auto in a template argument. A few tests used this construction. We could perhaps only give an error in C++20, but not in C++17 with -fconcepts. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: DR 625

Re: [PATCH] arm: Fix multiple inheritance thunks for thumb-1 with -mpure-code

On Wed, 28 Oct 2020 at 18:44, Richard Earnshaw wrote: > > On 27/10/2020 15:42, Richard Earnshaw via Gcc-patches wrote: > > On 26/10/2020 10:52, Christophe Lyon via Gcc-patches wrote: > >> On Thu, 22 Oct 2020 at 17:22, Richard Earnshaw > >> wrote: > >>> > >>> On 22/10/2020 09:45, Christophe Lyon v

Re: [PATCH] c++: GCC accepts junk before fold-expression [PR86773]

On 10/28/20 2:02 PM, Marek Polacek wrote: Here we accept a bogus expression before a left fold: Recall that a fold expression looks like: fold-expression: ( cast-expression fold-operator ... ) ( ... fold-operator cast-expression ) ( cast-expression fold-operator ... fold-operat

Re: [PATCH] c++: Implement CWG 625: Use of auto as template-arg [PR97479]

On 10/28/20 2:02 PM, Marek Polacek wrote: This patch implements CWG 625 which prohibits using auto in a template argument. A few tests used this construction. We could perhaps only give an error in C++20, but not in C++17 with -fconcepts. We should not give an error with -fconcepts-ts, this w

Re: [PATCH] c++: Deprecate arithmetic convs on different enums [PR97573]

On 10/28/20 2:01 PM, Marek Polacek wrote: I noticed that C++20 P1120R0 deprecated certain arithmetic conversions as outlined in [depr.arith.conv.enum], but we don't warn about them. In particular, "If one operand is of enumeration type and the other operand is of a different enumeration type or

Re: [RS6000] float128-type-2.c unsupported

On Wed, Oct 28, 2020 at 09:18:35PM +1030, Alan Modra wrote: > >From e7ce33cef478a826a2fe4e110b43b49586ef2438 Mon Sep 17 00:00:00 2001 > From: Alan Modra > Date: Wed, 28 Oct 2020 15:57:57 +1030 > Subject: > > I noticed this test is unsupported on power10 when looking through > test logs. There s

c++: Make OMP UDR DECL_LOCAL_DECL_P earlier

I discovered that we were pushing an OMP UDR in a template before setting DECL_LOCAL_DECL. This caused the template machinery to give it some template info. It doesn't need that, and this changes the parser to set it earlier. We have to adjust instantiate_body to not try and access such a func

Re: [PATCH v2] c++: Prevent warnings for value-dependent exprs [PR96742]

On 10/28/20 2:00 PM, Marek Polacek wrote: On Tue, Oct 27, 2020 at 01:36:30PM -0400, Jason Merrill wrote: On 10/24/20 6:52 PM, Marek Polacek wrote: Here, in r11-155, I changed the call to uses_template_parms to type_dependent_expression_p_push to avoid a crash in C++98 in value_dependent_express

Re: [PATCH][PR target/97540] Don't extract memory from operand for normal memory constraint.

Hongtao Liu writes: > On Tue, Oct 27, 2020 at 7:13 PM Richard Sandiford > wrote: >> >> Hongtao Liu via Gcc-patches writes: >> > Hi: >> > For inline asm, there could be an operand like (not (mem:)), it's >> > not a valid operand for normal memory constraint. >> > Bootstrap is ok, regression t

c: Allow omitted parameter names for C2x

C2x allows parameter names to be omitted in function definitions, as in C++; add support for this feature. As with other features that only result in previously rejected code being accepted, this feature is now accepted as an extension for previous standard versions, with a pedwarn-if-pedantic tha

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

On 10/28/20 1:58 PM, Marek Polacek wrote: On Wed, Oct 28, 2020 at 01:26:53AM -0400, Jason Merrill via Gcc-patches wrote: On 10/24/20 7:40 PM, Marek Polacek wrote: On Fri, Oct 23, 2020 at 09:33:38PM -0400, Jason Merrill via Gcc-patches wrote: On 10/23/20 3:01 PM, Marek Polacek wrote: This patc

[committed][PATCH]AArch64 Skip test for pr97535 on ILP32 since it can't express the range.

Hi All, I am excluding the test from ILP32 since the goal of the test is to test truncations of large numbers above INT_MAX. Regtested on aarch64-none-linux-gnu and no issues. Committed under the obvious rule. Thanks, Tamar gcc/testsuite/ChangeLog: PR target/97535 * gcc.target

  1   2   >