Re: [PATCH][committed] Warn about inconsistent OpenACC nested reduction clauses

Hi Jakub, On 06.11.19 14:00, Jakub Jelinek wrote: > On Wed, Nov 06, 2019 at 01:41:47PM +0100, frede...@codesourcery.com wrote: >> --- a/gcc/omp-low.c >> +++ b/gcc/omp-low.c >> @@ -128,6 +128,12 @@ struct omp_context >> [...] >> + /* A tree_list of the reduction clauses in this context. */ >> +

Re: [Patch][Fortran] PR91253 fix continuation-line handling with -pre_include

On 11/7/19 12:41 PM, Tobias Burnus wrote: This fixes the gfortran.dg/continuation_6.f fails testsuite fails with newer GLIBC. The continuation line handling assumes that the line number starts at 0 (→ continue_line) and then can be incremented, if needed. The problem came up with -pre_includ

Re: [PATCH rs6000]Fix PR92132

Hi Segher, on 2019/11/8 上午8:07, Segher Boessenkool wrote: > Hi! > >>> Half are pretty simple: >>> >>> lt(a,b) = gt(b,a) >>> gt(a,b) = gt(a,b) >>> eq(a,b) = eq(a,b) >>> le(a,b) = ge(b,a) >>> ge(a,b) = ge(a,b) >>> >>> ltgt(a,b) = ge(a,b) ^ ge(b,a) >>> ord(a,b) = ge(a,b) | ge(b,a) >>> >>> The other

Re: [PR47785] COLLECT_AS_OPTIONS

Hi Richard, Thanks for the review. On Tue, 5 Nov 2019 at 23:08, Richard Biener wrote: > > On Tue, Nov 5, 2019 at 12:17 AM Kugan Vivekanandarajah > wrote: > > > > Hi, > > Thanks for the review. > > > > On Tue, 5 Nov 2019 at 03:57, H.J. Lu wrote: > > > > > > On Sun, Nov 3, 2019 at 6:45 PM Kugan V

Re: [PATCH, rs6000 v2] Make load cost more in vectorization cost for P8/P9

Hi Segher, on 2019/11/8 上午6:36, Segher Boessenkool wrote: > On Thu, Nov 07, 2019 at 11:22:12AM +0800, Kewen.Lin wrote: >> One updated patch to enable it everywhere attached. > >> 2019-11-07 Kewen Lin >> >> * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Make >> scalar_l

Handle removal of old-style function definitions in C2x

C2x removes support for old-style function definitions with identifier lists, changing () in function definitions to be equivalent to (void) (while () in declarations that are not definitions still gives an unprototyped type). This patch updates GCC accordingly. The new semantics for () are imple

[committed] pa: Revise memory barriers to use strongly ordered ldcw instruction

This change revises the memory barrier patterns to use the ldcw instruction instead of the sync instruction. The sync instruction performs better and I have more confidence in it than sync. We use a location just above the top of the stack for these operations. The stack address is aligned to

[PATCH] libsupc++: add to precompiled header

Also process it with Doxygen. * doc/doxygen/user.cfg.in (INPUT): Add header. * include/precompiled/stdc++.h: Include header. Tested powerpc64le-linux, committed to trunk. commit ed86b7c065df6b33dfee86fba3bee089386ac4a8 Author: Jonathan Wakely Date: Thu Nov 7 23:20:51 2019 +0

[PATCH] libstdc++: define std::common_comparison_category for C++20

* libsupc++/compare (common_comparison_category) (common_comparison_category_t): Define for C++20. * testsuite/18_support/comparisons/common/1.cc: New test. Tested powerpc64le-linux, committed to trunk. commit cb48e7e6d0bbed9eadc34b4318511f3e05ec1b64 Author: Jonathan Wake

Re: [PATCH 2/4] MSP430: Disable exception handling by default for C++

On Thu, 2019-11-07 at 21:37 +, Jozef Lawrynowicz wrote: > The code size bloat added by building C++ programs using libraries containing > support for exceptions is significant. When using simple constructs such as > static variables, sometimes many kB from the libraries are unnecessarily > pull

Re: [PATCH rs6000]Fix PR92132

Hi! On Thu, Nov 07, 2019 at 06:17:53PM +0800, Kewen.Lin wrote: > on 2019/11/7 上午7:49, Segher Boessenkool wrote: > > The expander named "one_cmpl3": > > > > Erm. 2, not 3 :-) > Ah, sorry I didn't notice we have one cmpl**3** but actually for one > cmpl**2** expand, a bit surprised. Done. Thank

[PATCH] rs6000: Remove no longer correct assert

After the simplify-rtx patch, we can now be asked about conditions we wouldn't be asked about before. This is perfectly fine, except we have a little over-eager assert. Remove that one. I originally had this patch before the simplify-rtx one, but I reordered them without retesting every step.

