Re: [PATCH] Refactor rust-demangle to be independent of C++ demangling.

On Fri, Nov 8, 2019, at 7:43 PM, Ian Lance Taylor wrote: > On Fri, Nov 8, 2019 at 9:02 AM Eduard-Mihai Burtescu wrote: > > > > Ping #2 for https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01830.html > > Original patch (without the early exit optimization): > >

Re: [PATCH, GCC] Fix unrolling check.

> I was fiddling around with the loop unrolling pass and noticed a check > in decide_unroll_* functions (in the patch). The comment on top of this > check says > "/* If we were not asked to unroll this loop, just return back silently. > */" > However the check returns when loop->unroll == 0

Backports to gcc-9-branch

Hi! I've backorted following 10 patches from trunk to 9 branch, bootstrapped/regtested them on x86_64-linux and i686-linux and committed. Jakub 2019-11-08 Jakub Jelinek Backported from mainline 2019-10-21 Jakub Jelinek PR c++/92015 * constexpr.c

C++ PATCH for c++/88337 - Implement P1327R1: Allow dynamic_cast in constexpr

After much weeping and gnashing of teeth, here's a patch to handle dynamic_cast in constexpr evaluation. While the change in the standard is trivial (see ), the change in the compiler is less so. When build_dynamic_cast

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

On Fri, Nov 08, 2019 at 12:05:19AM +0100, Egeyar Bagcioglu wrote: > On 11/7/19 7:57 PM, Segher Boessenkool wrote: > >>>Opening a file as "r" but then > >>>accessing it with "fread" is peculiar, too. > >>I am not sure what you mean here. Is it that you prefer "wb" and "rb" > >>instead of "w" and

[PATCH, GCC] Fix unrolling check.

Hi I was fiddling around with the loop unrolling pass and noticed a check in decide_unroll_* functions (in the patch). The comment on top of this check says "/* If we were not asked to unroll this loop, just return back silently. */" However the check returns when loop->unroll == 0 rather

Re: [PATCH rs6000]Fix PR92132

