Re: [PATCH] c++: Partially implement P1042R1: __VA_OPT__ wording clarifications [PR92319]

On 1/31/20 7:14 PM, Jakub Jelinek wrote: Hi! I've noticed we claim in cxx-status.html that we implement P1042R1, but it seems we don't implement any of the changes from there. The following patch implements just the change that __VA_OPT__ determines whether to expand to nothing or the enclosed t

Re: [PATCH]Several intrinsic macros lack a closing parenthesis[PR93274]

On Fri, Feb 14, 2020 at 7:03 AM Hongtao Liu wrote: > > On Thu, Feb 13, 2020 at 5:31 PM Hongtao Liu wrote: > > > > On Thu, Feb 13, 2020 at 5:12 PM Uros Bizjak wrote: > > > > > > On Thu, Feb 13, 2020 at 9:53 AM Jakub Jelinek wrote: > > > > > > > > On Thu, Feb 13, 2020 at 09:39:05AM +0100, Uros Bi

Re: [PATCH, rs6000]: mark clobber for registers changed by untpyed_call

Segher Boessenkool writes: > On Sat, Feb 08, 2020 at 10:17:42AM -0600, Segher Boessenkool wrote: >> And we do not know which of the register will be used for the return, in >> untyped_call (only untyped-return knows). But we can add clobbers of all >> registers that *might* be used for the retur

Re: [PATCH]Several intrinsic macros lack a closing parenthesis[PR93274]

On Thu, Feb 13, 2020 at 5:31 PM Hongtao Liu wrote: > > On Thu, Feb 13, 2020 at 5:12 PM Uros Bizjak wrote: > > > > On Thu, Feb 13, 2020 at 9:53 AM Jakub Jelinek wrote: > > > > > > On Thu, Feb 13, 2020 at 09:39:05AM +0100, Uros Bizjak wrote: > > > > > Changelog > > > > > gcc/ > > > > >* co

Re: [PATCH 2/3] libstdc++: Implement C++20 constrained algorithms

Thanks for those additional information. I still think that the same way we rely on STL algos for push_heap/pop_heap/... we should do it for copy/move/... from stl_algobase.h for RAI. In fact range algos that are already trying to call C functions should just try to call the STL counterparts

[PATCH] testsuite/strlenopt-81.c: Add target limitation.

- strlenopt-81.c has same limitation as strlenopt-80.c, this optimization only work when memcpy expand into load/store. ChangeLog gcc/testsuite Kito Cheng * gcc.dg/strlenopt-81.c: Add target limitation. --- gcc/testsuite/gcc.dg/strlenopt-81.c | 6 +- 1 file changed, 5 inserti

[PATCH] aarch64: Allow -mcpu=generic -march=armv8.5-a

From: Andrew Pinski Right if someone supplies a -mcpu= option and then overrides that option with -march=*, we get a warning when they conflict. What we need is a generic cpu for each arch level but that is not that useful because the only difference would be the arch level. The best option is to

Re: [PATCH] tree-optimization/93661 properly guard tree_to_poly_int64

On Tue, 11 Feb 2020, Richard Biener wrote: > Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed. > diff --git a/gcc/testsuite/gcc.dg/pr93661.c b/gcc/testsuite/gcc.dg/pr93661.c > new file mode 100644 > index 000..e311ba545c4 > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/pr93661.c > @@

[PATCH] rs6000: fixinc: Skip machine_name fix for powerpc*-*-linux*

From: Matheus Castanho Some system headers can be broken by the machine_name fix performed by GCC during the fixincludes step. According to the comment in fixincludes/fixinc.h:130 : On some platforms, machine_name doesn't work properly and breaks some of the header files. Since everything

Re: [PATCH] configure: Re-disable building cross-gdbserver

On Wed, 12 Feb 2020, Pedro Alves wrote: > > That's actually quite similar to what I considered first, before I > > changed my mind. Whatever. > > Doing it in gdbserver/ has the advantage that it stays under gdbserver's > control, so it doesn't need syncing code with the gcc tree. I know of at