Expand C2x attribute parsing support and factor out from TM attributes

There is one place in the C parser that already handles a subset of the C2x [[]] attribute syntax: c_parser_transaction_attributes. This patch factors C2x attribute parsing out of there, extending it to cover the full C2x attribute syntax (although currently only called from that one place in the

Re: [C] Opt out of GNU vector extensions for built-in SVE types

On Thu, 7 Nov 2019, Richard Sandiford wrote: > Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [C++ PATCH] Implement D1959R0, remove weak_equality and strong_equality.

On Thu, Nov 07, 2019 at 05:05:16PM +, Jason Merrill wrote: > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-scalar1-neg.C > @@ -0,0 +1,25 @@ > +// { dg-do run { target c++2a } } > + > +#include > + > +#define assert(X) do { if (!(X)) __builtin_abort(); } while(0) > + > +void f(){}

[committed] Fix some typos

Hi! I've noticed a comment typo in build_vec_delete_1 and when grepping around if the same typo isn't elsewhere, I found a different typo elsewhere. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as obvious. 2019-11-08 Jakub Jelinek * ipa-util

[PATCH] libstdc++: make negative count safe with std::for_each_n

The Library Working Group have approved a change to std::for_each_n that requires it to handle negative N gracefully, which we were not doing for random access iterators. * include/bits/stl_algo.h (for_each_n): Handle negative count. * testsuite/25_algorithms/for_each/for_each_n_d

Re: [PATCH 2/2] Introduce the gcc option --record-gcc-command-line

On 11/7/19 7:57 PM, Segher Boessenkool wrote: Hi! On Thu, Nov 07, 2019 at 06:44:17PM +0100, Egeyar Bagcioglu wrote: On 11/7/19 9:03 AM, Segher Boessenkool wrote: + ASM_OUTPUT_ASCII(asm_out_file, cmdline, cmdline_length); +} + cmdline[0] = 0; + ASM_OUTPUT_ASCII(asm_out_file, cmdl

Re: introduce -fcallgraph-info option

On Nov 7, 2019, Richard Biener wrote: > (also raises the question why we have both -dumpbase and -auxbase ...) https://gcc.gnu.org/ml/gcc-patches/2002-08/msg00294.html This was before -dumpdir, however. Here's the current logic for aux_base_name: -c or -S with -o [odir/]obase.oext: [odir/]ob

Re: [PATCH, rs6000 v2] Make load cost more in vectorization cost for P8/P9

On Thu, Nov 07, 2019 at 11:22:12AM +0800, Kewen.Lin wrote: > One updated patch to enable it everywhere attached. > 2019-11-07 Kewen Lin > > * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Make > scalar_load, vector_load, unaligned_load and vector_gather_load cost >

Re: [PATCH] simplify-rtx: simplify_logical_relational_operation

On Wed, Nov 06, 2019 at 10:46:06AM -0700, Jeff Law wrote: > BTW, I think there's enough overlap between simplify-rtx and combine > that if you wanted to maintain simplify-rtx as well that I'd fully > support it. Thoughts? I'd be honoured, thanks for the offer! Segher

[PATCH 4/4] MSP430: Deprecate -minrt option

Support for the MSP430 -minrt option has been removed from Newlib, since all the associated behaviour is now dynamic. Initialization code run before main is only included when needed. This patch removes the final traces of -minrt from GCC. -minrt used to modify the linking process in the followin

[PATCH 3/4] MSP430: Disable __cxa_atexit

The MSP430 target does not need to support dynamic shared objects so __cxa_atexit does not need to be used - atexit is sufficient. Newlib atexit is a fine replacement as it also supports registration of more than 32 functions. By not using __cxa_atexit, we can define TARGET_LIBGCC_REMOVE_DSO_HAND

[PATCH 2/4] MSP430: Disable exception handling by default for C++

The code size bloat added by building C++ programs using libraries containing support for exceptions is significant. When using simple constructs such as static variables, sometimes many kB from the libraries are unnecessarily pulled in. So this patch disable exceptions by default for MSP430 when

[PATCH 1/4] MSP430: Disable TM clone registry by default

Given that MSP430 is a resource constrained, embedded target disabling transactional memory by default is a good idea to save on code size in the runtime library. It can still be enabled by passing --enable-tm-clone-registry (although as far as I understand the feature is fundamentally incompatibl

[PATCH 0/4][MSP430] Tweaks to default configuration to reduce code size

When building small programs for MSP430, the impact of the unused functions pulled in from the CRT libraries is quite noticeable. Most of these relates to feature that will never be used for MSP430 (Transactional memory, supporting shared objects and dynamic linking), or rarely used (exception hand

[Darwin, X86, testsuite, committed] Fix pr92258.c.

This test uses -masm=intel, which isn't supported by Darwin, so add the necessary dg-require-effective-target. tested on x86_64-darwin16, applied as obvious to mainline, thanks Iain gcc/testsuite/ChangeLog: 2019-11-07 Iain Sandoe * gcc.target/i386/pr92258.c: Add dg-requires for mas

[Patch][Fortran] PR91253 fix continuation-line handling with -pre_include

This fixes the gfortran.dg/continuation_6.f fails testsuite fails with newer GLIBC. The continuation line handling assumes that the line number starts at 0 (→ continue_line) and then can be incremented, if needed. The problem came up with -pre_include, which is used with newer GLIBC to provi

Re: [C++ PATCH] PR c++/91370 - Implement P1041R4 and P1139R2 - Stronger Unicode reqs

OK. On 11/7/19 3:38 PM, Jakub Jelinek wrote: Hi! GCC does use UTF-16 and UTF-32 for char16_t and char32_t string literals already, so P1041R4 is I believe already implemented with no changes needed. While going through P1139R2, I've realized that we weren't handling "If the value is not repres

[PATCH] PR libstdc++/92124 on hashtable

From what I understood from recent fix the unordered containers need to be updated the same way. I hope you'll appreciate the usage of rvalue forwarding. Containers node values are moved as soon as _M_assign is called with a rvalue reference to the source container. Additionnaly this patch r

[PATCH, rs6000][committed] Fix PR92090: Allow MODE_PARTIAL_INT modes for integer constant input operands.

Before, LRA, we have an insn that sets a TImode pseudo with an integer constant and a following insn that copies that TImode pseudo to a PTImode pseudo. During LRA spilling, we generate a new insn that sets a PTImode pseudo to that constant directly and we ICE because we do not recognize that as a

Re: [PATCH 2/2] Introduce the gcc option --record-gcc-command-line

Hi! On Thu, Nov 07, 2019 at 06:44:17PM +0100, Egeyar Bagcioglu wrote: > On 11/7/19 9:03 AM, Segher Boessenkool wrote: > >>+ ASM_OUTPUT_ASCII(asm_out_file, cmdline, cmdline_length); > >>+} > >>+ cmdline[0] = 0; > >>+ ASM_OUTPUT_ASCII(asm_out_file, cmdline, 1); > >>+ > >>+ /* The return val

[PATCH 7/X] [libsanitizer] Add tests

Adding hwasan tests. Frankly, these could be tidied up a little. I will be tidying them up while getting feedback on the hwasan introduction. gcc/testsuite/ChangeLog: 2019-11-07 Matthew Malcomson * c-c++-common/hwasan/arguments.c: New test. * c-c++-common/hwasan/halt_on_erro

[PATCH 5/X] [libsanitizer][mid-end] Introduce stack variable handling for HWASAN

Handling stack variables has three features. 1) Ensure HWASAN required alignment for stack variables When tagging shadow memory, we need to ensure that each tag granule is only used by one variable at a time. This is done by ensuring that each tagged variable is aligned to the tag granule repres

[PATCH 6/X] [libsanitizer] Add hwasan pass and associated gimple changes

There are four main features to this change: 1) Check pointer tags match address tags. In the new `hwasan` pass we put HWASAN_CHECK internal functions around all memory accesses, to check that tags in the pointer being used match the tag stored in shadow memory for the memory region being used.

[PATCH 4/X] [libsanitizer][options] Add hwasan flags and argument parsing

These flags can't be used at the same time as any of the other sanitizers. We add an equivalent flag to -static-libasan in -static-libhwasan to ensure static linking. The -fsanitize=kernel-hwaddress option is for compiling targeting the kernel. This flag has defaults that allow compiling KASAN wi

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

This patch does tries to tie libhwasan into the GCC build system in the same way that the other sanitizer runtime libraries are handled. libsanitizer/ChangeLog: 2019-11-07 Matthew Malcomson * Makefile.am: Build libhwasan. * Makefile.in: Build libhwasan. * asan/Makefi

[PATCH 3/X] [libsanitizer] Add option to bootstrap using HWASAN

This is an analogous option to --bootstrap-asan to configure. It allows bootstrapping GCC using HWASAN. For the same reasons as for ASAN we have to avoid using the HWASAN sanitizer when compiling libiberty and the lto-plugin. Also add a function to query whether -fsanitize=hwaddress has been pas

[PATCH 2/X] [libsanitizer] Only build libhwasan when targeting AArch64

Though the library has limited support for x86, we don't have any support for generating code targeting x86 so there is no point building for that target. libsanitizer/ChangeLog: 2019-11-07 Matthew Malcomson * Makefile.am: Condition building hwasan directory. * Makefile.in: Re

v2 [PATCH 0/X] Introduce HWASAN sanitizer to GCC

I have rebased this series onto Martin Liska's patches that take the most recent libhwasan from upstream LLVM. https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html I've also cleared up some nomenclature (I had previously used the word 'colour' a few times instead of the word 'tag' and that cla

Re: [PATCH 13/X] [libsanitizer][options] Add hwasan flags and argument parsing

Clang has a function level attribute, __attribute__((no_sanitize("hwaddress"))) a feature macro #if __has_feature(hwaddress_sanitizer) and a blacklist section [hwaddress] https://clang.llvm.org/docs/SanitizerSpecialCaseList.html I think it makes sense for the compiler to err on the side of

Re: [PATCH 2/2] Introduce the gcc option --record-gcc-command-line

Hello again Segher! On 11/7/19 9:03 AM, Segher Boessenkool wrote: Hi! On Wed, Nov 06, 2019 at 06:21:34PM +0100, Egeyar Bagcioglu wrote: +static const char * +record_gcc_command_line_spec_function(int argc ATTRIBUTE_UNUSED, const char **argv) +{ + const char *filename = argv[0]; + FILE *out

[PATCH] [LRA] Do not use eliminable registers for spilling

Hello On AMD GCN, I encountered the following situation in the following testcases using the compilation flags '-O2 -ftracer -fsplit-paths': libgomp.oacc-fortran/reduction-1.f90 libgomp.oacc-fortran/reduction-2.f90 libgomp.oacc-fortran/reduction-3.f90 gcc.c-torture/execute/ieee/pr50310.c - LR

Re: [PATCH 1/2] Introduce dg-require-target-object-format

On 11/7/19 6:17 PM, jose.march...@oracle.com wrote: On 11/7/19 8:47 AM, Segher Boessenkool wrote: > Hi! > > On Wed, Nov 06, 2019 at 06:21:33PM +0100, Egeyar Bagcioglu wrote: >> gcc/testsuite/ChangeLog: >> 2019-11-06 Egeyar Bagcioglu >> >>

Re: [PATCH 1/2] Introduce dg-require-target-object-format

On 11/7/19 8:47 AM, Segher Boessenkool wrote: > Hi! > > On Wed, Nov 06, 2019 at 06:21:33PM +0100, Egeyar Bagcioglu wrote: >> gcc/testsuite/ChangeLog: >> 2019-11-06 Egeyar Bagcioglu >> >> * lib/target-supports-dg.exp: Define dg-require-target-object-

Re: [4/6] Optionally pick the cheapest loop_vec_info

Richard Biener writes: > On Wed, Nov 6, 2019 at 3:01 PM Richard Sandiford > wrote: >> >> Richard Biener writes: >> > On Tue, Nov 5, 2019 at 3:29 PM Richard Sandiford >> > wrote: >> >> >> >> This patch adds a mode in which the vectoriser tries each available >> >> base vector mode and picks the

[C++ PATCH] Implement D1959R0, remove weak_equality and strong_equality.

Shortly after I finished implementing the previous <=> semantics, the committee decided to remove the *_equality comparison categories, because they were largely obsoleted by the earlier change that separated operator== from its original dependency on operator<=>. Tested x86_64-pc-linux-gnu, apply

Re: [PATCH 2/2][MIPS][RFC] Emit .note.GNU-stack for hard-float linux targets.

On 01.11.2019. 11:32, Dragan Mladjenovic wrote: > On 10.08.2019. 00:15, Joseph Myers wrote: >> On Fri, 9 Aug 2019, Jeff Law wrote: >> 2019-08-05 Dragan Mladjenovic * config.in: Regenerated. * config/mips/linux.h (NEED_INDICATE_EXEC_STACK): Define to 1 for TAR

Re: [2/6] Don't assign a cost to vectorizable_assignment

Richard Biener writes: > On Wed, Nov 6, 2019 at 4:58 PM Richard Sandiford > wrote: >> >> Richard Biener writes: >> > On Tue, Nov 5, 2019 at 3:27 PM Richard Sandiford >> > wrote: >> >> >> >> vectorizable_assignment handles true SSA-to-SSA copies (which hopefully >> >> we don't see in practice) a

Re: [PATCH 1/2] Introduce dg-require-target-object-format

Hi Segher! On 11/7/19 8:47 AM, Segher Boessenkool wrote: Hi! On Wed, Nov 06, 2019 at 06:21:33PM +0100, Egeyar Bagcioglu wrote: gcc/testsuite/ChangeLog: 2019-11-06 Egeyar Bagcioglu * lib/target-supports-dg.exp: Define dg-require-target-object-format. * lib/target-supports-dg.exp

Re: [PATCH 0/2] Introduce a new GCC option, --record-gcc-command-line

On 11/7/19 4:13 PM, Nick Clifton wrote: Hi Egeyar, Thanks for including me in this discussion. This option is similar to -frecord-gcc-switches. For the record I will also note that there is -fverbose-asm which does almost the same thing, but only records the options as comments in the asse

[patch] follow up on the aarch64 r18 story

Hello, About a year ago we discussed various possibilities regarding an issue with the aarch64 selection of r18 as the static chain, problematic in environments where the OS uses r18 for "private" reasons. VxWorks uses this permission to use r18 as a pointer to the current TCB, and Windows does so

Re: [1/6] Fix vectorizable_conversion costs

On November 7, 2019 4:14:14 PM GMT+01:00, Richard Sandiford wrote: >Richard Biener writes: >> On Tue, Nov 5, 2019 at 3:25 PM Richard Sandiford >> wrote: >>> >>> This patch makes two tweaks to vectorizable_conversion. The first >>> is to use "modifier" to distinguish between promotion, demotion

Re: [PATCH 13/X] [libsanitizer][options] Add hwasan flags and argument parsing

On Thu, Nov 7, 2019 at 1:48 PM Matthew Malcomson wrote: > > On 05/11/2019 13:11, Andrey Konovalov wrote: > > On Tue, Nov 5, 2019 at 12:34 PM Matthew Malcomson > > wrote: > >> > >> NOTE: > >> -- > >> I have defined a new macro of __SANITIZE_HWADDRESS__ that gets > >> automatically defined when

[C++ PATCH] PR c++/91370 - Implement P1041R4 and P1139R2 - Stronger Unicode reqs

Hi! GCC does use UTF-16 and UTF-32 for char16_t and char32_t string literals already, so P1041R4 is I believe already implemented with no changes needed. While going through P1139R2, I've realized that we weren't handling "If the value is not representable within 16 bits, the program is ill-forme

[PATCH] Handle gimple_clobber_p stmts in store-merging (PR target/92038)

Hi! The following patch adds handling of clobbers in store-merging. The intent is if we have a clobber followed by some stores into the clobbered area, even if don't store all the bytes in the area, we can avoid masking, because the non-stored bytes are undefined and in some cases we can even ove

Re: [committed] Remove gimple_call_types_likely_match_p (PR 70929)

On Thu, Nov 07, 2019 at 12:00:32PM +0100, Martin Jambor wrote: > 2019-11-07 Martin Jambor > > PR lto/70929 > * cif-code.def (MISMATCHED_ARGUMENTS): Removed. > * cgraph.h (gimple_check_call_matching_types): Remove > * cgraph.c (gimple_check_call_args): Likewise. > (

Re: [1/6] Fix vectorizable_conversion costs

Richard Biener writes: > On Tue, Nov 5, 2019 at 3:25 PM Richard Sandiford > wrote: >> >> This patch makes two tweaks to vectorizable_conversion. The first >> is to use "modifier" to distinguish between promotion, demotion, >> and neither promotion nor demotion, rather than using a code for >> so

Re: [PATCH 0/2] Introduce a new GCC option, --record-gcc-command-line

Hi Egeyar, Thanks for including me in this discussion. >>> This option is similar to -frecord-gcc-switches. For the record I will also note that there is -fverbose-asm which does almost the same thing, but only records the options as comments in the assembler. They are never converted into data

Re: [PATCH 0/2] Introduce a new GCC option, --record-gcc-command-line

On 11/7/19 10:24 AM, Martin Liška wrote: On 11/6/19 6:21 PM, Egeyar Bagcioglu wrote: Hello, Hello. Thanks for your detailed reply Martin. You'll find my reply inline. Since you added Nick Clifton to your following reply, I am adding him to this email too. He is not only the author of anno

Re: [PATCH V3] rs6000: Refine small loop unroll in loop_unroll_adjust hook

Jiufu Guo writes: Hi Sehger, I updated the patch as we discussed. This patch does not turn on -fweb or -frename-registers with -funroll-loops for powerpc. Thanks for review in advance. gcc/ 2019-11-07 Jiufu Guo PR tree-optimization/88760 * gcc/config/rs6000/rs6000.opt (-mu

Re: [PATCH][vect] PR 92351: When peeling for alignment make alignment of epilogues unknown

On 07/11/2019 14:00, Richard Biener wrote: On Thu, 7 Nov 2019, Andre Vieira (lists) wrote: Hi, PR92351 reports a bug in which a wrongly aligned load is generated for an epilogue of a main loop for which we peeled for alignment. There is no way to guarantee that epilogue data accesses are a

Re: [PATCH][vect] Disable vectorization of epilogues for loops with SIMDUID set

On Thu, Nov 07, 2019 at 02:26:29PM +, Andre Vieira (lists) wrote: > 2019-11-07 Andre Vieira > > * tree-vect-loop.c (vect_analyze_loop): Disable epilogue > vectorization for loops with SIMDUID set. Enable epilogue > vectorization for loops with SIMDLEN set after find

Re: [PATCH][vect] Disable vectorization of epilogues for loops with SIMDUID set

Hi, Rebased the patch on top of Richard Sandiford's patches, with his fixes I can now allow for vectorization of epilogues after we match simdlen. This will however not turn on epilogue vectorization in cases where we specify a desired simdlen that is never matched. This would require more w

Re: introduce -fcallgraph-info option

On Thu, 7 Nov 2019, Alexandre Oliva wrote: > On Nov 7, 2019, Richard Biener wrote: > > > So how's -dumpbase handled? > > It's part of the gcc driver interface, and lto-wrapper passes it to gcc > for -fltrans compilations. -auxbase isn't, so one of the alternatives I > suggested involved our t

Re: [PATCH][vect] PR 92351: When peeling for alignment make alignment of epilogues unknown

On Thu, 7 Nov 2019, Andre Vieira (lists) wrote: > Hi, > > PR92351 reports a bug in which a wrongly aligned load is generated for an > epilogue of a main loop for which we peeled for alignment. There is no way to > guarantee that epilogue data accesses are aligned when the main loop is > peeling

Re: [PATCH][AArch64] Implement Armv8.5-A memory tagging (MTE) intrinsics

Hi Kyrill, I have rebased the patch on top of current truck. For resolve_overloaded, I redefined my memtag overloading function to fit the latest resolve_overloaded_builtin interface. Regression tested again and survived for aarch64-none-linux-gnu. Cheers Dennis Changelog is updated as followi

Free some more stuff in free_lang_data

Hi, as every year, I went through reasons why types of same ODR name are not merged in firefox streaming. Here are few problems I caught. Remaining issues I understand are 1) odr violations (which is OK of course) 2) keyed vtables: sometimes the vtable decl is weak and sometimes it is exter

Re: [patch][avr] PR92055: Add switches to enable 64-bit [long] double.

Am 07.11.19 um 13:49 schrieb Martin Liška: On 11/7/19 1:39 PM, Georg-Johann Lay wrote: Am 07.11.19 um 10:41 schrieb Martin Liška: Hello. I've noticed quite some GNU coding style violations with your patch. Please next time, use something like: $ git diff HEAD~ > /tmp/patch && ./contrib/check_

Re: [patch][avr] PR92055: Add switches to enable 64-bit [long] double.

On 11/7/19 1:39 PM, Georg-Johann Lay wrote: Am 07.11.19 um 10:41 schrieb Martin Liška: Hello. I've noticed quite some GNU coding style violations with your patch. Please next time, use something like: $ git diff HEAD~ > /tmp/patch && ./contrib/check_GNU_style.py /tmp/patch Thanks, Martin h

Re: [PATCH 13/X] [libsanitizer][options] Add hwasan flags and argument parsing

On 05/11/2019 13:11, Andrey Konovalov wrote: > On Tue, Nov 5, 2019 at 12:34 PM Matthew Malcomson > wrote: >> >> NOTE: >> -- >> I have defined a new macro of __SANITIZE_HWADDRESS__ that gets >> automatically defined when compiling with hwasan. This is analogous to >> __SANITIZE_ADDRESS__ which

Re: [RFC PATCH] Extend the simd function attribute

On 05/11/2019 18:42, Joseph Myers wrote: > On Tue, 5 Nov 2019, Szabolcs Nagy wrote: >> GCC currently supports two ways to declare the availability of vector >> variants of a scalar function: >> >> #pragma omp declare simd >> void f (void); >> >> and >> >> __attribute__ ((simd)) >> void f (v

Re: [patch][avr] PR92055: Add switches to enable 64-bit [long] double.

Am 07.11.19 um 10:41 schrieb Martin Liška: Hello. I've noticed quite some GNU coding style violations with your patch. Please next time, use something like: $ git diff HEAD~ > /tmp/patch && ./contrib/check_GNU_style.py /tmp/patch Thanks, Martin hm, I am actually using GNU style with Emacs..

[PATCH 7/7] Fix test-suite fallout.

gcc/testsuite/ChangeLog: 2019-11-06 Martin Liska * gcc.dg/completion-3.c: Append = to all expected results and sort expected output. * gcc.dg/pr83620.c: Update error message. * gcc.dg/spellcheck-params-2.c: Likewise. * gcc.dg/spellcheck-params.c: Likewi

[PATCH 5/7] Remove last leftover usage of params* files.

gcc/ChangeLog: 2019-11-06 Martin Liska * common.opt: Remove param_values. * config/i386/i386-options.c (ix86_valid_target_attribute_p): Remove finalize_options_struct. * gcc.c (driver::decode_argv): Do not call global_init_params and finish_params.

[PATCH 6/7] Remove set_default_param_value from documentation.

gcc/ChangeLog: 2019-11-06 Martin Liska * common/common-target.def: Do not mention set_default_param_value and set_param_value. * doc/tm.texi: Likewise. --- gcc/common/common-target.def | 6 ++ gcc/doc/tm.texi | 4 ++-- 2 files changed, 4 inser

[PATCH 2/7] Include new generated gcc/params.opt file.

gcc/ChangeLog: 2019-11-06 Martin Liska * Makefile.in: Include params.opt. * flag-types.h (enum parloops_schedule_type): Add parloops_schedule_type used in params.opt. * params.opt: New file. --- gcc/Makefile.in | 2 +- gcc/flag-types.h | 11 + gcc/params.o

[PATCH 0/7] Param conversion to option machinery

The email thread is follow up of a demo that I made here: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02220.html The patchset converts current param infrastructure to the option machinery. The parts 3 and 4 are quite mechanical. I would appreciate a feedback about what parameters should be per

[PATCH 1/7] Param to options conversion.

gcc/ChangeLog: 2019-11-06 Martin Liska * common.opt: Remove --param and --param= options. * opt-functions.awk: Mark CL_PARAMS for options that have Param keyword. * opts-common.c (decode_cmdline_options_to_array): Replace --param key=value with --param=

Re: introduce -fcallgraph-info option

On Nov 7, 2019, Richard Biener wrote: > So how's -dumpbase handled? It's part of the gcc driver interface, and lto-wrapper passes it to gcc for -fltrans compilations. -auxbase isn't, so one of the alternatives I suggested involved our taking auxbase from dumpdir & dumpbase for -fltrans compila

[PATCH][vect] PR 92351: When peeling for alignment make alignment of epilogues unknown

Hi, PR92351 reports a bug in which a wrongly aligned load is generated for an epilogue of a main loop for which we peeled for alignment. There is no way to guarantee that epilogue data accesses are aligned when the main loop is peeling for alignment. I also had to split vect-peel-2.c as the

[Committed] IBM Z: Add pattern for load truth value of comparison into reg

The RTXs used to express an overflow condition check in add/sub/mul are too complex for if conversion. However, there is code in noce_emit_store_flag which generates a simple CC compare as the base for using a conditional load. All we have to do is to provide a pattern to store the truth value of

Re: introduce -fcallgraph-info option

On Thu, 7 Nov 2019, Alexandre Oliva wrote: > On Nov 7, 2019, Richard Biener wrote: > > > A simple test shows we currently only pass -auxbase-strip /tmp/cc...o > > to the LTRANS lto1 invocation plus -dumpbase cc...o > > This -auxbase-strip argument is introduced by the gcc driver that runs > lt

[PATCH] Fix PR92405

Bootstrapped & tested on x86_64-unknown-linux-gnu, applied. Richard. 2019-11-07 Richard Biener PR tree-optimization/92405 * tree-vect-loop.c (vectorizable_reduction): Appropriately restrict lane-reducing ops to single stmt chains. Index: gcc/tree-vect-loop.c ===

Re: introduce -fcallgraph-info option

On Nov 6, 2019, Thomas Schwinge wrote: >> which is a valid VCG file (you can launch your favorite VCG >> viewer on it unmodified) > What should be my "favorite VCG viewer"? -ENOCLUE, I'm afraid. I honestly don't even know which one Eric used back when he first attempted to contribute this fea

[committed] Remove gimple_call_types_likely_match_p (PR 70929)

Hi On Mon, Nov 04 2019, Richard Biener wrote: > On Fri, 1 Nov 2019, Martin Jambor wrote: > >> Hi, >> >> I have spent some more time looking into PR 70929, how >> gimple_check_call_matching_types behaves when LTO-building Firefox to >> see what could replace it or if we perhaps could remove it. >>

Re: introduce -fcallgraph-info option

On Nov 7, 2019, Richard Biener wrote: > A simple test shows we currently only pass -auxbase-strip /tmp/cc...o > to the LTRANS lto1 invocation plus -dumpbase cc...o This -auxbase-strip argument is introduced by the gcc driver that runs lto1, based on the -o (tmp ltrans .o) argument, but this dri

[C] Opt out of GNU vector extensions for built-in SVE types

The AArch64 port defines built-in SVE types at start-up under names like __SVInt8_t. These types are represented in the front end and gimple as normal VECTOR_TYPEs and are code-generated as normal vectors. However, we'd like to stop the frontends from treating them in the same way as GNU-style ("v

Re: [Patch][OpenMP][Fortran] Support absent optional args with use_device_{ptr,addr} (+ OpenACC's use_device clause)

Thinking about the patch over night, I have now updated it a bit: Namely, I only add the "if(present-check)" condition, if the original variable is dereferenced. There is no need for code like   omp_data_arr.c = c == NULL ? NULL : c; and then, after the libgomp call, code like "c_2 = c == NULL

[PATCH][arm][4/X] Add initial support for GE-setting SIMD32 intrinsics

Hi all, This patch adds in plumbing for the ACLE intrinsics that set the GE bits in APSR.  These are special SIMD instructions in Armv6 that pack bytes or halfwords into the 32-bit general-purpose registers and set the GE bits in APSR to indicate if some of the "lanes" of the result have overflow

[PATCH][arm][5/X] Implement Q-bit-setting SIMD32 intrinsics

Hi all, This patch implements some more Q-setting intrinsics of the multiply-accumulate variety, but these are in the SIMD32 family in that they treat their operands as packed SIMD values, but that's not important at the RTL level. Bootstrapped and tested on arm-none-linux-gnueabihf. Committ

[PATCH][arm][6/X] Add support for __[us]sat16 intrinsics

Hi all, This last patch adds the the __ssat16 and __usat16 intrinsics that perform "clipping" to a particular bitwidth on packed SIMD values, setting the Q bit as appropriate. Bootstrapped and tested on arm-none-linux-gnueabihf. Committing to trunk. Thanks, Kyrill 2019-11-07  Kyrylo Tkachov 

[PATCH][arm][3/X] Implement __smla* intrinsics (Q-setting)

Hi all, This patch implements some more Q-setting intrinsics form the SMLA* group. These can set the saturation bit on overflow in the accumulation step. Like earlier, these have non-Q-setting RTL forms as well for when the Q-bit read is not needed. Bootstrapped and tested on arm-none-linux-gn

[PATCH][arm][2/X] Implement __qadd, __qsub, __qdbl intrinsics

Hi all, This patch implements some more Q-bit-setting intrinsics from ACLE. With the plumbing from patch 1 in place they are a simple builtin->RTL affair. Bootstrapped and tested on arm-none-linux-gnueabihf. Committing to trunk. Thanks, Kyrill 2019-11-07  Kyrylo Tkachov      * config/arm/a

[PATCH][arm][1/X] Add initial support for saturation intrinsics

Hi all, This patch adds the plumbing for and an implementation of the saturation intrinsics from ACLE [1], in particular the __ssat, __usat intrinsics. These intrinsics set the Q sticky bit in APSR if an overflow occurred. ACLE allows the user to read that bit (within the same function, it's not

Re: [PATCH rs6000]Fix PR92132

Hi Segher, on 2019/11/7 上午7:49, Segher Boessenkool wrote: > > The expander named "one_cmpl3": > > Erm. 2, not 3 :-) > > (define_expand "one_cmpl2" > [(set (match_operand:BOOL_128 0 "vlogical_operand") > (not:BOOL_128 (match_operand:BOOL_128 1 "vlogical_operand")))] > "" > "") >

[PATCH] Add OpenACC 2.6 `serial' construct support

Hi, this patch implements the OpenACC 2.6 "serial" construct. It has been tested by running the testsuite with nvptx-none offloading on x86_64-pc-linux-gnu. Best regards, Frederik 8< --- The `serial' construct (cf. section 2.5.3 of the OpenACC 2.6 standa

Re: [PATCH target/92295] Fix inefficient vector constructor

On Thu, Nov 7, 2019 at 7:58 AM Hongtao Liu wrote: > > Ping! OK. Thanks, Richard. > On Sat, Nov 2, 2019 at 9:38 PM Hongtao Liu wrote: > > > > Hi Jakub: > > Could you help reviewing this patch. > > > > PS: Since this patch is related to vectors(avx512f), and Uros > > mentioned before that he h

Re: [patch][avr] PR92055: Add switches to enable 64-bit [long] double.

Hello. I've noticed quite some GNU coding style violations with your patch. Please next time, use something like: $ git diff HEAD~ > /tmp/patch && ./contrib/check_GNU_style.py /tmp/patch Thanks, Martin

Re: Generalise gather and scatter optabs

On Wed, Nov 6, 2019 at 5:06 PM Richard Sandiford wrote: > > The gather and scatter optabs required the vector offset to be > the integer equivalent of the vector mode being loaded or stored. > This patch generalises them so that the two vectors can have different > element sizes, although they sti

  1   2   >