Re: introduce -fcallgraph-info option

On Fri, 15 Nov 2019, Alexandre Oliva wrote: > On Nov 14, 2019, Alexandre Oliva wrote: > > > %{!c:%{!S:-dumpbase %b} > > Uhh, I failed to adjust this one to add the executable output name to > dumpbase. > > Anyway, getting the right semantics out of specs is providing to be a > lot trickier

Re: [Patch] [mid-end][__RTL] Clean df state despite invalid __RTL startwith passes

On Thu, 14 Nov 2019, Matthew Malcomson wrote: > Hi there, > > When compiling an __RTL function that has an invalid "startwith" pass we > currently don't run the dfinish cleanup pass. This means we ICE on the next > function. > > This change ensures that all state is cleaned up for the next

Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures

Hi Thomas, On 11/11/19 10:55 PM, Thomas König wrote: the attached patch loads scalar INTENT(IN) variables to a local variable at the start of a procedure, as suggested in PR 67202, in order to aid optimization.  This is controlled by front-end optimization so it is easier to catch if any bugs

Re: introduce -fcallgraph-info option

On Nov 14, 2019, Alexandre Oliva wrote: > %{!c:%{!S:-dumpbase %b} Uhh, I failed to adjust this one to add the executable output name to dumpbase. Anyway, getting the right semantics out of specs is providing to be a lot trickier than I had anticipated. I'm now pondering a single spec function

Re: [PATCH] PR92398: Fix testcase failure of pr72804.c

On 2019/11/15 11:12, Xiong Hu Luo wrote: P9LE generated instruction is not worse than P8LE. mtvsrdd;xxlnot;stxv vs. not;not;std;std. Update the test case to fix failures. gcc/testsuite/ChangeLog: 2019-11-15 Luo Xiong Hu testsuite/pr92398 *

Go patch committed: Fix inlining of sink names

This Go frontend patch by Than McIntosh fixes inlining of sink names. When the compiler writes an inlinable function to the export data, parameter names are written out (in Export::write_name) using the Gogo::message_name as opposed to a raw/encoded name. This means that sink parameters (those

[PATCH] PR92398: Fix testcase failure of pr72804.c

P9LE generated instruction is not worse than P8LE. mtvsrdd;xxlnot;stxv vs. not;not;std;std. Update the test case to fix failures. gcc/testsuite/ChangeLog: 2019-11-15 Luo Xiong Hu testsuite/pr92398 * gcc.target/powerpc/pr72804.h: New. *

Re: [PATCH] Add support for C++2a stop_token

Tested x86_64-pc-linux-gnu, committed to trunk. Jonathan Wakely writes: > On 13/11/19 17:59 -0800, Thomas Rodgers wrote: >>+/** @file include/stop_token >>+ * This is a Standard C++ Library header. >>+ */ >>+ >>+#ifndef _GLIBCXX_STOP_TOKEN >>+#define _GLIBCXX_STOP_TOKEN >>+ >>+#if __cplusplus

Improve checks on C2x fallthrough attribute

When adding C2x attribute support, some [[fallthrough]] support appeared as a side-effect because of code for that attribute going through separate paths from the normal attribute handling. However, going through those paths without the normal attribute handlers meant that certain checks, such as

Re: introduce -fcallgraph-info option

On Nov 8, 2019, Eric Gallager wrote: > If you're touching the -auxbase option... is that related to the other > options starting with -aux at all? 'fraid they're entirely unrelated. We're talking about how the compiler names aux and dump output files, which is not related with the contents of

Re: introduce -fcallgraph-info option

On Nov 8, 2019, Richard Biener wrote: > Wow, thanks for the elaborate write-up! I wonder if we can > cut this into documentation somewhere appropriate, maybe > there's already a section for "auxiliary compiler outputs". Sure, that makes sense. >> I'm a little hesitant, this amounts to quite

[PATCH], V8, #6 of #6, Testsuite: Test -fstack-protect-strong works with prefixed addressing

This patch checks whether the -fstack-protect-strong option works with a large stack frame on -mcpu=future systems where prefixed instructions are generated. Can I check this into the FSF trunk? 2019-11-14 Michael Meissner * gcc.target/powerpc/prefix-stack-protect.c: New test to make

[PATCH], V8, #5 of 6, Testsuite: Test PC-relative load/store instructions

This patch adds tests for using the PC-relative addressing on the 'future' system. Can I check this patch into the FSF trunk after the patch in the V7 series that enables PC-relative addressing by default on 64-bit Linux systems has been commited? 2019-11-14 Michael Meissner *

[PATCH], V8, #4 of 6, Testsuite: Test for prefixed instructions with large offsets

This patch tests whether using large numeric offsets causes prefixed loads or stores to be generated. Can I check this patch into the FSF trunk? 2019-11-14 Michael Meissner * gcc/testsuite/gcc.target/powerpc/prefix-large.h: New set of tests to test prefixed addressing on

[PATCH], V8, #3 of 6, Testsuite: Insure no prefixed instruction uses update addressing

The prefixed instructions do not support the update form of the memory instruction (i.e. internally this is addresses using PRE_INC, PRE_DEC, or PRE_MODIFY). Can I check this into the FSF trunk? 2019-11-14 Michael Meissner * gcc.target/powerpc/prefix-premodify.c: New test to make

[PATCH], V8, #2 of 6, Testsuite: Test illegal DS/DQ offsets become prefixed insns

This test tests whether traditional DS and DQ instructions that require the bottom 2 bits of the offset to be zero (DS) or the bottom 4 of the offset to be zero (DQ) properly generate the prefixed form of the instruction instead of loading the offset into a GPR and doing an indexed memory

[PATCH], V8, #1 of 6, Tessuite: Add PADDI tests

This patch adds 3 tests that tests whether PLI (PADDI) is generated to load up DImode constants, load up SImode constants, and adding 34-bit constants. Once the appropriate patches to generate this code have been checked in (V7, #1-3), can I check these new tests into the FSF trunk? 2019-11-14

PowerPC V8 testsuite patches

After the V7 patches have been processed, these patches add various tests for new features with -mcpu=future. If we don't apply the last patch of V7 (that sets the defaults for 64-bit Linux to enable both prefixed and PC-relative addressing when -mcpu=future is used), some of these patches may

Support C2x [[deprecated]] attribute

This patch adds support for the C2x [[deprecated]] attribute. All the actual logic for generating warnings can be identical to the GNU __attribute__ ((deprecated)), as can the attribute handler, so this is just a matter of wiring things up appropriately and adding the checks specified in the

Re: Use known value ranges while evaluating ipa predicates

On Tue, Nov 12, 2019 at 02:03:32PM +0100, Jan Hubicka wrote: > this implements use of value ranges in ipa-predicates so inliner know > when some tests are going to be removed (especially NULL pointer > checks). > > Bootstrapped/regtested x86_64-linux. Martin, I would apprechiate if you > look on

[PATCH], V7, #7 of 7, Turn on -mpcrel for Linux 64-bit, but not for other targets

This patch will enable prefixed addressing and PC-relative addressing if the OS target support indicates that the OS supports either prefixed addressing and whether it supports PC-relative addressing when the user uses -mcpu=future. At the moment, 64-bit Linux is the only system that enables both

[PATCH], V7, #6 of 7, Fix issues with vector extract and prefixed instructions

This patch fixes two issues with vector extracts and prefixed instructions. The first is if you use a vector extract on a vector that is located in memory and to access the vector, you use a PC-relative address with a veriable index. I.e.: #include static vector int vi;

[PATCH], V7, #5 of 7, Add more effective targets for the 'future' system to target-supports.

This patch adds more effective targets to the target-supports.exp in the testsuite. I tried to break it down to whether prefixed instructions are allowed, whether the target is generating 64-bit code with prefixed instructions, and if -mpcrel support is available. I also enabled 'future' testing

[PATCH] V7, #4 of 7, Add explicit (0),1 to @pcrel references

In some of my previous work, I had make a mistake forgetting that the PADDI instruction did not allow adding a PC-relative reference to a register (you can either load up a PC-relative address without adding a register, or you can add a register to a constant). The assembler allowed the

[PATCH], V7, #3 of 7, Use PADDI for 34-bit immediate adds

This patch generates PADDI to add 34-bit immediate constants on the 'future' system, and prevents such adds from being split. I have built and boostrapped compilers with the patch, and there were no regressions. Can I check this into the trunk? 2019-11-14 Michael Meissner *

[PATCH], V7, #2 of 7, Use PLI to load up 32-bit SImode constants

This patch generates the PLI (PADDI) instruction to load up 32-bit SImode constants on the future system. It adds an alternative to movsi, and prevents the movsi load immediate from being split. I have built compilers with this patch which bootstrapped fine, and there were no regressions in the

[PATCH] V7, #1 of 7, Use PLI to load up 34-bit DImode constants

This patch adds an alternative to movdi to allow using PLI (PADDI) to load up 34-bit constants on the 'future' machine. I have built compilers with this patch, and there were no regressions in the test suite. Can I check this into the trunk? 2019-11-14 Michael Meissner *

Re: [RFC C++ PATCH] __builtin_source_location ()

On Thu, Nov 14, 2019 at 10:15:21PM +, Jonathan Wakely wrote: > > namespace std { > > struct source_location { > >struct __impl { > > Will this work if the library type is actually in an inline namespace, > such as std::__8::source_location::__impl (as for >

[committed] Change range_operator:fold_range to return a boolean indicating success.

One final tweak to the range-ops API. Most fold_range calls were returning true, which was a trigger for the original change to return by value.   When I changed it back to a return by reference, I should also have added the boolean result back.  Now all 3 routines are similar...    

PowerPC V7 future machine patches

This set of patches from V6 got missed, and should go in ASAP. I am breaking the patches into 3 logical steps: 1) The V7 patches that were part of the V6 patches that have not been committed. There are 7 patches in the suite (6 to the compiler, 1 to the testsuite to enable finer granularity for

Re: [RFC C++ PATCH] __builtin_source_location ()

On 14/11/19 20:34 +0100, Jakub Jelinek wrote: Hi! The following WIP patch implements __builtin_source_location (), which returns const void pointer to a std::source_location::__impl struct that is required to contain __file, __function, __line and __column fields, the first two with const char

Re: [PATCH V2] Refactor tree-loop-distribution for thread safety

Previously, the suggested patch removed all tree-loop-distributions.c global variables moving them into a struct and passing it aroung across the functions. This patch address this problem by using C++ classes instead, avoiding passing the struct as argument since it will be accessible from this

Re: [PATCH v3] gdbinit.in: allow to pass function argument explicitly

On 14.11.2019 23:50, Segher Boessenkool wrote: Hi! On Thu, Nov 14, 2019 at 07:01:47PM +0300, Konstantin Kharlamov wrote: Generally, people expect functions to accept arguments directly. But ones defined in gdbinit did not use the argument, which may be confusing for newcomers. But we can't

Re: [PATCH] Check suitability of spill register for mode

On 11/14/19 7:34 AM, Kwok Cheung Yeung wrote: Hello Currently, when choosing a spill register, GCC just picks the first available register in the register class returned by the TAQRGET_SPILL_CLASS hook that doesn't conflict. On AMD GCN this can cause problems as DImode values stored in

[PATCH] PR c++/92078 Add access specifiers to specializations

Fixes mentioned issue. Tested on bootstrap and cmcsstl2. gcc/cp/ * pt.c (maybe_new_partial_specialization): Apply access to newly created partial specializations. Update comment style. gcc/testsuite/ * g++.dg/cpp2a/concepts-pr92078.C: New. Andrew pr92078.patch Description: Binary data

Re: [PATCH v3] gdbinit.in: allow to pass function argument explicitly

Hi! On Thu, Nov 14, 2019 at 07:01:47PM +0300, Konstantin Kharlamov wrote: > Generally, people expect functions to accept arguments directly. But > ones defined in gdbinit did not use the argument, which may be confusing > for newcomers. But we can't change behavior to use the argument without >

Re: [PATCH] Support multi-versioning on self-recursive function (ipa/92133)

> >> Cost model used by self-recursive cloning is mainly based on existing > >> stuffs > >> in ipa-cp cloning, size growth and time benefit are considered. But since > >> recursive cloning is a more aggressive cloning, we will actually have > >> another > >> problem, which is opposite to your

[PATCH, fortran] Extend the builtin directive

The builtin directive allows specifying the simd attribute for a builtin function. Similarly how the C language simd attribtue got extended to allow declaring a specific vector variant, update the fortran builtin directive too. Before the patch, only the masking (inbranch/notinbranch) could be

Re: [C++ Patch] Use cp_expr_loc_or_input_loc in a few additional typeck.c places

Hi again, On 14/11/19 12:09, Paolo Carlini wrote: Hi, tested x86_64-linux. Instead of sending a separate patch, the below has two additional uses. Tested as usual. Thanks, Paolo. /// /cp 2019-11-14 Paolo Carlini * typeck.c (cp_build_addr_expr_1): Use

[PATCH v3] Extend the simd function attribute

Sorry v2 had a bug. v2: added documentation and tests. v3: fixed expand_simd_clones so different isa variants are actually generated. GCC currently supports two ways to declare the availability of vector variants of a scalar function: #pragma omp declare simd void f (void); and

Support UTF-8 character constants for C2x

C2x adds u8'' character constants to C. This patch adds the corresponding GCC support. Most of the support was already present for C++ and just needed enabling for C2x. However, in C2x these constants have type unsigned char, which required corresponding adjustments in the compiler and the

[RFC C++ PATCH] __builtin_source_location ()

Hi! The following WIP patch implements __builtin_source_location (), which returns const void pointer to a std::source_location::__impl struct that is required to contain __file, __function, __line and __column fields, the first two with const char * type, the latter some integral type. I don't

[PATCH][ARM][GCC][0/x]: Support for MVE ACLE intrinsics.

Hello, This patches series is to support Arm MVE ACLE intrinsics. Please refer to Arm reference manual [1] and MVE intrinsics [2] for more details. Please refer to Chapter 13 MVE ACLE [3] for MVE intrinsics concepts. This patch series depends on upstream patches "Armv8.1-M Mainline Security

[PATCH][ARM][GCC][11x]: MVE ACLE vector interleaving store and deinterleaving load intrinsics and also aliases to vstr and vldr intrinsics.

Hello, This patch supports following MVE ACLE intrinsics which are aliases of vstr and vldr intrinsics. vst1q_p_u8, vst1q_p_s8, vld1q_z_u8, vld1q_z_s8, vst1q_p_u16, vst1q_p_s16, vld1q_z_u16, vld1q_z_s16, vst1q_p_u32, vst1q_p_s32, vld1q_z_u32, vld1q_z_s32, vld1q_z_f16, vst1q_p_f16, vld1q_z_f32,

[PATCH][ARM][GCC][12x]: MVE ACLE intrinsics to set and get vector lane.

Hello, This patch supports following MVE ACLE intrinsics to get and set vector lane. vsetq_lane_f16, vsetq_lane_f32, vsetq_lane_s16, vsetq_lane_s32, vsetq_lane_s8, vsetq_lane_s64, vsetq_lane_u8, vsetq_lane_u16, vsetq_lane_u32, vsetq_lane_u64, vgetq_lane_f16, vgetq_lane_f32, vgetq_lane_s16,

[PATCH][ARM][GCC][13x]: MVE ACLE scalar shift intrinsics.

Hello, This patch supports following MVE ACLE scalar shift intrinsics. sqrshr, sqrshrl, sqrshrl_sat48, sqshl, sqshll, srshr, srshrl, uqrshl, uqrshll, uqrshll_sat48, uqshl, uqshll, urshr, urshrl, lsll, asrl. Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more details. [1]

[PATCH][ARM][GCC][14x]: MVE ACLE whole vector left shift with carry intrinsics.

Hello, This patch supports following MVE ACLE whole vector left shift with carry intrinsics. vshlcq_m_s8, vshlcq_m_s16, vshlcq_m_s32, vshlcq_m_u8, vshlcq_m_u16, vshlcq_m_u32. Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more details. [1]

[PATCH][ARM][GCC][10x]: MVE ACLE intrinsics "add with carry across beats" and "beat-wise substract".

Hello, This patch supports following MVE ACLE "add with carry across beats" intrinsics and "beat-wise substract" intrinsics. vadciq_s32, vadciq_u32, vadciq_m_s32, vadciq_m_u32, vadcq_s32, vadcq_u32, vadcq_m_s32, vadcq_m_u32, vsbciq_s32, vsbciq_u32, vsbciq_m_s32, vsbciq_m_u32, vsbcq_s32,

[PATCH][ARM][GCC][9x]: MVE ACLE predicated intrinsics with (dont-care) variant.

Hello, This patch supports following MVE ACLE predicated intrinsic with `_x` (dont-care) variant. * ``_x`` (dont-care) which indicates that the false-predicated lanes have undefined values. These are syntactic sugar for merge intrinsics with a ``vuninitializedq`` inactive parameter.

[PATCH][ARM][GCC][2/8x]: MVE ACLE gather load and scatter store intrinsics with writeback.

Hello, This patch supports following MVE ACLE intrinsics with writeback. vldrdq_gather_base_wb_s64, vldrdq_gather_base_wb_u64, vldrdq_gather_base_wb_z_s64, vldrdq_gather_base_wb_z_u64, vldrwq_gather_base_wb_f32, vldrwq_gather_base_wb_s32, vldrwq_gather_base_wb_u32, vldrwq_gather_base_wb_z_f32,

[PATCH][ARM][GCC][7x]: MVE vreinterpretq and vuninitializedq intrinsics.

Hello, This patch supports following MVE ACLE intrinsics. vreinterpretq_s16_s32, vreinterpretq_s16_s64, vreinterpretq_s16_s8, vreinterpretq_s16_u16, vreinterpretq_s16_u32, vreinterpretq_s16_u64, vreinterpretq_s16_u8, vreinterpretq_s32_s16, vreinterpretq_s32_s64, vreinterpretq_s32_s8,

[PATCH][ARM][GCC][1/8x]: MVE ACLE vidup, vddup, viwdup and vdwdup intrinsics with writeback.

Hello, This patch supports following MVE ACLE intrinsics with writeback. vddupq_m_n_u8, vddupq_m_n_u32, vddupq_m_n_u16, vddupq_m_wb_u8, vddupq_m_wb_u16, vddupq_m_wb_u32, vddupq_n_u8, vddupq_n_u32, vddupq_n_u16, vddupq_wb_u8, vddupq_wb_u16, vddupq_wb_u32, vdwdupq_m_n_u8, vdwdupq_m_n_u32,

[PATCH][ARM][GCC][7/5x]: MVE store intrinsics which stores byte,half word or word to memory.

Hello, This patch supports the following MVE ACLE store intrinsics which stores a byte, halfword, or word to memory. vst1q_f32, vst1q_f16, vst1q_s8, vst1q_s32, vst1q_s16, vst1q_u8, vst1q_u32, vst1q_u16, vstrhq_f16, vstrhq_scatter_offset_s32, vstrhq_scatter_offset_s16,

[PATCH][ARM][GCC][5/5x]: MVE ACLE load intrinsics which load a byte, halfword, or word from memory.

Hello, This patch supports the following MVE ACLE load intrinsics which load a byte, halfword, or word from memory. vld1q_s8, vld1q_s32, vld1q_s16, vld1q_u8, vld1q_u32, vld1q_u16, vldrhq_gather_offset_s32, vldrhq_gather_offset_s16, vldrhq_gather_offset_u32, vldrhq_gather_offset_u16,

[PATCH][ARM][GCC][6x]:MVE ACLE vaddq intrinsics using arithmetic plus operator.

Hello, This patch supports following MVE ACLE vaddq intrinsics. The RTL patterns for this intrinsics are added using arithmetic "plus" operator. vaddq_s8, vaddq_s16, vaddq_s32, vaddq_u8, vaddq_u16, vaddq_u32, vaddq_f16, vaddq_f32. Please refer to M-profile Vector Extension (MVE) intrinsics

[PATCH][ARM][GCC][6/5x]: Remaining MVE load intrinsics which loads half word and word or double word from memory.

Hello, This patch supports the following Remaining MVE ACLE load intrinsics which load an halfword, word or double word from memory. vldrdq_gather_base_s64, vldrdq_gather_base_u64, vldrdq_gather_base_z_s64, vldrdq_gather_base_z_u64, vldrdq_gather_offset_s64, vldrdq_gather_offset_u64,

[PATCH][ARM][GCC][3/5x]: MVE store intrinsics with predicated suffix.

Hello, This patch supports the following MVE ACLE store intrinsics with predicated suffix. vstrbq_p_s8, vstrbq_p_s32, vstrbq_p_s16, vstrbq_p_u8, vstrbq_p_u32, vstrbq_p_u16, vstrbq_scatter_offset_p_s8, vstrbq_scatter_offset_p_s32, vstrbq_scatter_offset_p_s16, vstrbq_scatter_offset_p_u8,

[PATCH][ARM][GCC][8/5x]: Remaining MVE store intrinsics which stores an half word, word and double word to memory.

Hello, This patch supports the following MVE ACLE store intrinsics which stores an halfword, word or double word to memory. vstrdq_scatter_base_p_s64, vstrdq_scatter_base_p_u64, vstrdq_scatter_base_s64, vstrdq_scatter_base_u64, vstrdq_scatter_offset_p_s64, vstrdq_scatter_offset_p_u64,

[PATCH][ARM][GCC][4/5x]: MVE load intrinsics with zero(_z) suffix.

Hello, This patch supports the following MVE ACLE load intrinsics with zero(_z) suffix. * ``_z`` (zero) which indicates false-predicated lanes are filled with zeroes, these are only used for load instructions. vldrbq_gather_offset_z_s16, vldrbq_gather_offset_z_u8, vldrbq_gather_offset_z_s32,

[PATCH][ARM][GCC][2/5x]: MVE load intrinsics.

Hello, This patch supports the following MVE ACLE load intrinsics. vldrbq_gather_offset_u8, vldrbq_gather_offset_s8, vldrbq_s8, vldrbq_u8, vldrbq_gather_offset_u16, vldrbq_gather_offset_s16, vldrbq_s16, vldrbq_u16, vldrbq_gather_offset_u32, vldrbq_gather_offset_s32, vldrbq_s32, vldrbq_u32,

[PATCH][ARM][GCC][1/5x]: MVE store intrinsics.

Hello, This patch supports the following MVE ACLE store intrinsics. vstrbq_scatter_offset_s8, vstrbq_scatter_offset_s32, vstrbq_scatter_offset_s16, vstrbq_scatter_offset_u8, vstrbq_scatter_offset_u32, vstrbq_scatter_offset_u16, vstrbq_s8, vstrbq_s32, vstrbq_s16, vstrbq_u8, vstrbq_u32,

[PATCH][ARM][GCC][1/4x]: MVE intrinsics with quaternary operands.

Hello, This patch supports following MVE ACLE intrinsics with quaternary operands. vsriq_m_n_s8, vsubq_m_s8, vsubq_x_s8, vcvtq_m_n_f16_u16, vcvtq_x_n_f16_u16, vqshluq_m_n_s8, vabavq_p_s8, vsriq_m_n_u8, vshlq_m_u8, vshlq_x_u8, vsubq_m_u8, vsubq_x_u8, vabavq_p_u8, vshlq_m_s8, vshlq_x_s8,

[PATCH][ARM][GCC][2/4x]: MVE intrinsics with quaternary operands.

Hello, This patch supports following MVE ACLE intrinsics with quaternary operands. vabdq_m_s8, vabdq_m_s32, vabdq_m_s16, vabdq_m_u8, vabdq_m_u32, vabdq_m_u16, vaddq_m_n_s8, vaddq_m_n_s32, vaddq_m_n_s16, vaddq_m_n_u8, vaddq_m_n_u32, vaddq_m_n_u16, vaddq_m_s8, vaddq_m_s32, vaddq_m_s16,

[PATCH][ARM][GCC][1/3x]: MVE intrinsics with ternary operands.

Hello, This patch supports following MVE ACLE intrinsics with ternary operands. vabavq_s8, vabavq_s16, vabavq_s32, vbicq_m_n_s16, vbicq_m_n_s32, vbicq_m_n_u16, vbicq_m_n_u32, vcmpeqq_m_f16, vcmpeqq_m_f32, vcvtaq_m_s16_f16, vcvtaq_m_u16_f16, vcvtaq_m_s32_f32, vcvtaq_m_u32_f32, vcvtq_m_f16_s16,

[PATCH][ARM][GCC][4/4x]: MVE intrinsics with quaternary operands.

Hello, This patch supports following MVE ACLE intrinsics with quaternary operands. vabdq_m_f32, vabdq_m_f16, vaddq_m_f32, vaddq_m_f16, vaddq_m_n_f32, vaddq_m_n_f16, vandq_m_f32, vandq_m_f16, vbicq_m_f32, vbicq_m_f16, vbrsrq_m_n_f32, vbrsrq_m_n_f16, vcaddq_rot270_m_f32, vcaddq_rot270_m_f16,

[PATCH][ARM][GCC][3/4x]: MVE intrinsics with quaternary operands.

Hello, This patch supports following MVE ACLE intrinsics with quaternary operands. vmlaldavaq_p_s16, vmlaldavaq_p_s32, vmlaldavaq_p_u16, vmlaldavaq_p_u32, vmlaldavaxq_p_s16, vmlaldavaxq_p_s32, vmlaldavaxq_p_u16, vmlaldavaxq_p_u32, vmlsldavaq_p_s16, vmlsldavaq_p_s32, vmlsldavaxq_p_s16,

[PATCH][ARM][GCC][2/3x]: MVE intrinsics with ternary operands.

Hello, This patch supports following MVE ACLE intrinsics with ternary operands. vpselq_u8, vpselq_s8, vrev64q_m_u8, vqrdmlashq_n_u8, vqrdmlahq_n_u8, vqdmlahq_n_u8, vmvnq_m_u8, vmlasq_n_u8, vmlaq_n_u8, vmladavq_p_u8, vmladavaq_u8, vminvq_p_u8, vmaxvq_p_u8, vdupq_m_n_u8, vcmpneq_m_u8,

[PATCH][ARM][GCC][3/3x]: MVE intrinsics with ternary operands.

Hello, This patch supports following MVE ACLE intrinsics with ternary operands. vrmlaldavhaxq_s32, vrmlsldavhaq_s32, vrmlsldavhaxq_s32, vaddlvaq_p_s32, vcvtbq_m_f16_f32, vcvtbq_m_f32_f16, vcvttq_m_f16_f32, vcvttq_m_f32_f16, vrev16q_m_s8, vrev32q_m_f16, vrmlaldavhq_p_s32, vrmlaldavhxq_p_s32,

[PATCH][ARM][GCC][4/2x]: MVE intrinsics with binary operands.

Hello, This patch supports following MVE ACLE intrinsics with binary operands. vsubq_u8, vsubq_n_u8, vrmulhq_u8, vrhaddq_u8, vqsubq_u8, vqsubq_n_u8, vqaddq_u8, vqaddq_n_u8, vorrq_u8, vornq_u8, vmulq_u8, vmulq_n_u8, vmulltq_int_u8, vmullbq_int_u8, vmulhq_u8, vmladavq_u8, vminvq_u8, vminq_u8,

[PATCH][ARM][GCC][5/2x]: MVE intrinsics with binary operands.

Hello, This patch supports following MVE ACLE intrinsics with binary operands. vqmovntq_u16, vqmovnbq_u16, vmulltq_poly_p8, vmullbq_poly_p8, vmovntq_u16, vmovnbq_u16, vmlaldavxq_u16, vmlaldavq_u16, vqmovuntq_s16, vqmovunbq_s16, vshlltq_n_u8, vshllbq_n_u8, vorrq_n_u16, vbicq_n_u16,

[PATCH][ARM][GCC][3/2x]: MVE intrinsics with binary operands.

Hello, This patch supports following MVE ACLE intrinsics with binary operands. vaddlvq_p_s32, vaddlvq_p_u32, vcmpneq_s8, vcmpneq_s16, vcmpneq_s32, vcmpneq_u8, vcmpneq_u16, vcmpneq_u32, vshlq_s8, vshlq_s16, vshlq_s32, vshlq_u8, vshlq_u16, vshlq_u32. Please refer to M-profile Vector Extension

[PATCH][ARM][GCC][2/2x]: MVE intrinsics with binary operands.

Hello, This patch supports following MVE ACLE intrinsics with binary operands. vcvtq_n_s16_f16, vcvtq_n_s32_f32, vcvtq_n_u16_f16, vcvtq_n_u32_f32, vcreateq_u8, vcreateq_u16, vcreateq_u32, vcreateq_u64, vcreateq_s8, vcreateq_s16, vcreateq_s32, vcreateq_s64, vshrq_n_s8, vshrq_n_s16, vshrq_n_s32,

[PATCH][ARM][GCC][1/2x]: MVE intrinsics with binary operands.

Hello, This patch supports following MVE ACLE intrinsics with binary operand. vsubq_n_f16, vsubq_n_f32, vbrsrq_n_f16, vbrsrq_n_f32, vcvtq_n_f16_s16, vcvtq_n_f32_s32, vcvtq_n_f16_u16, vcvtq_n_f32_u32, vcreateq_f16, vcreateq_f32. Please refer to M-profile Vector Extension (MVE) intrinsics [1]

[PATCH][ARM][GCC][1/1x]: Patch to support MVE ACLE intrinsics with unary operand.

Hello, This patch supports MVE ACLE intrinsics vcvtq_f16_s16, vcvtq_f32_s32, vcvtq_f16_u16, vcvtq_f32_u32n vrndxq_f16, vrndxq_f32, vrndq_f16, vrndq_f32, vrndpq_f16, vrndpq_f32, vrndnq_f16, vrndnq_f32, vrndmq_f16, vrndmq_f32, vrndaq_f16, vrndaq_f32, vrev64q_f16, vrev64q_f32, vnegq_f16,

[PATCH][ARM][GCC][4/x]: MVE ACLE vector interleaving store intrinsics.

Hello, This patch supports MVE ACLE intrinsics vst4q_s8, vst4q_s16, vst4q_s32, vst4q_u8, vst4q_u16, vst4q_u32, vst4q_f16 and vst4q_f32. In this patch arm_mve_builtins.def file is added to the source code in which the builtins for MVE ACLE intrinsics are defined using builtin qualifiers. Please

[PATCH][ARM][GCC][1/x]: MVE ACLE intrinsics framework patch.

Hello, This patch creates the required framework for MVE ACLE intrinsics. The following changes are done in this patch to support MVE ACLE intrinsics. Header file arm_mve.h is added to source code, which contains the definitions of MVE ACLE intrinsics and different data types used in MVE.

[PATCH][ARM][GCC][2/1x]: MVE intrinsics with unary operand.

Hello, This patch supports following MVE ACLE intrinsics with unary operand. vmvnq_n_s16, vmvnq_n_s32, vrev64q_s8, vrev64q_s16, vrev64q_s32, vcvtq_s16_f16, vcvtq_s32_f32, vrev64q_u8, vrev64q_u16, vrev64q_u32, vmvnq_n_u16, vmvnq_n_u32, vcvtq_u16_f16, vcvtq_u32_f32, vrev64q. Please refer to

[PATCH][ARM][GCC][4/1x]: MVE intrinsics with unary operand.

Hello, This patch supports following MVE ACLE intrinsics with unary operand. vctp16q, vctp32q, vctp64q, vctp8q, vpnot. Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more details. [1]

[PATCH][ARM][GCC][2/x]: MVE ACLE intrinsics framework patch.

Hello, This patch is part of MVE ACLE intrinsics framework. This patches add support to update (read/write) the APSR (Application Program Status Register) register and FPSCR (Floating-point Status and Control Register) register for MVE. This patch also enables thumb2 mov RTL patterns for MVE.

[PATCH][ARM][GCC][3/1x]: MVE intrinsics with unary operand.

Hello, This patch supports following MVE ACLE intrinsics with unary operand. vdupq_n_s8, vdupq_n_s16, vdupq_n_s32, vabsq_s8, vabsq_s16, vabsq_s32, vclsq_s8, vclsq_s16, vclsq_s32, vclzq_s8, vclzq_s16, vclzq_s32, vnegq_s8, vnegq_s16, vnegq_s32, vaddlvq_s32, vaddvq_s8, vaddvq_s16, vaddvq_s32,

[PATCH][ARM][GCC][3/x]: MVE ACLE intrinsics framework patch.

Hello, This patch is part of MVE ACLE intrinsics framework. The patch supports the use of emulation for the double-precision arithmetic operations for MVE. This changes are to support the MVE ACLE intrinsics which operates on vector floating point arithmetic operations. Please refer to Arm

[committed] operator_abs::fold_range() returning incorrect result for overflows (pr92506)

Traced it back to a typo in operator_abs::fold_range() when I did the conversion where the wrong line got copied in.. Instead of returning value_range (type) when a overflow happens, it was returning the same result of the previous check, which was the case for all positives. This had EVRP

Re: Tweak gcc.dg/vect/bb-slp-4[01].c (PR92366)

On November 14, 2019 7:10:10 PM GMT+01:00, Richard Sandiford wrote: >gcc.dg/vect/bb-slp-40.c was failing on some targets because the >explicit dg-options overrode things like -maltivec. This patch >uses dg-additional-options instead. > >Also, it seems safer not to require exactly 1 instance of

[PATCH v2] Extend the simd function attribute

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 (void); However these declare a set of symbols that are different simd variants of f, so a library either

[SVE] PR89007 - Implement generic vector average expansion

Hi, As suggested in PR, the attached patch falls back to distributing rshift over plus_expr instead of fallback widening -> arithmetic -> narrowing sequence, if target support is not available. Bootstrap+tested on x86_64-unknown-linux-gnu and aarch64-linux-gnu. OK to commit ? Thanks, Prathamesh

[Patch] [mid-end][__RTL] Clean df state despite invalid __RTL startwith passes

Hi there, When compiling an __RTL function that has an invalid "startwith" pass we currently don't run the dfinish cleanup pass. This means we ICE on the next function. This change ensures that all state is cleaned up for the next function to run correctly. As an example, before this change the

[mid-end][__RTL] Clean state despite unspecified __RTL startwith passes

Hi there, When compiling an __RTL function that has an unspecified "startwith" pass we currently don't run the cleanup pass, this means that we ICE on the next function (if it's a basic function). I asked about this on the GCC mailing list a while ago and Richard mentioned it might be a good idea

Tweak gcc.dg/vect/bb-slp-4[01].c (PR92366)

gcc.dg/vect/bb-slp-40.c was failing on some targets because the explicit dg-options overrode things like -maltivec. This patch uses dg-additional-options instead. Also, it seems safer not to require exactly 1 instance of each message, since that depends on the target vector length.

[arm] Follow up for asm-flags vs thumb1

What I committed today does in fact ICE for thumb1, as you suspected. I'm currently testing the following vs arm-sim/ arm-sim/-mthumb arm-sim/-mcpu=cortex-a15/-mthumb. which, with the default cpu for arm-elf-eabi, should test all of arm, thumb1, thumb2. I'm not thrilled about the ifdef

[PATCH] extend missing nul checks to all built-ins (PR 88226)

GCC 9 added checks for usafe uses of unterminated constant char arrays to a few string functions but the checking is far from comprehensive. It's been on my list of things to do to do a more thorough review and add the checks where they're missing. The attached patch does this for the majority

Re: [patch, libgomp] Add tests for print from offload target

On Thu, Nov 14, 2019 at 05:18:41PM +, Andrew Stubbs wrote: > On 14/11/2019 17:05, Jakub Jelinek wrote: > > On Thu, Nov 14, 2019 at 04:47:49PM +, Andrew Stubbs wrote: > > > This patch adds new libgomp tests to ensure that C "printf" and Fortran > > > "write" work correctly within offload

Re: [patch, libgomp] Add tests for print from offload target

On 14/11/2019 17:05, Jakub Jelinek wrote: On Thu, Nov 14, 2019 at 04:47:49PM +, Andrew Stubbs wrote: This patch adds new libgomp tests to ensure that C "printf" and Fortran "write" work correctly within offload kernels. Both should work for amdgcn, but nvptx uses the libgfortran "minimal"

Re: [patch, libgomp] Add tests for print from offload target

On 11/14/19 5:47 PM, Andrew Stubbs wrote: This patch adds new libgomp tests to ensure that C "printf" and Fortran "write" work correctly within offload kernels. Both should work for amdgcn, but nvptx uses the libgfortran "minimal" mode which lacks "write" support. Can't you add something

[COMMITTED] Remove range_intersect, range_invert, and range_union.

range_intersect, range_union, and range_intersect are currently returning their results by value. After Andrew's change, these should also return their results in an argument. However, if we do this, the functions become superfluous since we have corresponding API methods with the same

[PATCH] fold strncmp of unterminated arrays (PR 92501)

Adding tests for unsafe uses of unterminated constant char arrays in string functions exposed the limitation in strncmp folding described in PR 92501: GCC only folds strncmp calls involving nul-terminated constant strings. The attached patch improves the folder to also handle unterminated

Re: [patch, libgomp] Add tests for print from offload target

On Thu, Nov 14, 2019 at 04:47:49PM +, Andrew Stubbs wrote: > This patch adds new libgomp tests to ensure that C "printf" and Fortran > "write" work correctly within offload kernels. Both should work for amdgcn, > but nvptx uses the libgfortran "minimal" mode which lacks "write" support. So,

Re: [Patch, fortran] PR69654 - ICE in gfc_trans_structure_assign

On Thu, Nov 14, 2019 at 03:52:26PM +, Paul Richard Thomas wrote: > As I remarked in PR, this fix probably comes 1,379 days too late. I am > not at all sure that I understand why I couldn't see the problem > because it is rather trivial. > > I am open to not adding the second gcc_assert - it

[PATCH] libstdc++: Implement new predicate concepts from P1716R3

* include/bits/iterator_concepts.h (__iter_concept_impl): Add comments. (indirect_relation): Rename to indirect_binary_predicate and adjust definition as per P1716R3. (indirect_equivalence_relation): Define. (indirectly_comparable): Adjust

[PATCH] libstdc++: Rename disable_sized_sentinel [P1871R1]

* include/bits/iterator_concepts.h (disable_sized_sentinel): Rename to disable_sized_sentinel_for. * testsuite/24_iterators/headers/iterator/synopsis_c++20.cc: Adjust. Tested powerpc64le-linux, committed to trunk. commit 3a7f3e87680cc0ca20318b0983d517cd32851fc5 Author:

[patch, libgomp] Add tests for print from offload target

Hi, This patch adds new libgomp tests to ensure that C "printf" and Fortran "write" work correctly within offload kernels. Both should work for amdgcn, but nvptx uses the libgfortran "minimal" mode which lacks "write" support. Obviously, printing from offload kernels is not recommended in

  1   2   3   >