Re: [PATCH] i386: Add AVX512 unaligned intrinsics

On Tue, Jul 9, 2019 at 11:44 PM Sunil Pandey wrote: > > __m512i _mm512_loadu_epi32( void * sa); > __m512i _mm512_loadu_epi64( void * sa); > void _mm512_storeu_epi32(void * d, __m512i a); > void _mm256_storeu_epi32(void * d, __m256i a); > void _mm_storeu_epi32(void * d, __m128i a); > void _mm512_st

[PATCH] Add hints for slim dumping if fallthrough bb of jump isn't next bb

Hi all, 6: NOTE_INSN_BASIC_BLOCK 2 12: r135:CC=cmp(r122:DI,0) 13: pc={(r135:CC!=0)?L52:pc} REG_DEAD r135:CC REG_BR_PROB 1041558836 31: L31: 17: NOTE_INSN_BASIC_BLOCK 3 The above RTL sequence is from pass doloop dumping with -fdump-rtl-all-slim, I misunders

[PING^1][PATCH v4 3/3] PR80791 Consider doloop cmp use in ivopts

Hi all, I'd like to gentle ping the below patch: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01225.html The previous version for more context/background: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01126.html Thanks a lot in advance! on 2019/6/20 下午8:16, Kewen.Lin wrote: > Hi, > > Sorry,

[og9] OpenACC assumed-size arrays with non-lexical data mappings

Hi, This patch provides support for implicit mapping of assumed-sized arrays for OpenACC, in cases where those arrays have previously been mapped using non-lexical data mappings (e.g. "#pragma acc enter data"). Previously posted here: https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02090.html and

[og9] Allow the accelerator to have more offloaded functions than the host

Hi, This patch was previously posted here by Cesar: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00668.html This patch is necessary when not all objects containing offload code are linked into the final executable, including those in static libraries. Re-tested with offloading to nvptx. I will

[og9] Support Fortran 2003 class pointers in OpenACC

This patch provides initial support for Fortran 2003 polymorphic class pointers in OpenACC. This necessitated some rewriting of the lowering code in gfc_trans_omp_clauses, partly reverting some of the changes made by the earlier manual deep copy support. In the new code, I've tried to reuse existin

Re: [PATCH,RFC,V3 0/5] Support for CTF in GCC

On 7/9/19 5:25 PM, Segher Boessenkool wrote: > On Fri, Jul 05, 2019 at 07:28:12PM +0100, Nix wrote: >> On 5 Jul 2019, Richard Biener said: >> >>> On Fri, Jul 5, 2019 at 12:21 AM Indu Bhagat wrote: CTF, at this time, is type information for entities at global or file scope. This can

[PATCH], PowerPC, Patch #7, Split up SIGNED_34BIT and SIGNED_16BIT macros

This patch splits up the macros SIGNED_16BIT_OFFSET_P and SIGNED_34BIT_OFFSET_P into two separate macros as you asked for previously in private mail. The main macros: SIGNED_16BIT_OFFSET_P SIGNED_34BIT_OFFSET_P only take one argument, and that is the offset that is being tested.

Re: [PATCH,RFC,V3 0/5] Support for CTF in GCC