Re: [PATCH v2] c++: Fix ICE with template codes in check_narrowing [PR91465]

On 2/11/20 5:06 PM, Marek Polacek wrote: On Sun, Feb 09, 2020 at 01:51:13PM +0100, Jason Merrill wrote: On 2/6/20 7:30 PM, Marek Polacek wrote: In ed4f2c001a883b2456fc607a33f1c59f9c4ee65d I changed the call to fold_non_dependent_expr in check_narrowing to maybe_constant_value. That was the wron

Re: [PATCH] c++: Fix hashing and testing for equality of ATOMIC_CONST_EXPRs

On Fri, 14 Feb 2020, Jason Merrill wrote: > On 2/12/20 5:15 PM, Patrick Palka wrote: > > Two equal atomic constraint expressions do not necessarily share the same > > tree, > > so we can't assume that two ATOMIC_CONST_EXPRs are equal if and only if they > > point to the same tree. > > This is inc

Re: [PING^7][PATCH 0/4] Fix library testsuite compilation for build sysroot

On Sun, 26 Jan 2020, Jeff Law wrote: > > Ping for the build system parts of: > > > > > > > OK. Sorry for the terrible slowness on this kit. No worries, completely understood w

[PATCH v2 4/4] libgomp/test: Remove a build sysroot fix regression

Fix a problem with commit c8e759b4215b ("libgomp/test: Fix compilation for build sysroot") that caused a regression in some standalone test environments where testsuite/libgomp-test-support.exp is used, but the compiler is expected to be determined by `[find_gcc]', and use the `--tool_exec' opt

[PATCH v2 1/4] libatomic/test: Fix compilation for build sysroot

Fix a problem with the libatomic testsuite using a method to determine the compiler to use resulting in the tool being different from one the library has been built with, and causing a catastrophic failure from the lack of a suitable `--sysroot=' option where the `--with-build-sysroot=' configu

[PATCH v2 0/4] Fix library testsuite compilation for build sysroot

Hi, This is v2 of patch series, originally posted here: mea

[PATCH v2 3/4] libgo/test: Complement compilation fix for build sysroot

Complement commit b72813a68c94 ("libgo: fix DejaGNU testsuite compiler when using build sysroot") and use the `--tool_exec' option to `runtest' via $(AM_RUNTESTFLAGS) with $(GOC) as the argument rather than the GOC_UNDER_TEST TCL variable to set the compiler to use with the test suite, for cons

[PATCH v2 2/4] libffi/test: Fix compilation for build sysroot

Fix a problem with the libffi testsuite using a method to determine the compiler to use resulting in the tool being different from one the library has been built with, and causing a catastrophic failure from the inability to actually choose any compiler at all in a cross-compilation configuratio

Re: [PATCH] c++: Fix value-init crash in template [PR93676]

On 2/11/20 8:54 PM, Marek Polacek wrote: Since we attempt to value-initialize in build_vec_init even when there's no initializer but the type has a constexpr default constructor. But build_value_init doesn't work in templates, so I think

Re: Update gcc.target/powerpc/pr92132-fp test for power7 and older

On Thu, Feb 13, 2020 at 04:41:09PM -0600, will schmidt wrote: > Attempting to clean up some more testcase failures. > This test in particular exercises the -ftree-vectorize > option, and by inspection I see this fails out with assorted > "conversion not supported by target" messages on power7 and

Re: [PATCH] c++: Fix poor diagnostic for array initializer [PR93710]

On 2/12/20 9:05 PM, Marek Polacek wrote: A small improvement for an error in build_user_type_conversion_1: instead of array-init1.C:11:1: error: conversion from ‘long int’ to ‘A’ is ambiguous 11 | }; | ^ we will print array-init1.C:8:3: error: conversion from ‘long int’ to ‘A’ is am