Hi! On Fri, Nov 08, 2019 at 10:38:13AM +0800, Kewen.Lin wrote: > >> + [(set (match_operand: 0 "vint_operand") > >> + (match_operator 1 "comparison_operator" > > > > If you make an iterator for this instead, it is simpler code (you can then > > use to do all these cases in one statement). >

Re: [PATCH, Fortran] Allow CHARACTER literals in assignments and DATA statements

On Fri, Nov 08, 2019 at 11:17:21AM +0100, Tobias Burnus wrote: > >     Jim MacArthur  > >     Mark Eggleston  > > > >     * arith.c (hollerith2representation): Use OPT_Wcharacter_truncation > > in > >     call to gfc_warning.  Add character2representation, > > gfc_character2int, > >    

[COMMITTED] Change fold_range() and wi_fold() to return the result via reference parameter.

The call to range_operator::fold_range() and wi_fold() originally returned the resulting range in a reference parameter.  When prepping for trunk,  we got excited about something else and I changed it to return the result by value. As we move towards multiple sub-ranges in value_range, I 

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

This is the C++ equivalent of r277950, which prevented the use of the GNU vector extensions with SVE vector types for C. [https://gcc.gnu.org/viewcvs/gcc?view=revision=277950]. I've copied the rationale below for reference. The changes here are very similar to the C ones. Perhaps the only

[PATCH] Fix PR c++/92365

Hi, this fixes an unexprected fallout from my previous patch on the -Wshadow=complatible-local. By using can_convert_arg here, it avoids the issue, that can_convert tries to cast int() to char*, which is a a possible NULL-pointer value in C++98 (but not in C++11). As pointed out in the PR,

Re: [PATCH] Refactor rust-demangle to be independent of C++ demangling.

Ping #2 for https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01830.html Original patch (without the early exit optimization): https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01591.html Thanks, - Eddy B. On Wed, Oct 30, 2019, at 6:46 PM, Eduard-Mihai Burtescu wrote: > Ping:

Re: [PATCH] Refactor rust-demangle to be independent of C++ demangling.

On Fri, Nov 8, 2019 at 11:17 AM Eduard-Mihai Burtescu wrote: > > On Fri, Nov 8, 2019, at 7:43 PM, Ian Lance Taylor wrote: > > On Fri, Nov 8, 2019 at 9:02 AM Eduard-Mihai Burtescu wrote: > > > > > > Ping #2 for https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01830.html > > > Original patch (without

Re: [PATCH] include size and offset in -Wstringop-overflow

On 11/6/19 2:06 PM, Martin Sebor wrote: On 11/6/19 1:39 PM, Jeff Law wrote: On 11/6/19 1:27 PM, Martin Sebor wrote: On 11/6/19 11:55 AM, Jeff Law wrote: On 11/6/19 11:00 AM, Martin Sebor wrote: The -Wstringop-overflow warnings for single-byte and multi-byte stores mention the amount of data 

[PATCH][GCC][arm] Add CLI and multilib support for Armv8.1-M Mainline MVE extensions

Hi, This patch adds CLI and multilib support for Armv8.1-M MVE to the Arm backend. Two new option added for v8.1-m.main: "+mve" for integer MVE instructions only and "+mve.fp" for both integer and single-precision/half-precision floating-point MVE. The patch also maps the Armv8.1-M multilib

Re: [PATCH] Refactor rust-demangle to be independent of C++ demangling.

On Fri, Nov 8, 2019 at 9:02 AM Eduard-Mihai Burtescu wrote: > > Ping #2 for https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01830.html > Original patch (without the early exit optimization): > https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01591.html Sorry for letting this slide. Do we need the

Re: [PATCH, Fortran] Allow CHARACTER literals in assignments and DATA statements

On Fri, Nov 08, 2019 at 11:17:21AM +0100, Tobias Burnus wrote: > >     Jim MacArthur > >     Mark Eggleston > > > >     PR fortran/89103 > >     * gfortran.dg/dec_char_conversion_in_assignment_1.f90: New test. > >     * gfortran.dg/dec_char_conversion_in_assignment_2.f90: New test. > >     *

[PATCH] Fix ICE during gimple resimplification (PR tree-optimization/92401)

Hi! On the following testcase we ICE, because gimple_resimplify3 is called on a CONSTRUCTOR with 3 elements, which is fine, but it calls fold_ternary which works only on expression codes with TREE_CODE_LENGTH of 3. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for

Add C2x *_NORM_MAX constants to

C2x adds constants FLT_NORM_MAX, DBL_NORM_MAX and LDBL_NORM_MAX. These are for the maximum "normalized" finite floating-point number, where the given definition of normalized is that all possible values with MANT_DIG significand digits (leading one not zero) can be represented with that

Re: [PATCH 1/5] Libsanitizer: merge from trunk with merge.sh.

On 11/5/19, Jakub Jelinek wrote: > On Mon, Nov 04, 2019 at 04:10:27PM +0100, Martin Liska wrote: >> >> libsanitizer/ChangeLog: >> >> 2019-11-05 Martin Liska >> >> * all source files: Merge from upstream r375507. >> --- >> libsanitizer/BlocksRuntime/Block.h| 59 + >>

Implement the part of C++20 p1032 Misc constexpr bits.

I'm going to implement p1032 in pieces. It *is* miscellaneous after all ;-). Tested on x96_64-linux? OK? 2019-11-09 Edward Smith-Rowland <3dw...@verizon.net> Implement the part of C++20 p1032 Misc constexpr bits. * include/std/array (fill, swap): Make constexpr. *

[committed] Fix various spelling errors in cgraph, tree-ssa-strlen and ipa-sra

Hi! While trying to read cgraph.h to find out how to enhance it to deal with declare variant, I've noticed a couple of spelling errors, enough that I ran aspell -c on a couple of sources (obviously, it flags a lot of issues which are non-issues, so most of time I have to press I). This only fixes

[PATCH] OpenACC "present" subarrays: runtime API return value and unmapping fixes

Hi, This patch fixes an issue I noticed when investigating an answer for Thomas's question about device pointer return values in: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02260.html It looks to me like the return value for the present case is wrong in the existing code: in case of a

Re: [PATCH] OpenACC reference count overhaul

On Thu, 31 Oct 2019 19:11:57 +0100 Thomas Schwinge wrote: > Hi Julian! > > On 2019-10-29T12:15:01+, Julian Brown > wrote: > > This is a new version of the patch which hopefully addresses all > > review comments. Further commentary below. > > Thanks, great, looking into that one -- I see

Implement the part of C++20 p1032 Misc constexpr bits.

Here is the part of C++20 p1032 Misc constexpr bits. Tested on x86_64-linux. OK? Ed 2019-11-09 Edward Smith-Rowland <3dw...@verizon.net> Implement the part of C++20 p1032 Misc constexpr bits. * include/std/tuple (_Head_base, _Tuple_impl(allocator_arg_t,...), _M_assign,

[C++ COMMITTED] Add test for c++/92058

Another test for the constinit issue I fixed recently (c++/92134). Tested on x86_64-linux, applying to trunk. 2019-11-08 Marek Polacek PR c++/92058 - constinit malfunction in static data member. * g++.dg/cpp2a/constinit15.C: New test. diff --git

Re: introduce -fcallgraph-info option

On 11/8/19, Richard Biener wrote: > On Thu, 7 Nov 2019, Alexandre Oliva wrote: > >> 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,

[PATCH] libgomp/test: Add flags to find libatomic in build-tree testing

Add flags to find libatomic in build-tree testing, fixing a catastrophic libgomp testsuite failure with targets such as `riscv-linux-gnu' that imply `-latomic' with the `-pthread' GCC option, implied in turn by the offload options, removing failures like: .../bin/riscv64-linux-gnu-ld: cannot

[RFC, libstdc++] Implement C++20 P1208R6 - source_location.

As an experiment, I took a shot at implementing source_location for C++20.?? This was mostly done in experimental but I wanted to try adding column information.?? (The experimental version just returned 0).?? I added __builtin_COLUMN in analogy to __builtin_LINE.?? The std version is also

[PATCH] extend -Wstringop-overflow to allocated objects (PR 91582)

Unless it's used with _FORTIFY_SOURCE, -Wstringop-overflow doesn't consider out-of-bounds accesses to objects allocated by alloca, malloc, other functions declared with attribute alloc_size, or even VLAs with variable bounds. This was a known limitation of the checks (done just before expansion)

[Darwin, committed] Add include guard to darwin-protos.h

The Darwin protos header is missing an include guard, this adds one. tested on x86_64-darwin16 applied to mainline thanks Iain gcc/ChangeLog: 2019-11-08 Iain Sandoe * config/darwin-protos.h: Add include quard. diff --git a/gcc/config/darwin-protos.h b/gcc/config/darwin-protos.h

Re: [PATCH] Fix ICE during gimple resimplification (PR tree-optimization/92401)

On November 9, 2019 1:07:18 AM GMT+01:00, Jakub Jelinek wrote: >Hi! > >On the following testcase we ICE, because gimple_resimplify3 is called >on a CONSTRUCTOR with 3 elements, which is fine, but it calls >fold_ternary >which works only on expression codes with TREE_CODE_LENGTH of 3. > >Fixed

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

Hi Jiu Fu, On Thu, Nov 07, 2019 at 10:40:41PM +0800, Jiufu Guo wrote: > gcc/ > 2019-11-07 Jiufu Guo > > PR tree-optimization/88760 > * gcc/config/rs6000/rs6000.opt (-munroll-only-small-loops): New option. > * gcc/common/config/rs6000/rs6000-common.c >

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

On Fri, Nov 08, 2019 at 04:41:23PM +0100, Tobias Burnus wrote: > With DECL_ARTIFICIAL added and also_value replaced: > Build on x86-64-gnu-linux. OK once regtested? Almost. > - gimplify_assign (x, var, ); > + if (do_optional_check && omp_check_optional_argument (ovar, true)) Do

Re: [PATCH] Fix PR92324

Richard Biener writes: > On Fri, 8 Nov 2019, Richard Sandiford wrote: > >> Richard Biener writes: >> > I've been sitting on this for a few days since I'm not 100% happy >> > with how the code looks like. There's possibly still holes in it >> > (chains with mixed signed/unsigned adds for example

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

On 2019-11-07 12:28 p.m., Kwok Cheung Yeung wrote: 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

[patch,avr] Add suport for devices from the 0-series.

Hi, this patch adds support for a few more AVR devices. Because the offset where flash is seen in RAM deviates from the settings for the family (and hence also from the linker script defaults), a new field in avr_mcu_t is needed to express this so that specs can be generated appropriately.

Fix SLP downward group access classification (PR92420)

This PR was caused by the SLP handling in get_group_load_store_type returning VMAT_CONTIGUOUS rather than VMAT_CONTIGUOUS_REVERSE for downward groups. A more elaborate fix would be to try to combine the reverse permutation into SLP_TREE_LOAD_PERMUTATION for loads, but that's really a follow-on

Re: [PATCH] Fix PR92324

On Fri, 8 Nov 2019, Richard Sandiford wrote: > Richard Biener writes: > > I've been sitting on this for a few days since I'm not 100% happy > > with how the code looks like. There's possibly still holes in it > > (chains with mixed signed/unsigned adds for example might pick > > up signed adds

[PATCH] gdbinit.in: call a function with "call", not "set"

Last time a command that calls a function of debuggee with "set" was added is 2013 year. Apparently something has changed since then, since doing "set foo()" in gdb to call a "foo()" results in error. Disregarding, it looks wrong to call a function with "set". Let's use "call" instead.

[SPARC] Fix PR target/92095

. (sparc_init_pic_reg): In PIC mode, always initialize the PIC register if optimization is enabled. * config/sparc/sparc.md (load_pcrel_sym): Emit the assembly by calling output_load_pcrel_sym. 2019-11-08 Eric Botcazou * gcc.c-torture/compile/20191108-1.c: New test

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

On Fri, 8 Nov 2019, Richard Sandiford wrote: > Richard Biener writes: > > On Thu, 7 Nov 2019, Andre Vieira (lists) wrote: > >> 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

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

On Fri, 08 Nov 2019 09:07:39 +0900 Oleg Endo wrote: > 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

[PATCH] Fix PR92324

I've been sitting on this for a few days since I'm not 100% happy with how the code looks like. There's possibly still holes in it (chains with mixed signed/unsigned adds for example might pick up signed adds in the epilogue), but the wrong-code cases should work fine now. I'm probably going

[committed] Handle POLY_INT_CSTs in declare_return_value

SVE allows variable-length vectors to be returned by value, which tripped the assert in declare_return_variable. Tested on aarch64-linux-gnu and x86_64-linux-gnu. Applied as obvious/ preapproved by Jeff some time ago for this kind of change. Richard 2019-11-08 Richard Sandiford gcc/

Re: Free some more stuff in free_lang_data

On Thu, 7 Nov 2019, Jan Hubicka wrote: > 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

[PATCH] Use op->resimplify from genmatch

Allows more refactoring here. Bootstrapped/tested on x86_64-unknown-linux-gnu, applied. Richard. 2019-11-08 Richard Biener * genmatch.c (expr::gen_transform): Use the resimplify member function instead of hard-coding the gimple_resimplifyN variant.

Re: [PATCH] Ensure x86_64 TYPE_EMPTY_P args have distinct addresses (PR c++/92384)

On Thu, 7 Nov 2019, Jakub Jelinek wrote: > Hi! > > TYPE_EMPTY_P arguments (which right now only x86_64 uses) have > data->entry_parm == data->stack_parm being a stack slot with zero size in > the stack parameter passing area. > The problem with that is that in C++ they should have distinct

Re: Mark constant-sized objects as addressable if they have poly-int accesses

On Fri, Nov 8, 2019 at 10:40 AM Richard Sandiford wrote: > > If SVE code is written for a specific vector length, it might load from > or store to fixed-sized objects. This needs to work even without > -msve-vector-bits=N (which should never be needed for correctness). > > There's no way of

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

On Thu, 2019-11-07 at 21:31 +, Jozef Lawrynowicz wrote: > 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, >

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

Richard Biener writes: > On Thu, Nov 7, 2019 at 6:15 PM Richard Sandiford > wrote: >> >> 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: >> >>

[PATCH] Fix PR92088

The following works around a middle-end limitation not being able to deal with by value-passing of VLAs transparently during inlining (but only DECL_BY_REFERENCE is handled) in the C frontend by marking said functions as not inlinable. This avoids ICEs later. Bootstrapped and tested on

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

Richard Biener writes: > On Thu, 7 Nov 2019, Andre Vieira (lists) wrote: >> 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

Re: Fix code order in tree-sra.c:create_access

On Fri, Nov 8, 2019 at 12:04 PM Martin Jambor wrote: > > Hi, > > On Fri, Nov 08 2019, Richard Sandiford wrote: > > If get_ref_base_and_extent returns poly_int offsets or sizes, > > tree-sra.c:create_access prevents SRA from being applied to the base. > > However, we haven't verified by that point

[RFC] Only warn for maybe-uninitialized SRAed bits in -Wextra (PR 80635)

Hi, this patch is an attempt to implement my idea from a previous thread about moving -Wmaybe-uninitialized to -Wextra: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00220.html Specifically, it attempts to split -Wmaybe-uninitialized into those that are about SRA DECLs and those which are not,

Re: [PATCH, nvptx] Expand OpenACC child function arguments to use CUDA params space

On 2019/10/8 10:05 PM, Thomas Schwinge wrote: Hi Chung-Lin! While we're all waiting for Tom to comment on this;-) -- here's another item I realized: On 2019-09-10T19:41:59+0800, Chung-Lin Tang wrote: The libgomp nvptx plugin changes are also quite contained, with lots of now unneeded [...]

[PATCH] Debug counter for IVOPTs

Bootstrapped / tested on x86_64-unknwon-linux-gnu, applied. Richard. 2019-11-08 Richard Biener * dbgcnt.def (ivopts_loop): Add. * tree-ssa-loop-ivopts.c (tree_ssa_iv_optimize): Check ivopts_loop before optimizing a loop. Index: gcc/dbgcnt.def

[PATCH] Fix PR92409

The following fixes an ICE with the recent relaxing of type constraints for inlining. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2019-11-08 Richard Biener PR ipa/92409 * tree-inline.c (declare_return_variable): Properly handle type

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

On Fri, 08 Nov 2019 21:14:19 +0900 Oleg Endo wrote: > On Thu, 2019-11-07 at 21:31 +, Jozef Lawrynowicz wrote: > > 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

Re: introduce -fcallgraph-info option

On Thu, 7 Nov 2019, Alexandre Oliva wrote: > 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

[committed] Handle POLY_INT_CST in copy_reference_ops_from_ref

Tested on aarch64-linux-gnu and x86_64-linux-gnu. Applied as obvious. Richard 2019-11-08 Richard Sandiford gcc/ * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Handle POLY_INT_CST. gcc/testsuite/ * gcc.target/aarch64/sve/acle/general/deref_2.c: New test.

[PATCH] Rename identifiers in a test-case.

Hi. I renamed identifiers and reformatted the test-case. I'm going to install the patch. Martin gcc/testsuite/ChangeLog: 2019-11-08 Martin Liska * g++.dg/pr92339.C: Rename identifiers to something more readable. --- gcc/testsuite/g++.dg/pr92339.C | 19 ++-

Re: [PATCH, Fortran] Allow CHARACTER literals in assignments and DATA statements

On 11/8/19 10:45 AM, Mark Eggleston wrote: PING - OK, to commit? I have a pending patch that needs this in place. Thanks for the ping. — Any chance, that you also work on some of the general issues once in a while (cf. Bugzilla remark below); e.g. one bug per week or fortnight? (Can be a

[PATCH 5/6] arm: Add testsuite checks for asm-flag

Inspired by the tests in gcc.target/i386. Testing code generation, diagnostics, and execution. * gcc.target/arm/asm-flag-1.c: New test. * gcc.target/arm/asm-flag-3.c: New test. * gcc.target/arm/asm-flag-5.c: New test. * gcc.target/arm/asm-flag-6.c: New test. ---

[PATCH 6/6] aarch64: Add testsuite checks for asm-flag

Inspired by the tests in gcc.target/i386. Testing code generation, diagnostics, and execution. * gcc.target/aarch64/asm-flag-1.c: New test. * gcc.target/aarch64/asm-flag-3.c: New test. * gcc.target/aarch64/asm-flag-5.c: New test. * gcc.target/aarch64/asm-flag-6.c:

[committed][AArch64] Don't handle bswap in aarch64_builtin_vectorized_function

aarch64_builtin_vectorized_function no longer needs to handle bswap* since we have internal functions and optabs for all supported cases. Tested on aarch64-linux-gnu and applied as r277951. Richard 2019-11-08 Richard Sandiford gcc/ * config/aarch64/aarch64-builtins.c

[C++ PATCH] Fix error-recovery with constexpr dtor (PR c++/92414)

Hi! We ICE on the following testcase, because DECL_INITIAL (decl) is error_mark_node due to previously reported error and cxx_eval_outermost_constant_expr is unhappy if ctx.ctor is not a CONSTRUCTOR, but error_mark_node. If the initializer is invalid, it should have been diagnosed already and

Fix code order in tree-sra.c:create_access

If get_ref_base_and_extent returns poly_int offsets or sizes, tree-sra.c:create_access prevents SRA from being applied to the base. However, we haven't verified by that point that we have a valid base to disqualify. This originally led to an ICE on the attached testcase, but it no longer triggers

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

On Thu, 7 Nov 2019, Jakub Jelinek wrote: > 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

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

On Thu, 7 Nov 2019, Andre Vieira (lists) wrote: > > > 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

Re: [PATCH 4/6] arm, aarch64: Add support for __GCC_ASM_FLAG_OUTPUTS__

On 11/8/19 11:54 AM, Richard Henderson wrote: > +@table @code > +@item eq > +``equal'' or Z flag set > +@item ne > +``not equal'' or Z flag clear > +@item cs > +``carry'' or C flag set > +@item cc > +C flag clear > +@item mi > +``minus'' or N flag set > +@item pl > +``plus'' or N flag clear >

Re: Fix code order in tree-sra.c:create_access

Hi, On Fri, Nov 08 2019, Richard Sandiford wrote: > If get_ref_base_and_extent returns poly_int offsets or sizes, > tree-sra.c:create_access prevents SRA from being applied to the base. > However, we haven't verified by that point that we have a valid base > to disqualify. > > This originally led

[committed][AArch64] Remove unused mode iterators

Tested on aarch64-linux-gnu, applied as r277953. Richard 2019-11-08 Richard Sandiford gcc/ * config/aarch64/iterators.md (SVE_BH, SVE_BHS): Delete. Index: gcc/config/aarch64/iterators.md === ---

Re: [PATCH] Fix PR92324

Richard Biener writes: > I've been sitting on this for a few days since I'm not 100% happy > with how the code looks like. There's possibly still holes in it > (chains with mixed signed/unsigned adds for example might pick > up signed adds in the epilogue), but the wrong-code cases should > work

[PATCH 4/6] arm, aarch64: Add support for __GCC_ASM_FLAG_OUTPUTS__

Since all but a couple of lines is shared between the two targets, enable them both at once. * config/arm/aarch-common-protos.h (arm_md_asm_adjust): Declare. * config/arm/aarch-common.c (arm_md_asm_adjust): New. * config/arm/arm-c.c (arm_cpu_builtins): Define

[PATCH 3/6] arm: Rename CC_NOOVmode to CC_NZmode

CC_NZmode is a more accurate description of what we require from the mode, and matches up with the definition in aarch64. Rename noov_comparison_operator to nz_comparison_operator in order to match. * config/arm/arm-modes.def (CC_NZ): Rename from CC_NOOV. *

[PATCH 2/6] arm: Fix the "c" constraint

The existing definition using register class CC_REG does not work because CC_REGNUM does not support normal modes, and so fails to match register_operand. Use a non-register constraint and the cc_register predicate instead. * config/arm/constraints.md (c): Use cc_register predicate. ---

[PATCH 0/6] Implement asm flag outputs for arm + aarch64

I've put the implementation into config/arm/aarch-common.c, so that it can be shared between the two targets. This required a little bit of cleanup to the CC modes and constraints to get the two targets to match up. I really should have done more than just x86 years ago, so that it would be done

[PATCH 1/6] aarch64: Add "c" constraint

Mirror arm in letting "c" match the condition code register. * config/aarch64/constraints.md (c): New constraint. --- gcc/config/aarch64/constraints.md | 4 1 file changed, 4 insertions(+) diff --git a/gcc/config/aarch64/constraints.md b/gcc/config/aarch64/constraints.md index

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

On Thu, Nov 7, 2019 at 6:15 PM Richard Sandiford wrote: > > 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

LRA: handle memory constraints that accept more than "m"

LRA allows address constraints that are more relaxed than "p": /* Target hooks sometimes don't treat extra-constraint addresses as legitimate address_operands, so handle them specially. */ if (insn_extra_address_constraint (cn) && satisfies_address_constraint_p (, cn)) return

Mark constant-sized objects as addressable if they have poly-int accesses

If SVE code is written for a specific vector length, it might load from or store to fixed-sized objects. This needs to work even without -msve-vector-bits=N (which should never be needed for correctness). There's no way of handling a direct poly-int sized reference to a fixed-size register; it

Re: [PATCH, Fortran] Allow CHARACTER literals in assignments and DATA statements

PING - OK, to commit? I have a pending patch that needs this in place. On 05/11/2019 09:55, Mark Eggleston wrote: On 25/10/2019 09:03, Tobias Burnus wrote: Hello Mark, hi all, On 10/21/19 4:40 PM, Mark Eggleston wrote: This is an extension to support a legacy feature supported by other

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

On Thu, Nov 7, 2019 at 5:40 PM Richard Sandiford wrote: > > 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

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

Hi Jakub, thanks for the review. On 11/8/19 3:39 PM, Jakub Jelinek wrote: + /* Walk function argument list to find the hidden arg. */ + decl = DECL_ARGUMENTS (DECL_CONTEXT (decl)); + for ( ; decl != NULL_TREE; decl = TREE_CHAIN (decl)) + if (DECL_NAME (decl) == tree_name)

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

On Fri, 2019-11-08 at 13:27 +, Jozef Lawrynowicz wrote: > > Yes, I should have used -flto in my examples. But it doesn't help remove these > CRT library functions which are normally either directly added to the > list of functions to run before main (via .init, .ctors or .init_array) or >

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

On Thu, Nov 07, 2019 at 11:42:22AM +0100, Tobias Burnus wrote: > + /* For VALUE, the scalar variable is passed as is but a hidden argument > + denotes the value. Cf. trans-expr.c. */ > + if (TREE_CODE (TREE_TYPE (decl)) != POINTER_TYPE) > +{ > + char name[GFC_MAX_SYMBOL_LEN + 2];

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

On Fri, 08 Nov 2019 22:59:18 +0900 Oleg Endo wrote: > On Fri, 2019-11-08 at 13:27 +, Jozef Lawrynowicz wrote: > > > > Yes, I should have used -flto in my examples. But it doesn't help remove > > these > > CRT library functions which are normally either directly added to the > > list of

Re: [PATCH, Fortran] Allow CHARACTER literals in assignments and DATA statements

On Fri, Nov 08, 2019 at 11:17:21AM +0100, Tobias Burnus wrote: > Additionally, there are several recent reports on segfaults and > regressions, looking Bugzilla (component = fortran, sort by change data). > Easiest way to find open gfortran bugs is through the gfortran wiki.

[PATCH][vect]Account for epilogue's peeling for gaps when checking if we have enough niters for epilogue

Hi, As I mentioned in the patch to disable epilogue vectorization for loops with SIMDUID set, there were still some aarch64 libgomp failures. This patch fixes those. The problem was that we were vectorizing a reduction that was only using one of the parts from a complex number, creating

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

OK, let's keep the macros district then. In the kernel it doesn't give you a lot, since you actually know which ASAN you're using based on the kernel CONFIG_ values, but looks like it's important for userspace. Thanks! On Thu, Nov 7, 2019 at 7:01 PM Evgenii Stepanov wrote: > > Clang has a

[PATCH] rs6000: Fix branch_comparison_operator

Another part I forgot yesterday. With this, everything is back to normal. Committing. Segher 2019-11-08 Segher Boessenkool * config/rs6000/predicates.md (branch_comparison_operator): Allow only the comparison codes that make sense for the mode used, and only the