On Fri, Jul 05, 2019 at 07:28:12PM +0100, Nix wrote: > On 5 Jul 2019, Richard Biener said: > > > On Fri, Jul 5, 2019 at 12:21 AM Indu Bhagat wrote: > >> CTF, at this time, is type information for entities at global or file > >> scope. > >> This can be used by online debuggers, program tracers (d

Re: [PATCH,RFC,V3 0/5] Support for CTF in GCC

On Jul 5, 2019, at 11:28 AM, Nix wrote: > ICTF for the entire Linux kernel is about 6MiB Any reason why not add CTF to the next dwarf standard? Then, we just support the next dwarf standard. If not, have you started talks with them to add it? Long term, this is a better solution, as we then g

[PATCH], PowerPC, Patch #6, Create pc-relative addressing insns

This patch updates the basic support for pc-relative addressing that will be added in a future machine. It was originally proposed as patch #4: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01866.html Segher suggested that I split out moving create_TOC_reference back to rs6000.c as a separate pat

Fix wi::lshift

Hello, because of an other bug, __builtin_constant_p is ignored in some cases, and this bug in wide_int went unnoticed. I am fixing it by making it match more closely the comment above. Bootstrap+regtest together with a fix for __builtin_constant_p on x86_64-pc-linux-gnu. 2019-07-11 Marc

Re: [range-ops] patch 05/04: bonus round!

On 7/6/19 3:26 AM, Aldy Hernandez wrote: > > > On 7/3/19 7:12 PM, Jeff Law wrote: >> On 7/1/19 4:24 AM, Aldy Hernandez wrote: >>> This is completely unrelated to range-ops itself, but may yield better >>> results in value_range intersections.  It's just something I found while >>> working on VRP,

Committed (vectorizable_comparison): Swap operands only once.

For gcc.dg/vect/vect-bool-cmp.c, vectorizable_comparison would swap the comparison operands in fn7 once for each copy, thus all odd copies would end up unswapped. Regression tested on x86_64-pc-linux-gnu. Committed as obvious. 2019-07-09 Joern Rennecke * tree-vect-stmts.c (vectorizabl

[PATCH] i386: Add AVX512 unaligned intrinsics

__m512i _mm512_loadu_epi32( void * sa); __m512i _mm512_loadu_epi64( void * sa); void _mm512_storeu_epi32(void * d, __m512i a); void _mm256_storeu_epi32(void * d, __m256i a); void _mm_storeu_epi32(void * d, __m128i a); void _mm512_storeu_epi64(void * d, __m512i a); void _mm256_storeu_epi64(void * d,

Re: [PATCH] Perform case-insensitive comparison when decoding register names (PR target/70320)

On Tue, Jul 09, 2019 at 10:16:31PM +0100, Jozef Lawrynowicz wrote: > On Mon, 8 Jul 2019 16:42:15 -0500 > Segher Boessenkool wrote: > > > > Ok, yes a DEFHOOKPOD or similar sounds like a good idea, I'll look into > > > this > > > alternative. > > > > What is that, like target macros? But with

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

On 08.07.19 23:19, Matthias Klose wrote: > On 14.06.19 15:09, Gaius Mulley wrote: >> >> Hello, >> >> here is version two of the patches which introduce Modula-2 into the >> GCC trunk. The patches include: >> >> (*) a patch to allow all front ends to register a lang spec function. >>(inc

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

On 09.07.19 21:48, Gaius Mulley wrote: > Matthias Klose writes: > >>> - libpth.{a,so} is installed in the system libdir, which >>>conflicts with the installation of the libpth packages >>>on most distros. >> >> found out that a system provided libpth can be used. Otoh if you build the >

Re: (C++) Remove -fdeduce-init-list?

On Mon, May 20, 2019 at 02:38:31PM -0400, Marek Polacek wrote: > Back in 2011, -fdeduce-init-list was marked as deprecated: > . > > 7.5 years later, is it time to rip it out completely from the compiler? Seeing the -frepo deprecation, any

Re: [C++ PATCH] PR c++/90590 Suppress warning for enumeration value not handled in switch warning

On 7/9/19 11:18 AM, Matthew Beliveau wrote: This patch suppresses the warning: "enumeration value not handled in switch", for enumerators that are defined in system headers and use reserved names. + if (decl == NULL_TREE) + decl = lookup_name (TREE_PURPOSE (chain)); This seems li

Re: [RFC/PATCH v2][PR89245] Check REG_CALL_DECL note during the tail-merging

On 7/9/19 2:06 PM, Dragan Mladjenovic wrote: > This patch prevents merging of CALL instructions that that have different > REG_CALL_DECL notes attached to them. > > On most architectures this is not an important distinction. Usually > instruction patterns > for calls to different functions refere

Re: [PATCH] Perform case-insensitive comparison when decoding register names (PR target/70320)

On Mon, 8 Jul 2019 16:42:15 -0500 Segher Boessenkool wrote: > > Ok, yes a DEFHOOKPOD or similar sounds like a good idea, I'll look into this > > alternative. > > What is that, like target macros? But with some indirection? Yes its for target macros, it looks like the "POD" in DEFHOOKPOD stan

Re: [PATCH] Deprecate -frepo option.

On 7/9/19 1:48 PM, Nathan Sidwell wrote: On 7/9/19 9:00 AM, Martin Liška wrote: On 7/9/19 1:41 PM, Nathan Sidwell wrote: On 7/9/19 6:39 AM, Richard Biener wrote: On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS

Re: [C++ Patch] A few additional location improvements to grokdeclarator and check_tag_decl

On 7/9/19 6:10 AM, Paolo Carlini wrote: Hi, On 08/07/19 23:44, Jason Merrill wrote: On 6/23/19 7:58 AM, Paolo Carlini wrote: +    error_at (smallest_type_location (get_type_quals (declspecs), +  declspecs->locations), How about adding a smallest_type_location overload that

Re: Make nonoverlapping_component_refs work with duplicated main variants

On 9 July 2019 15:37:30 CEST, Richard Biener wrote: >On Tue, 9 Jul 2019, Jan Hubicka wrote: > >> Hi, >> this is updated variant I am testing. >> It documents better how function works and streamlines the checks. >> >> OK assuming it passes the tests? >> >> Honza >> >> Index: tree-ssa-alias.c >>

Re: [PATCH 1/2] Come up with function_decl_type and use it in tree_function_decl.

On 7/9/19 6:17 AM, Marc Glisse wrote: On Tue, 9 Jul 2019, Martin Liška wrote: On 7/9/19 9:49 AM, Marc Glisse wrote: On Tue, 9 Jul 2019, Marc Glisse wrote: On Mon, 8 Jul 2019, Martin Liška wrote: The patch apparently has DECL_IS_OPERATOR_DELETE only on the replaceable global deallocation fu

[RFC/PATCH v2][PR89245] Check REG_CALL_DECL note during the tail-merging

This patch prevents merging of CALL instructions that that have different REG_CALL_DECL notes attached to them. On most architectures this is not an important distinction. Usually instruction patterns for calls to different functions reference different SYMBOL_REF-s, so they won't match. On MIPS

Re: Patch ping (Re: [PATCH] Fortran include line fixes and -fdec-include support)

On Sat, 19 Jan 2019, Jakub Jelinek wrote: >> how about the refinement below? > LGTM. Thanks. The context has changed a bit since then (due to links being added), so I had to manually re-apply the patch and committed the following now. Gerald Index: changes.html =

Re: [wwwdocs] Buildstat update for 6.x

On Wed, 27 Feb 2019, Tom G. Christensen wrote: > Latest results for 6.x. Applied, thank you! Note, I had to manually apply the last three hunks, since patch somehow did not like the format (w/o me seeing anything obviously wrong): > Testresults for 6.5.0: > hppa2.0w-hp-hpux11.11 > hppa64-hp-

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

Matthias Klose writes: >> - libpth.{a,so} is installed in the system libdir, which >>conflicts with the installation of the libpth packages >>on most distros. > > found out that a system provided libpth can be used. Otoh if you build the > in-tree libpth, it shouldn't be installed, but

Re: [wwwdocs] Buildstat update for 7.x

On Wed, 27 Feb 2019, Tom G. Christensen wrote: > Latest results for 7.x. > > -tgc > > Testresults for 7.4.0: > x86_64-w64-mingw32 Thank you, applied (finally). Gerald

Re: [PATCH] simplify-rtx.c (simplify_unary_operation_1): Change BITSIZE to PRECISION.

On 7/8/19 1:11 AM, John Darrington wrote: > gcc/ > * simplify-rtx.c (simplify_unary_operation_1): Change BITSIZE to PRECISION > in simplification of (extend ashiftrt (ashift ..))) Otherwise the > gcc_assert can catch when dealing with partial int modes. THanks. I edited the ChangeLog entry a bi

Re: [patch, libfortran] Adjust block size for libgfortran for unformatted reads

On Mon, 8 Jul 2019 09:05:04 -0700 Steve Kargl wrote: > On Mon, Jul 08, 2019 at 04:02:17PM +0300, Janne Blomqvist wrote: > > > > Good point. If you happen to have a USB stick handy, can you try the > > simple C benchmark program at > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030#c38 ? > >

Re: [PING][PATCH] constrain one character optimization to one character stores (PR 90989)

On 7/8/19 8:37 PM, Martin Sebor wrote: > Ping: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01506.html > > Jeff (et al.), do you have any outstanding questions/concerns > about the patch? Sorry I wasn't clear. All my concerns are resolved. The patch is fine for the trunk. jeff >

Re: [PATCH 3/3] change class-key of PODs to struct and others to class (PR 61339)

On 7/9/19 9:17 AM, Richard Sandiford wrote: Martin Sebor writes: diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h index cfc41e1ed86..625d5b17413 100644 --- a/gcc/cp/cp-tree.h +++ b/gcc/cp/cp-tree.h @@ -6428,7 +6428,7 @@ extern tree get_scope_of_declarator (const cp_declarator *);

Re: [PATCH, committed] PowerPC Prefixed Memory, Patch #5 (move create_TOC_reference)

On Tue, Jul 09, 2019 at 01:32:26PM -0400, Michael Meissner wrote: > On Mon, Jul 08, 2019 at 01:53:13PM -0500, Segher Boessenkool wrote: > > Please do; as a separate patch. Thanks in advance. A patch purely moving > > it back is pre-approved. > > I just committed this patch: > > 2019-07-09 Mich

Re: [PATCH] Deprecate -frepo option.

On 7/9/19 9:00 AM, Martin Liška wrote: On 7/9/19 1:41 PM, Nathan Sidwell wrote: On 7/9/19 6:39 AM, Richard Biener wrote: On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS 17) and apparently 17 is not enough to reso

Re: [C++ PATCH] PR c++/90590 Suppress warning for enumeration value not handled in switch warning

On Tue, Jul 09, 2019 at 11:18:53AM -0400, Matthew Beliveau wrote: > index 000..8aa65cf0afd > --- /dev/null > +++ gcc/testsuite/c-c++-common/pr90590-2.c > @@ -0,0 +1,8 @@ > +#include "pr90590-2.h" > + > +void > +fn () > +{ > + switch (c.b) // { dg-bogus "enumeration value" } > +; > +}

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

On 09.07.19 17:53, Gaius Mulley wrote: > Rainer Orth writes: > >> Hi Matthias, >> >>> I had a look at the GCC 9 version of the patches, with a build including a >>> make >>> install. Some comments: >>> >>> - A parallel build (at least with -j4) isn't working. A sequental >>>build works fine

[PATCH, committed] PowerPC Prefixed Memory, Patch #5 (move create_TOC_reference)

On Mon, Jul 08, 2019 at 01:53:13PM -0500, Segher Boessenkool wrote: > Please do; as a separate patch. Thanks in advance. A patch purely moving > it back is pre-approved. I just committed this patch: 2019-07-09 Michael Meissner * config/rs6000/rs6000-internal.h (create_TOC_reference)

Re: [PATCH,RFC,V3 0/5] Support for CTF in GCC

On 07/04/2019 03:43 AM, Richard Biener wrote: Hmm...a GCC plugin for CTF generation at compile-time may work out for a single compilation unit. But I am not sure how will LTO be supported in that case. Basically, for LTO and -gtLEVEL to work together, I need the lto-wrapper to be aware of the

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

Matthias Klose writes: > And an unrelated one: You are introducing python2 as a build-dependency. > Afaics, it's only one invocation > > python ../../src/gcc/gm2/tools-src/def2texi.py -uLibraries -s../../src/gcc/gm2 > -b/home/packages/gcc/9/u/gcc-9-9.1.1/build/gcc/gm2 > > /home/packages/gcc/9/u/g

Re: [PATCH V4] PR88497 - Extend reassoc for vector bit_field_ref

On Tue, Jul 09, 2019 at 10:28:06AM +0800, Kewen.Lin wrote: > on 2019/7/9 上午12:32, Segher Boessenkool wrote: > > On Mon, Jul 08, 2019 at 04:07:00PM +0800, Kewen.Lin wrote: > >> --- /dev/null > >> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c > >> @@ -0,0 +1,60 @@ > >> +/* { dg-do run } */ > >> +/*

Re: [PATCH] Restrict LOOP_ALIGN to loop headers only.

On July 9, 2019 3:10:19 PM GMT+02:00, Michael Matz wrote: >Hi, > >On Tue, 9 Jul 2019, Richard Biener wrote: > >> > So a "backedge" in this sense would be e->dest->index < >e->src->index. >> > No? >> >> To me the following would make sense. > >The basic block index is not a DFS index, so no, that'

Re: [PATCH 2/3] change class-key of PODs to struct and others to class (PR 61339)

On 7/9/19 7:48 AM, Richard Sandiford wrote: Martin Sebor writes: Hopefully with the right patch this time (thanks Jon). On 7/8/19 4:00 PM, Martin Sebor wrote: The attached patch changes the class-key of class definitions that satisfy the requirements on a POD struct to 'struct', and that of s

Re: [PATCH 1/2] [ARC] Fix and refurbish the interrupts.

Hi Jeff, Please find attached the updated patch. What is new: - mailing list feedback is taken into account. - some comments are updated. - a new test is added. - the ARC AUX registers used by ZOL (hardware loop) and FPX (a custom floating point implementation) are saved before fp-register. - the

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

On 09.07.19 15:41, Gaius Mulley wrote: > Matthias Klose writes: > >>> the libraries ./usr/lib/x86_64-linux-gnu/lib{ulm,pim,gm2,cor,iso,min}.a >>> are not needed the correct locations of the static libraries are: >>> >>> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/ulm/libulm.a >>> ./usr/lib/gcc/x86_64-lin

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

Rainer Orth writes: > Hi Matthias, > >> I had a look at the GCC 9 version of the patches, with a build including a >> make >> install. Some comments: >> >> - A parallel build (at least with -j4) isn't working. A sequental >>build works fine. I think forcing a sequential build will not >>

[C++ PATCH] PR c++/90590 Suppress warning for enumeration value not handled in switch warning

This patch suppresses the warning: "enumeration value not handled in switch", for enumerators that are defined in system headers and use reserved names. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2019-07-08 Matthew Beliveau PR c++/90590 * c-warn.c (c_do_switch_warnings): Suppress

Re: [PATCH 3/3] change class-key of PODs to struct and others to class (PR 61339)

Martin Sebor writes: > diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h > index cfc41e1ed86..625d5b17413 100644 > --- a/gcc/cp/cp-tree.h > +++ b/gcc/cp/cp-tree.h > @@ -6428,7 +6428,7 @@ extern tree get_scope_of_declarator (const > cp_declarator *); > extern void grok_special_member_p

[PATCH] gdbhooks.py: dump-fn, dot-fn: cast ret values of fopen/fclose

Hi, Without the patch, I see these error messages with gdb 8.3: (gdb) Python Exception 'fclose@@GLIBC_2.2.5' has unknown return type; cast the call to its declared return type: (gdb) Error occurred in Python: 'fclose@@GLIBC_2.2.5' has unknown return type; cast the call to its dec

Re: [PATCH 2/3] change class-key of PODs to struct and others to class (PR 61339)

Martin Sebor writes: > Hopefully with the right patch this time (thanks Jon). > > On 7/8/19 4:00 PM, Martin Sebor wrote: >> The attached patch changes the class-key of class definitions that >> satisfy the requirements on a POD struct to 'struct', and that of >> struct definitions that aren't POD

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

Matthias Klose writes: >> the libraries ./usr/lib/x86_64-linux-gnu/lib{ulm,pim,gm2,cor,iso,min}.a >> are not needed the correct locations of the static libraries are: >> >> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/ulm/libulm.a >> ./usr/lib/gcc/x86_64-linux-gnu/9/m2/min/libmin.a >> ./usr/lib/gcc/x86_6

Re: Make nonoverlapping_component_refs work with duplicated main variants

On Tue, 9 Jul 2019, Jan Hubicka wrote: > Hi, > this is updated variant I am testing. > It documents better how function works and streamlines the checks. > > OK assuming it passes the tests? > > Honza > > Index: tree-ssa-alias.c >

Re: Make nonoverlapping_component_refs work with duplicated main variants

Hi, this is updated variant I am testing. It documents better how function works and streamlines the checks. OK assuming it passes the tests? Honza Index: tree-ssa-alias.c === --- tree-ssa-alias.c(revision 273193) +++ tree-ssa-a

Re: Make nonoverlapping_component_refs work with duplicated main variants

On Tue, 9 Jul 2019, Jan Hubicka wrote: > > > tree_int_cst_equal will return false if offsets are not INTEGER_CST. > > > I was not sure if I can safely use operand_equal_p. What happens for > > > fields with variable offsets when I inline two copies of same function > > > which takes size as param

[PATCH] Fix PR91114

The following fixes PR91114. It's not really the most desirable solution but hey. Bootstrapped / tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2019-07-09 Richard Biener PR tree-optimization/91114 * tree-vect-data-refs.c (vect_analyze_data_refs): Failure to

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

On 09.07.19 14:02, Gaius Mulley wrote: > Matthias Klose writes: > >>> - There are three letter libraries with pretty generic >>>names installed into the system libdir: log, iso, cor, >>>min, ulm. At least for log, you have a file conflict >>>with another library. Shouldn't these lib

Re: [PATCH] Restrict LOOP_ALIGN to loop headers only.

Hi, On Tue, 9 Jul 2019, Richard Biener wrote: > > So a "backedge" in this sense would be e->dest->index < e->src->index. > > No? > > To me the following would make sense. The basic block index is not a DFS index, so no, that's not a test for backedge. Ciao, Michael.

Re: Make nonoverlapping_component_refs work with duplicated main variants

> > tree_int_cst_equal will return false if offsets are not INTEGER_CST. > > I was not sure if I can safely use operand_equal_p. What happens for > > fields with variable offsets when I inline two copies of same function > > which takes size as parameter and make the size different? Will I get > >

[PATCH v3 2/5] or1k: Fix issues with msoft-div

Fixes bad assembly logic with software divide as reported by Richard Selvaggi. Also, add a basic test to verify the soft math works when enabled. gcc/testsuite/ChangeLog: PR target/90362 * gcc.target/or1k/div-mul-3.c: New test. libgcc/ChangeLog: PR target/90362 *

[PATCH v3 3/5] or1k: Add mrori option, fix option docs

gcc/ChangeLog: * config.gcc (or1k*-*-*): Add mrori and mror to validation. * doc/invoke.texi (OpenRISC Options): Add mrori option, rewrite all documenation to be more clear. * config/or1k/elf.opt (mboard=, mnewlib): Rewrite documentation to be more clear.

[PATCH v3 5/5] or1k: only force reg for immediates

The force_reg in or1k_expand_compare is hard coded for SImode, which is fine as this used to only be used on SI expands. However, with FP support this will cause issues. In general we should only force the right hand operand to a register if its an immediate. This patch adds an condition to chec

[PATCH v3 4/5] or1k: Initial support for FPU

This adds support for OpenRISC hardware floating point instructions. This is enabled with the -mhard-float option. Double-prevision floating point operations work using register pairing as specified in: https://openrisc.io/proposals/orfpx64a32. This has just been added in the OpenRISC architectur

[PATCH v3 1/5] or1k: Fix code quality for volatile memory loads

Volatile memory does not match the memory_operand predicate. This causes extra extend/mask instructions instructions when reading from volatile memory. On OpenRISC loading volatile memory can be treated the same as regular memory loads which supports combined sign/zero extends. Fixing this elimi

[PATCH v3 0/5] OpenRISC updates for 10 (fpu, fixes)

Hello, New since v2: - Fix comment formatting pointed out by Segher in valatile patch - Fix issue and add test for rotrsi3 options pointed out by Segher - Fix issue with reg mask for doubles being backwards Pointed out by Segher and Richard. New since v1: - Changed 64-bit FPU operations to

Re: [PATCH] Deprecate -frepo option.

On 7/9/19 1:41 PM, Nathan Sidwell wrote: > On 7/9/19 6:39 AM, Richard Biener wrote: >> On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: >>> > >>> >>> Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS >>> 17) and >>> apparently 17 is not enough to resolve all symbols. And

Re: [patch 1/2][aarch64]: redefine aes patterns

Hi Sylvia, On 7/8/19 5:59 PM, Sylvia Taylor wrote: Hi James, I forgot to mention that. Yes, please do commit it on my behalf. I've committed this on your behalf with r273304. Thanks, Kyrill Cheers, Syl

Re: Make nonoverlapping_component_refs work with duplicated main variants

On Tue, 9 Jul 2019, Jan Hubicka wrote: > > For consistency yes I guess but IIRC they cannot really appear in > > FIELD_DECLs. > > OK, i tought that if I put SVE into structures, we may end up with > these. > > > + /* Different fields of the same record type cannot overlap. > > > + ??? Bitf

Re: Make nonoverlapping_component_refs work with duplicated main variants

> For consistency yes I guess but IIRC they cannot really appear in > FIELD_DECLs. OK, i tought that if I put SVE into structures, we may end up with these. > > + /* Different fields of the same record type cannot overlap. > > +??? Bitfields can overlap at RTL level so punt on them. */

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

Hi Matthias, > I had a look at the GCC 9 version of the patches, with a build including a > make > install. Some comments: > > - A parallel build (at least with -j4) isn't working. A sequental >build works fine. I think forcing a sequential build will not >work well, increasing the buil

Re: [PATCH, RISC-V] Fix ambiguous mode of some compare insn

Hello Jim, On 2019/07/08 13:41, Jim Wilson wrote: On Sat, Jul 6, 2019 at 1:26 AM Katsuhiro Suzuki wrote: This patch fixes ambiguous mode of some compare insns of RISC-V. Only sge, slt and sle are using but other compare insns use . It seems first group mode settings are ambiguous. Richard S

[PATCH] Properly valueize according to availability in all cases

We're relying on this for correctness, placing an assert triggers easily so we're not handling things fully correctly in all paths leading up to here. So simply valueize appropriately in vn_nary_build_or_lookup_1 which should make using value-numbers where it is more natural possible. I've also

Re: Make nonoverlapping_component_refs work with duplicated main variants

On Tue, 9 Jul 2019, Jan Hubicka wrote: > Hi, > this is updated patch. I based the logic on gimple_compare_field_offset but > dropped bits about PLACEHOLDER_EXPR since my understanding is that to get > comparsion done I would then need to compare operand #2 of COMPONENT_REF which > I don't. > > I

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

Matthias Klose writes: >> - There are three letter libraries with pretty generic >>names installed into the system libdir: log, iso, cor, >>min, ulm. At least for log, you have a file conflict >>with another library. Shouldn't these libraries named >>mpre specific, like libgm2lo

Re: Make nonoverlapping_component_refs work with duplicated main variants

Hi, this is updated patch. I based the logic on gimple_compare_field_offset but dropped bits about PLACEHOLDER_EXPR since my understanding is that to get comparsion done I would then need to compare operand #2 of COMPONENT_REF which I don't. I also wrote the range checks using polyint since I bel

Re: [PATCH] Deprecate -frepo option.

On 7/9/19 6:39 AM, Richard Biener wrote: On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS 17) and apparently 17 is not enough to resolve all symbols. And it's really slow. Ouch. hm, 17 is a magic number. in C++

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

Rainer Orth writes: > here are some initial issues. I'll reply to Matthias' mail to expand on > other problems he's raised. > > * First, the build broke like this: > > /vol/gcc/src/hg/trunk/solaris/gcc/gm2/mc-boot/GRTint.c:57:30: error: 'time' > redeclared as different kind of symbol >57 |

[OG9] Improve diagnostics for unmappable types

I've backported Jakub's patch to openacc-gcc-9-branch. Andrew On 08/07/2019 23:10, Jakub Jelinek wrote: On Thu, Jul 04, 2019 at 12:44:32PM +0100, Andrew Stubbs wrote: On 03/07/2019 18:58, Jason Merrill wrote: OK, thanks. Committed. This broke following testcase. error_mark_node type isn't

Re: [PATCH] Deprecate -frepo option.

On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: > > On 6/21/19 4:28 PM, Richard Biener wrote: > > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote: > >> > >> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote: > >>> On 6/21/19 1:58 PM, Jakub Jelinek wrote: > On Fri, Jun 21, 2

Re: [PATCH] Restrict LOOP_ALIGN to loop headers only.

On Tue, Jul 9, 2019 at 12:23 PM Richard Biener wrote: > > On Tue, Jul 9, 2019 at 12:22 PM Richard Biener > wrote: > > > > On Tue, Jul 9, 2019 at 11:56 AM Jan Hubicka wrote: > > > > > > > Hi. > > > > > > > > I'm suggesting to restrict LOOP_ALIGN to only loop headers. That are the > > > > basic bl

Re: [PATCH] Restrict LOOP_ALIGN to loop headers only.

On Tue, Jul 9, 2019 at 12:22 PM Richard Biener wrote: > > On Tue, Jul 9, 2019 at 11:56 AM Jan Hubicka wrote: > > > > > Hi. > > > > > > I'm suggesting to restrict LOOP_ALIGN to only loop headers. That are the > > > basic blocks for which it makes the biggest sense. I quite some binary > > > size r

Re: [PATCH] Restrict LOOP_ALIGN to loop headers only.

On Tue, Jul 9, 2019 at 11:56 AM Jan Hubicka wrote: > > > Hi. > > > > I'm suggesting to restrict LOOP_ALIGN to only loop headers. That are the > > basic blocks for which it makes the biggest sense. I quite some binary > > size reductions on SPEC2006 and SPEC2017. Speed numbers are also slightly > >

Re: [PATCH 1/2] Come up with function_decl_type and use it in tree_function_decl.

On Tue, 9 Jul 2019, Martin Liška wrote: On 7/9/19 9:49 AM, Marc Glisse wrote: On Tue, 9 Jul 2019, Marc Glisse wrote: On Mon, 8 Jul 2019, Martin Liška wrote: The patch apparently has DECL_IS_OPERATOR_DELETE only on the replaceable global deallocation functions, not all delete operators, con

Re: [C++ Patch] A few additional location improvements to grokdeclarator and check_tag_decl

Hi, On 08/07/19 23:44, Jason Merrill wrote: On 6/23/19 7:58 AM, Paolo Carlini wrote: +    error_at (smallest_type_location (get_type_quals (declspecs), +  declspecs->locations), How about adding a smallest_type_location overload that just takes declspecs? Sure. The below

Re: [PATCH] Restrict LOOP_ALIGN to loop headers only.

On 7/9/19 11:56 AM, Jan Hubicka wrote: >> Hi. >> >> I'm suggesting to restrict LOOP_ALIGN to only loop headers. That are the >> basic blocks for which it makes the biggest sense. I quite some binary >> size reductions on SPEC2006 and SPEC2017. Speed numbers are also slightly >> positive. >> >> Patc

Re: [patch] Small improvements to coverage info (3/n)

> 2019-07-08 Eric Botcazou > > * emit-rtl.c (set_insn_locations): New function moved from... > * function.c (set_insn_locations): ...here. > * ira-emit.c (emit_moves): Propagate location of the first instruction > to the inserted move instructions. > * reg-stack.c

Re: [patch, c++ openmp] Improve diagnostics for unmappable types

On 08/07/2019 23:10, Jakub Jelinek wrote: This broke following testcase. error_mark_node type isn't really incomplete, it is errorneous, doesn't have TYPE_MAIN_DECL and we should have diagnosed it earlier, so it makes no sense to emit extra explanation messages. Apologies. Did I miss something

Re: [PATCH] Restrict LOOP_ALIGN to loop headers only.

> Hi. > > I'm suggesting to restrict LOOP_ALIGN to only loop headers. That are the > basic blocks for which it makes the biggest sense. I quite some binary > size reductions on SPEC2006 and SPEC2017. Speed numbers are also slightly > positive. > > Patch can bootstrap on x86_64-linux-gnu and survi

Re: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING

On Tue, Jul 9, 2019 at 9:28 AM Aldy Hernandez wrote: > > > > On 7/4/19 6:33 AM, Richard Biener wrote: > > On Wed, Jul 3, 2019 at 2:17 PM Aldy Hernandez wrote: > >> > >> On 7/3/19 7:08 AM, Richard Biener wrote: > >>> On Wed, Jul 3, 2019 at 11:19 AM Aldy Hernandez wrote: > > > >> How about we keep

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

On 08.07.19 23:19, Matthias Klose wrote: > On 14.06.19 15:09, Gaius Mulley wrote: >> >> Hello, >> >> here is version two of the patches which introduce Modula-2 into the >> GCC trunk. The patches include: >> >> (*) a patch to allow all front ends to register a lang spec function. >>(inc

Re: [PATCH] Improve scan_operand_equal_p

On Tue, Jul 9, 2019 at 12:13 AM Jakub Jelinek wrote: > > Hi! > > The 4 testcases below weren't vectorized, because while > tree-vect-data-refs.c now allows more forms of simd lane access, > scan_operand_equal_p didn't allow combining them together. > > Fixed thusly, bootstrapped/regtested on x86_6

Re: [patch 2/2][arm]: redefine aes patterns

Hi Sylvia, On 7/5/19 12:32 PM, Sylvia Taylor wrote: Greetings, This patch removes the arch-common aese/aesmc and aesd/aesimc fusions (i.e. aes fusion) implemented in the scheduling phase through the aarch_crypto_can_dual function. The reason is due to observing undesired behaviour in cases such

Re: [PATCH][ARM][testsuite] Fix address of sg stubs in CMSE tests

Hi Christophe, On 7/2/19 3:41 PM, Christophe Lyon wrote: Hi, While running the GCC testsuite with an armv8-m target, I noticed that a few tests where causing the BFD linker to crash. I opened PR ld/24709 for this [1], but fixing it properly is tricky and not worth the headache. I "fixed" the l

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v2)

Hi Gaius, >> it rather depends upon what you want, if you want the latest complete >> gm2 grafting onto the svn gcc trunk then these two scripts will create a >> patched tree and also rebuild gm2. > > that's my goal: I'd like to see if gm2 and libgm2 build on Solaris and > pass at least a reasonab

Re: [PATCH] Support __builtin_expect_with_probability for analysis of # of loop iterations.

On 7/4/19 6:02 PM, Jan Hubicka wrote: > perhaps we want to also document that builtin-expect can be used this way? > It owuld be also nice to have a testcase. Good idea! I'm going to install the following patch. Martin >From 6b59938eff83600ae237409de027040b7904f66d Mon Sep 17 00:00:00 2001 From:

Re: [PATCH v2] S/390: Improve storing asan frame_pc

On 02.07.19 17:34, Ilya Leoshkevich wrote: ... > 2019-06-28 Ilya Leoshkevich > > * asan.c (asan_emit_stack_protection): Provide an alignment > hint. > * config/s390/s390.h (CODE_LABEL_BOUNDARY): Specify that s390 > requires code labels to be aligned on a 2-byte boundary.

Re: [PATCH 1/2] Come up with function_decl_type and use it in tree_function_decl.

On 7/9/19 9:49 AM, Marc Glisse wrote: > On Tue, 9 Jul 2019, Marc Glisse wrote: > >> On Mon, 8 Jul 2019, Martin Liška wrote: >> The patch apparently has DECL_IS_OPERATOR_DELETE only on the replaceable global deallocation functions, not all delete operators, contrary to DECL_IS_OPER

Re: [PATCH] Re-instantiate access-path based analysis during VN

On Mon, 8 Jul 2019, Richard Biener wrote: > > This re-instantiates the patch I had to revert earlier, doing it in > a safer way. We record the original ref so we can do an additional > disambiguation during vn_reference_lookup_3. > > Bootstrap and regtest running on x86_64-unknown-linux-gnu. A

[Ada] Missing escape of the double quote in JSON output

In Ada, the name of operators contains a pair of double quotes, which need to be properly escaped when the name appears in the JSON output of -gnatR. The change also ensures that formal parameters are not listed in the layout information, since this information is not back-annotated for them. Tes

  1   2   >