Re: [PATCH] c++: Fix hashing and testing for equality of ATOMIC_CONST_EXPRs

On 2/12/20 5:15 PM, Patrick Palka wrote: Two equal atomic constraint expressions do not necessarily share the same tree, so we can't assume that two ATOMIC_CONST_EXPRs are equal if and only if they point to the same tree. This is incorrect; comparison of atomic constraints is based on them com

Re: Fix existing fold-vec-extract-longlong.p8.c testcase

Hi! On Thu, Feb 13, 2020 at 04:41:03PM -0600, will schmidt wrote: > The code generated by this test changed shortly after > this test was committed, and we didn't get back to > updating the scan-assembler statements to match. > Until now. Progress! :-) Just some nits: > [testsuite] > * gc

Re: [PATCH] c++: Emit DFP typeinfos even when DFP is disabled [PR92906]

On 2/12/20 12:31 PM, Jakub Jelinek wrote: Hi! Before Joseph's changes when compiling libstdc++-v3/libsupc++/fundamental_type_info.cc we were emitting _ZTIPDd, _ZTIPDe, _ZTIPDf, _ZTIPKDd, _ZTIPKDe, _ZTIPKDf, _ZTIDd, _ZTIDe, _ZTIDf symbols even when DFP wasn't usable, but now we don't and thus tho

Re: [PATCH] avoid user-constructible types in reshape_init_array (PR 90938)

On 2/12/20 9:21 PM, Martin Sebor wrote: On 2/11/20 5:28 PM, Jason Merrill wrote: On 2/11/20 9:00 PM, Martin Sebor wrote: r270155, committed in GCC 9, introduced a transformation that strips redundant trailing zero initializers from array initializer lists in order to support string literals as

Re: [PATCH] document that alias and target must have the same type

On 2/5/20 1:13 PM, Martin Sebor wrote: diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index ec99c38a607..3634ce1c423 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -2557,8 +2557,11 @@ __attribute__ ((access (write_only, 1, 2), access (read_write, 3))) int fgets (c @ite

Backports to 9.3

Hi! I've backported following 15 commits from trunk to 9.3 branch, bootstrapped/regtested on x86_64-linux and i686-linux, committed. r10-6186-g32667e04c7153d97d09d81c1af073d400f0c719a r10-6273-gbff948aa337807260344c83ac9079d6386410094 r10-6314-gaa1b56967d85bfc80d71341395f862ec2b30ca36 r10-6315-g8

Re: [PATCH] document that alias and target must have the same type

On 2/4/20 6:05 PM, Martin Sebor wrote: GCC diagnoses declarations of function aliases whose type doesn't match that of the target (ditto for attribute weakref).  It doesn't yet diagnose such incompatbilities for variable aliases but that's just an oversight that I will try to remember to correct

Update gcc.target/powerpc/pr92132-fp test for power7 and older

Hi, Attempting to clean up some more testcase failures. This test in particular exercises the -ftree-vectorize option, and by inspection I see this fails out with assorted "conversion not supported by target" messages on power7 and earlier systems. Thus, this would limits the scan-dump check of

Fix existing fold-vec-extract-longlong.p8.c testcase

Hi, The code generated by this test changed shortly after this test was committed, and we didn't get back to updating the scan-assembler statements to match. Until now. Tested across assorted power* linux targets. OK for master? Thanks -Will [testsuite] * gcc.target/powerpc/fold-vec-ex

[committed] c++: Fix useless using-declaration.

Here reintroducing the same declarations into the global namespace via using-declaration is useless but OK. And a function and a function template with the same parameters do not conflict. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/cp/ChangeLog 2020-02-13 Jason Merrill PR c++

[comitted] c++: Fix static local vars in extern "C".

Since my patch for PR 91476 moved visibility determination sooner, a local static in a vague linkage function now gets TREE_PUBLIC set before retrofit_lang_decl calls set_decl_linkage, which was making decl_linkage think that it has external linkage. It still has no linkage according to the standa

Re: [PATCH 2/2] libstdc++: Implement ranges [specialized.algorithms]

On Thu, 13 Feb 2020, Jonathan Wakely wrote: > On 12/02/20 15:41 -0500, Patrick Palka wrote: > > This implements all the ranges members defined in [specialized.algorithms]: > > > > ranges::uninitialized_default_construct > > ranges::uninitialized_value_construct > > ranges::uninitialized_copy >

Re: Do not call null register_common in emutls

On Thu, 2020-02-06 at 04:07 -0300, Alexandre Oliva wrote: > Thread-local variables with DECL_COMMON trigger an internal compiler > error on targets that use emulated TLS without register_common, when > we attempt to expand a call to the NULL register_common, with > testcases as simple as gcc.dg/tls

[PATCH] c++: Fix ICE with ill-formed array list-initialization [PR93712]

My P0388R4 patch changed build_array_conv to create an identity conversion at the start of the conversion chain. That was a sound change but now we crash in convert_like_real 7457 case ck_identity: 7458 if (BRACE_ENCLOSED_INITIALIZER_P (expr)) 7459 { 7460 int nelts

Re: Patch ping

On Thu, 2020-02-13 at 10:42 -0700, Martin Sebor wrote: > On 2/13/20 2:54 AM, Jakub Jelinek wrote: > > On Wed, Feb 12, 2020 at 02:39:05PM -0700, Jeff Law wrote: > > > On Mon, 2020-02-10 at 10:24 +0100, Jakub Jelinek wrote: > > > > Hi! > > > > > > > > I'd like to ping a couple of patches: > > > > >

Re: [PATCH] c: Fix ICE with cast to VLA [93576]

On Thu, 2020-02-13 at 18:57 +0100, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs, because the PR84305 changes try to evaluate > the size earlier. If size has side-effects, that is desirable, and the > side-effects will actually be wrapped in a SAVE_EXPR. The problem on this > testca

Re: [PATCH 2/3] libstdc++: Implement C++20 constrained algorithms

On 13/02/20 19:07 +0100, François Dumont wrote: On 2/4/20 3:07 AM, Patrick Palka wrote: This patch implements the C++20 ranges overloads for the algorithms in [algorithms]. Most of the algorithms were reimplemented, with each of their implementations very closely following the existing implemen

[committed, obvious] Add -fdelete-null-pointer-checks to more new C++ testcases.

A few weeks ago I committed this patch to fix some problems I saw in nios2-elf testing: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01385.html Since then there have been some further new C++ constexpr testcases added that have the same problem with assuming -fdelete-null-pointer-checks. I'

Re: [PATCH Coroutines]Insert the default return_void call at correct position

Hello Bin, Nathan, Iain Sandoe wrote: We are seeking to clarify the standard wording around this (and the cases where unhandled_exception() returns - hopefully during the WG21 meeting this week, FWIW, I think your interpretation makes sense here. It’s not clear if the committee will h

Re: [PATCH 2/3] libstdc++: Implement C++20 constrained algorithms

On 2/4/20 3:07 AM, Patrick Palka wrote: This patch implements the C++20 ranges overloads for the algorithms in [algorithms]. Most of the algorithms were reimplemented, with each of their implementations very closely following the existing implementation in bits/stl_algo.h and bits/stl_algobase.h

Re: [PATCH] Generalize -fuse-ld= to support absolute path or arbitrary ld.linker

On 2020-02-09, Fangrui Song wrote: PR driver/93645 * common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=. * opts.c (common_handle_option): Handle OPT_fuse_ld_. * gcc.c (driver_handle_option): Likewise. * collect2.c (main): Likewise. --- gc

[PATCH] c: Fix ICE with cast to VLA [93576]

Hi! The following testcase ICEs, because the PR84305 changes try to evaluate the size earlier. If size has side-effects, that is desirable, and the side-effects will actually be wrapped in a SAVE_EXPR. The problem on this testcase is that there are no side-effects, and c_fully_fold doesn't fold

Re: [PATCH] [arm] Implement Armv8.1-M low overhead loops

Hi Roman, Roman Zhuykov writes: > This patch is stage1 material, right? Yes >> >>> +(define_insn "*doloop_end" >>> + [(parallel [(set (pc) >>> + (if_then_else >>> + (ne (reg:SI LR_REGNUM) (const_int 1)) >>> + (label_ref (match_operan

Re: Patch ping

On 2/13/20 2:54 AM, Jakub Jelinek wrote: On Wed, Feb 12, 2020 at 02:39:05PM -0700, Jeff Law wrote: On Mon, 2020-02-10 at 10:24 +0100, Jakub Jelinek wrote: Hi! I'd like to ping a couple of patches: PR target/91913 - arm movsi + cmpsi -> movsi_compare0 peephole2 ICE fix https://gcc.gnu.org/

Re: [PATCH v2] [MIPS] Prevent allocation of a GPR for a floating mode pseudo

On Mon, 2020-02-10 at 14:33 +0100, Mihailo Stojanovic wrote: > Similar to the mirror case of allocating an FPR for an integer mode > pseudo, prevent GPRs from being allocated for a floating mode pseudo. > > gcc/ChangeLog: > > * gcc/config/mips/mips.c (mips_ira_change_pseudo_allocno_class)

Re: [fixincludes] skip fixinc on vxworks7*, amend mkheaders

On Thu, 2020-02-13 at 01:30 -0300, Alexandre Oliva wrote: > vxworks7 headers haven't required fixes, and we've long avoided > running fixinc on them. > > The problem with that is that, with a dummy fixinc, mkheaders wipes > out include-fixed but then multi_dir subdirs are not created again, so > w

Re: [PATCH] libiberty.h: punt duplicate strverscmp prototype

On Thu, 2020-02-13 at 00:27 -0500, Mike Frysinger wrote: > SVN r216772 accidentally copied & pasted this prototype when adding > other ones nearby. > > 2020-02-13 Mike Frysinger > > * libiberty.h (strverscmp): Delete duplicate prototype. OK. Please push if you've got privs. If not, let

Re: [PATCH] config: import pkg.m4 from pkg-config

On Thu, 2020-02-13 at 00:30 -0500, Mike Frysinger wrote: > We use this in the sim tree currently. Rather than require people to > have pkg-config installed, include it in the config/ dir. > > 2012-12-23 Mike Frysinger > > * pkg.m4: New file from pkg-config-0.29.2. Presumably you're send

Re: [PATCH 2/2] libstdc++: Implement ranges [specialized.algorithms]

On 12/02/20 15:41 -0500, Patrick Palka wrote: This implements all the ranges members defined in [specialized.algorithms]: ranges::uninitialized_default_construct ranges::uninitialized_value_construct ranges::uninitialized_copy ranges::uninitialized_copy_n ranges::uninitialized_move ranges:

Re: [PING^3][PATCH] optimize costly division in rtx_cost

On Thu, Feb 13, 2020 at 2:46 PM Alexander Monakov wrote: > > Ping^3. OK. > On Sun, 5 Jan 2020, Alexander Monakov wrote: > > > Hi, > > > > I noticed there's a costly signed 64-bit division in rtx_cost on x86 as > > well as > > any other target where UNITS_PER_WORD is implemented like TARGET_64BI

[PING^3][PATCH] optimize costly division in rtx_cost

Ping^3. On Sun, 5 Jan 2020, Alexander Monakov wrote: > Hi, > > I noticed there's a costly signed 64-bit division in rtx_cost on x86 as well > as > any other target where UNITS_PER_WORD is implemented like TARGET_64BIT ? 8 : > 4. > It's also evident that rtx_cost does redundant work for a SET r

Re: gcov: reduce code quality loss by reproducible topn merging [PR92924]

> On 1/30/20 5:13 PM, Jan Hubicka wrote: > > Martin, I welcome your opinion on the patch > > Ok, recently we've made quite some experiments with Honza about > TOP N counters. Based on the numbers, it shows that tracking a negative > value per-counter value does not help much. So that I suggest to

Re: [PATCH] i386: Also skip ENDBR32 at the target function entry

On Thu, Feb 13, 2020 at 5:10 AM Uros Bizjak wrote: > > On Thu, Feb 13, 2020 at 1:42 PM H.J. Lu wrote: > > > > On Thu, Feb 13, 2020 at 01:28:43PM +0100, Uros Bizjak wrote: > > > On Thu, Feb 13, 2020 at 1:06 PM H.J. Lu wrote: > > > > > > > > On Thu, Feb 13, 2020 at 09:29:32AM +0100, Uros Bizjak wr

Re: [PATCH] i386: Also skip ENDBR32 at the target function entry

On Thu, Feb 13, 2020 at 1:42 PM H.J. Lu wrote: > > On Thu, Feb 13, 2020 at 01:28:43PM +0100, Uros Bizjak wrote: > > On Thu, Feb 13, 2020 at 1:06 PM H.J. Lu wrote: > > > > > > On Thu, Feb 13, 2020 at 09:29:32AM +0100, Uros Bizjak wrote: > > > > On Wed, Feb 12, 2020 at 1:21 PM H.J. Lu wrote: > > >

PING^7: [PATCH] i386: Properly encode xmm16-xmm31/ymm16-ymm31 for vector move

On Thu, Feb 6, 2020 at 8:17 PM H.J. Lu wrote: > > On Mon, Jan 27, 2020 at 10:59 AM H.J. Lu wrote: > > > > On Mon, Jul 8, 2019 at 8:19 AM H.J. Lu wrote: > > > > > > On Tue, Jun 18, 2019 at 8:59 AM H.J. Lu wrote: > > > > > > > > On Fri, May 31, 2019 at 10:38 AM H.J. Lu wrote: > > > > > > > > > >

Re: [PATCH] i386: Also skip ENDBR32 at the target function entry

On Thu, Feb 13, 2020 at 01:28:43PM +0100, Uros Bizjak wrote: > On Thu, Feb 13, 2020 at 1:06 PM H.J. Lu wrote: > > > > On Thu, Feb 13, 2020 at 09:29:32AM +0100, Uros Bizjak wrote: > > > On Wed, Feb 12, 2020 at 1:21 PM H.J. Lu wrote: > > > > > > > > On Mon, Feb 10, 2020 at 12:01 PM Uros Bizjak wro

Re: [PATCH] i386: Also skip ENDBR32 at the target function entry

On Thu, Feb 13, 2020 at 1:06 PM H.J. Lu wrote: > > On Thu, Feb 13, 2020 at 09:29:32AM +0100, Uros Bizjak wrote: > > On Wed, Feb 12, 2020 at 1:21 PM H.J. Lu wrote: > > > > > > On Mon, Feb 10, 2020 at 12:01 PM Uros Bizjak wrote: > > > > > > > > On Mon, Feb 10, 2020 at 8:53 PM H.J. Lu wrote: > > >

Re: [PATCH 1/2] libstdc++: Move some ranges algos to a new header

On 12/02/20 15:41 -0500, Patrick Palka wrote: This roughly mirrors the existing split between and . The ranges [specialized.algorithms] will use this new header to avoid including all of of . libstdc++-v3/ChangeLog: * include/Makefile.am: Add bits/ranges_algobase.h * include/M

[PATCH] i386: Also skip ENDBR32 at the target function entry

On Thu, Feb 13, 2020 at 09:29:32AM +0100, Uros Bizjak wrote: > On Wed, Feb 12, 2020 at 1:21 PM H.J. Lu wrote: > > > > On Mon, Feb 10, 2020 at 12:01 PM Uros Bizjak wrote: > > > > > > On Mon, Feb 10, 2020 at 8:53 PM H.J. Lu wrote: > > > > > > > > On Mon, Feb 10, 2020 at 11:40 AM Uros Bizjak wrote

Re: [ARM] Fix -mpure-code for v6m

On Mon, 10 Feb 2020 at 17:45, Richard Earnshaw (lists) wrote: > > On 10/02/2020 09:27, Christophe Lyon wrote: > > On Fri, 7 Feb 2020 at 17:55, Richard Earnshaw (lists) > > wrote: > >> > >> On 07/02/2020 16:43, Christophe Lyon wrote: > >>> On Fri, 7 Feb 2020 at 14:49, Richard Earnshaw (lists) > >>

Re: Patch ping

On Wed, Feb 12, 2020 at 02:39:05PM -0700, Jeff Law wrote: > On Mon, 2020-02-10 at 10:24 +0100, Jakub Jelinek wrote: > > Hi! > > > > I'd like to ping a couple of patches: > > > > PR target/91913 - arm movsi + cmpsi -> movsi_compare0 peephole2 ICE fix > >https://gcc.gnu.org/ml/gcc-patches/2020-

Re: [PATCH] openmp: ignore nowait if async execution is unsupported [PR93481]

Hi Jakub, On 13.02.20 09:30, Jakub Jelinek wrote: > On Thu, Feb 13, 2020 at 09:04:36AM +0100, Harwath, Frederik wrote: >> --- a/libgomp/target.c >> +++ b/libgomp/target.c >> @@ -2022,6 +2022,16 @@ GOMP_target (int device, void (*fn) (void *), const >> void *unused, >>gomp_unmap_vars (tgt_vars

Re: [PATCH]Several intrinsic macros lack a closing parenthesis[PR93274]

On Thu, Feb 13, 2020 at 5:12 PM Uros Bizjak wrote: > > On Thu, Feb 13, 2020 at 9:53 AM Jakub Jelinek wrote: > > > > On Thu, Feb 13, 2020 at 09:39:05AM +0100, Uros Bizjak wrote: > > > > Changelog > > > > gcc/ > > > >* config/i386/avx512vbmi2intrin.h > > > >(_mm512_[,mask_,maskz_]sh

Re: [PATCH] i386: Fix up _mm*_mask_popcnt_epi* [PR93696]

On Thu, Feb 13, 2020 at 9:47 AM Jakub Jelinek wrote: > > Hi! > > As mentioned in the PR and as > https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mask_popcnt_epi > also documents, _mm*_popcnt_epi* intrinsics are consistent with all other > unary AVX512* intrinsics regarding argu

Re: testsuite: Fix g++.dg/analyzer/pr93212.C with check-c++-all

On Thu, 2020-02-13 at 08:11 +0100, Jakub Jelinek wrote: > On Thu, Feb 06, 2020 at 03:27:29PM -0500, David Malcolm wrote: > > gcc/testsuite/ChangeLog: > > PR analyzer/93212 > > * g++.dg/analyzer/analyzer.exp: New subdirectory and .exp > > suite. > > * g++.dg/analyzer/malloc.C: New test.

Re: [PATCH]Several intrinsic macros lack a closing parenthesis[PR93274]

On Thu, Feb 13, 2020 at 9:53 AM Jakub Jelinek wrote: > > On Thu, Feb 13, 2020 at 09:39:05AM +0100, Uros Bizjak wrote: > > > Changelog > > > gcc/ > > >* config/i386/avx512vbmi2intrin.h > > >(_mm512_[,mask_,maskz_]shrdi_epi16, > > >_mm512_[,mask_,maskz_]shrdi_epi32, > > >

Re: [PATCH 0/4 GCC11] IVOPTs consider step cost for different forms when unrolling

On Thu, Feb 13, 2020 at 08:48:33AM +0100, Richard Biener wrote: > On Wed, 12 Feb 2020, Segher Boessenkool wrote: > > On Wed, Feb 12, 2020 at 11:53:22AM +0100, Richard Biener wrote: > > > BB reorder switches back and forth as well ... :/ > > > > Yes. It is extremely hard to change any jumps in cfg

Re: [PATCH]Several intrinsic macros lack a closing parenthesis[PR93274]

On Thu, Feb 13, 2020 at 09:39:05AM +0100, Uros Bizjak wrote: > > Changelog > > gcc/ > >* config/i386/avx512vbmi2intrin.h > >(_mm512_[,mask_,maskz_]shrdi_epi16, > >_mm512_[,mask_,maskz_]shrdi_epi32, > >_m512_[,mask_,maskz_]shrdi_epi64, > >_mm512_[,mask_,maskz_

Re: [PATCH] sccvn: Handle bitfields in vn_reference_lookup_3 [PR93582]

On Thu, 13 Feb 2020, Jakub Jelinek wrote: > Hi! > > The following patch is first step towards fixing PR93582. > vn_reference_lookup_3 right now punts on anything that isn't byte aligned, > so to be able to lookup a constant bitfield store, one needs to use > the exact same COMPONENT_REF, otherwis

[PATCH] i386: Fix up _mm*_mask_popcnt_epi* [PR93696]

Hi! As mentioned in the PR and as https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mask_popcnt_epi also documents, _mm*_popcnt_epi* intrinsics are consistent with all other unary AVX512* intrinsics regarding arguments, i.e. the _mm*_whatever has just single argument (called a in

Re: [PATCH]Several intrinsic macros lack a closing parenthesis[PR93274]

> Changelog > gcc/ >* config/i386/avx512vbmi2intrin.h >(_mm512_[,mask_,maskz_]shrdi_epi16, >_mm512_[,mask_,maskz_]shrdi_epi32, >_m512_[,mask_,maskz_]shrdi_epi64, >_mm512_[,mask_,maskz_]shldi_epi16, >_mm512_[,mask_,maskz_]shldi_epi32, >_m512_[,

Re: [PATCH] openmp: ignore nowait if async execution is unsupported [PR93481]

On Thu, Feb 13, 2020 at 09:04:36AM +0100, Harwath, Frederik wrote: > --- a/libgomp/target.c > +++ b/libgomp/target.c > @@ -2022,6 +2022,16 @@ GOMP_target (int device, void (*fn) (void *), const > void *unused, >gomp_unmap_vars (tgt_vars, true); > } > > +static unsigned int Add inline? > +

Re: [PATCH] i386: Skip ENDBR32 at nested function entry

On Wed, Feb 12, 2020 at 1:21 PM H.J. Lu wrote: > > On Mon, Feb 10, 2020 at 12:01 PM Uros Bizjak wrote: > > > > On Mon, Feb 10, 2020 at 8:53 PM H.J. Lu wrote: > > > > > > On Mon, Feb 10, 2020 at 11:40 AM Uros Bizjak wrote: > > > > > > > > On Mon, Feb 10, 2020 at 8:22 PM H.J. Lu wrote: > > > > >

[PATCH] testsuite/93717 fix up gcc.dg/optimize-bswapsi-2.c for BE

Pushed. 2020-02-13 Richard Biener PR testsuite/93717 * gcc.dg/optimize-bswapsi-2.c: Add BE case. --- gcc/testsuite/gcc.dg/optimize-bswapsi-2.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/gcc/testsuite/gcc.dg/optimize-bswapsi-2.c

[PATCH] openmp: ignore nowait if async execution is unsupported [PR93481]

Hi Jakub, On 10.02.20 08:49, Harwath, Frederik wrote: >> There has been even in some PR a suggestion that instead of failing >> in nvptx async_run we should just ignore the nowait clause if the plugin >> doesn't implement it properly. > > This must be https://gcc.gnu.org/PR93481. The attached p