[RFA][PATCH] patch 5/n Cleaning up evrp

So with the major reorganization bits in place it's time to start cleaning up. This patch is primarily concerned with cleanups to the evrp_dom_walker class. We pull a blob of code from execute_early_vrp into a new member function. That subsequently allows various data members to become pr

[RFA][PATCH] patch 7/n Introduce evrp_range_analyzer class

This patch introduces the evrp_range_analyzer class. This is the class we're going to be able to embed into existing dominator walkers to provide them with context sensitive range analysis. The bulk of the class is extracted from the evrp_dom_walker class. A few minor notes. Setup o

Re: [RFA][PATCH] patch 6/n Refactoring evrp

On Fri, Nov 17, 2017 at 8:18 AM, Jeff Law wrote: > > As I've stated several times one of the goals here is to provide a > little range analysis module that we can embed & reuse. > > To accomplish that I need to break down the evrp class. > > This patch

Re: [PATCH][testcase]patch for fixing PR 86519

On 08/29/2018 08:53 AM, Qing Zhao wrote: > Hi, > > this is the patch to fix PR86519. > > Per Jeff’s suggestion, I removed strcmpopt_6.c from gcc.dg, and > added it to gcc.target/aarch64 and gcc.target/i386. > > retested on x86 and aarch64. no issue. > > Okay to

Re: C++ PATCH to refine c++/87109 patch

On Wed, Sep 19, 2018 at 9:50 PM, Marek Polacek wrote: > Aaaand this addresses > , > as I promised earlier. I hope I got it right. > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > 2018-09-19 Marek Polacek > > PR c++/8

Re: C++ PATCH to refine c++/87109 patch

On Thu, Sep 20, 2018 at 11:25:38AM -0400, Jason Merrill wrote: > On Wed, Sep 19, 2018 at 9:50 PM, Marek Polacek wrote: > > Aaaand this addresses > > , > > as I promised earlier. I hope I got it right. > > > > Bootstrapped/regtested on x86_6

Re: C++ PATCH to refine c++/87109 patch

On Thu, Sep 20, 2018 at 11:53 AM, Marek Polacek wrote: > On Thu, Sep 20, 2018 at 11:25:38AM -0400, Jason Merrill wrote: >> On Wed, Sep 19, 2018 at 9:50 PM, Marek Polacek wrote: >> > Aaaand this addresses >> > , >> > as I promised earlier.

Re: C++ PATCH to refine c++/87109 patch

On Thu, Sep 20, 2018 at 12:20:08PM -0400, Jason Merrill wrote: > On Thu, Sep 20, 2018 at 11:53 AM, Marek Polacek wrote: > > On Thu, Sep 20, 2018 at 11:25:38AM -0400, Jason Merrill wrote: > >> On Wed, Sep 19, 2018 at 9:50 PM, Marek Polacek wrote: > >> > Aaaand this addresses > >> >

Re: C++ PATCH to refine c++/87109 patch

OK. On Thu, Sep 20, 2018 at 4:49 PM, Marek Polacek wrote: > On Thu, Sep 20, 2018 at 12:20:08PM -0400, Jason Merrill wrote: >> On Thu, Sep 20, 2018 at 11:53 AM, Marek Polacek wrote: >> > On Thu, Sep 20, 2018 at 11:25:38AM -0400, Jason Merrill wrote: >> >> On Wed, Sep 19, 2018 at 9:50 PM, Marek Po

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised #2), Subpatch #05 (patch included)

On Fri, Oct 23, 2015 at 01:39:36PM -0400, Michael Meissner wrote: > This patch prevents the compiler from calling the IEEE 128-bit emulation > functions with the vector value in both GPRs and vector registers due to the > fact that the library function did not have a prototype. > &g

[PATCH], V4, patch #11 [part of patch #4.2], Adjust insn cost for prefixed instructions

I was asked to split V4 patch #4.2 into smaller chuncks. This patch is one of 8 patches that were broken out from 4.2. Another patch from 4.2 to use SIGNED_16BIT_OFFSET_EXTRA_P has already been committed. This patch adjusts the insn cost to treat prefixed instructions the same as non-prefixed

[PATCH], V4, patch #14 [part of patch #4.2], Update vector 128-bit instruction sizes

I was asked to split V4 patch #4.2 into smaller chuncks. This patch is one of 8 patches that were broken out from 4.2. Another patch from 4.2 to use SIGNED_16BIT_OFFSET_EXTRA_P has already been committed. This patch adjusts the instruction size for prefixed addresses for vector 128-bit types

Re: [PATCH], V4, patch #9 [part of patch #4.2], Add prefixed address offset checks

return 1; > + > + /* Handle prefixed addresses (PC-relative or 34-bit offset). */ > + if (address_is_prefixed (x, mode, NON_PREFIXED_DEFAULT)) > +return 1; Is this correct? Are addresses with a larger offset always legitimate? I don't see why that would be the case. The rest of the patch looks good, thanks. Segher

Re: [PATCH], V4, patch #9 [part of patch #4.2], Add prefixed address offset checks

gt; Is this correct? Are addresses with a larger offset always legitimate? > I don't see why that would be the case. > > The rest of the patch looks good, thanks. As far as I know, with the exception of SDmode (which is not allowed to have an offset) all other modes that use D*-form a

Re: [PATCH], V4, patch #9 [part of patch #4.2], Add prefixed address offset checks

gt; Is this correct? Are addresses with a larger offset always legitimate? > I don't see why that would be the case. > > The rest of the patch looks good, thanks. This patch BTW is the same as the new V5 patch #1. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH], V4, patch #9 [part of patch #4.2], Add prefixed address offset checks

On Wed, Oct 09, 2019 at 07:40:23PM -0400, Michael Meissner wrote: > On Wed, Oct 09, 2019 at 04:56:48PM -0500, Segher Boessenkool wrote: > > On Fri, Oct 04, 2019 at 08:29:11AM -0400, Michael Meissner wrote: > > > @@ -8651,6 +8675,11 @@ rs6000_legitimate_address_p (machine_mod > > >&& mode_su

[RFA][PATCH] patch 4/n Refactor bits of vrp_visit_assignment_or_call -- correct patch attached this time

No nyquil tonight, so the proper patch is attached this time... -- So the next group of changes is focused on breaking down evrp into an analysis engine and the actual optimization pass. The analysis engine can be embedded into other dom walker passes quite easily. I've done it fo

[Patch, Fortran] Fix previous patch (was: Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules)

Attached is a regtested patch, which fixes the issue. Additionally, the variable visibility (TREE_PUBLIC) is now depending on the private attribute (copied from the module var generation) and I mark the tree as DECL_NONALIASED. The former I also did for proc-pointers, which is an unrelated

[PATCH], V4, patch #13 [part of patch #4.2], Update stack protect insns for prefixed addresses

I was asked to split V4 patch #4.2 into smaller chuncks. This patch is one of 8 patches that were broken out from 4.2. Another patch from 4.2 to use SIGNED_16BIT_OFFSET_EXTRA_P has already been committed. This patch makes the stack_protect_setdi and stack_protect_testdi insns work if the stack

[PATCH], V4, patch #15 [part of patch #4.2], Make vector extract/insert support prefixed instructions

I was asked to split V4 patch #4.2 into smaller chuncks. This patch is one of 8 patches that were broken out from 4.2. Another patch from 4.2 to use SIGNED_16BIT_OFFSET_EXTRA_P has already been committed. This patch updates the functions that adjust a vector address to access a scalar element

[PATCH], V4, patch #18 [Same as patch #7], Use PADDI to add 34-bit constants

This is the same as patch #7, but was re-issued after patches 9-15 replaced the old patch #4. This patch generates the PADDI instruction to add 34-bit constant values on the 'future' system. Using all of the patches in this series, I have bootstrapped the compiler on a little end

[PATCH], V4, patch #19 [Same as patch #8], Enable -mpcrel on Linux 64-bit systems

This is the same as patch #8, but re-issued after patches 9-15 replaced the old patch #4. This patch enables -mpcrel for the default on Linux 64-bit systems when compiling for -mcpu=future. If/when other OSs add support for prefixed instructions (including PC-relative instructions), it is simple

Re: patch to fix constant math - second small patch -patch ping for next stage 1

Here is the second of my wide int patches with the patch rot removed. I would like to get these pre approved for the next stage 1. On 10/05/2012 06:48 PM, Kenneth Zadeck wrote: This patch adds machinery to genmodes.c so that largest possible sizes of various data structures can be determined at

Re: patch to fix constant math - second small patch -patch ping for next stage 1

On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck wrote: > Here is the second of my wide int patches with the patch rot removed. > > I would like to get these pre approved for the next stage 1. > On 10/05/2012 06:48 PM, Kenneth Zadeck wrote: >> >> This patch adds machine

Re: patch to fix constant math - second small patch -patch ping for next stage 1

On 03/27/2013 10:18 AM, Richard Biener wrote: On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck wrote: Here is the second of my wide int patches with the patch rot removed. I would like to get these pre approved for the next stage 1. On 10/05/2012 06:48 PM, Kenneth Zadeck wrote: This patch

Re: patch to fix constant math - second small patch -patch ping for next stage 1

On Wed, Mar 27, 2013 at 3:23 PM, Kenneth Zadeck wrote: > > On 03/27/2013 10:18 AM, Richard Biener wrote: >> >> On Wed, Feb 27, 2013 at 1:27 AM, Kenneth Zadeck >> wrote: >>> >>> Here is the second of my wide int patches with the patch rot removed. >

Re: patch to fix constant math - second small patch -patch ping for next stage 1

patch rot removed. I would like to get these pre approved for the next stage 1. On 10/05/2012 06:48 PM, Kenneth Zadeck wrote: This patch adds machinery to genmodes.c so that largest possible sizes of various data structures can be determined at gcc build time. These functions create 3 symbols

Re: [RFA][PATCH] patch 4/n Refactor bits of vrp_visit_assignment_or_call -- correct patch attached this time

On Fri, Nov 17, 2017 at 5:17 AM, Jeff Law wrote: > No nyquil tonight, so the proper patch is attached this time... > > -- > > > > So the next group of changes is focused on breaking down evrp into an > analysis engine and the actual optimization pass. The analysis engin

[Patch, Fortran] Follow up patch to the backtrace changes

This patch re-adds the option -f(no-)backtrace as Ignored to improve backward compatibility. Additionally, for ERROR STOP, no backtrace is printed any more. Build on x86-64-linux. OK for the trunk? Tobias 2011-05-14 Tobias Burnus * lang.opt (fdump-core): Re-add as ignored option for

[PATCH, testsuite] Additional tests for PR46728 (PR46728 patch 4)

nteed. This patch is conditional on patch 3 of the PR46728 series; without it, test pr46728-16.c will fail, since the FMA will not be generated. All other tests currently pass. OK to add to test suite on trunk? Thanks, Bill 2011-05-25 Bill Schmidt * gcc.target/powerpc/pr46728-1.c

Re: [PATCH] Adjustment to DW_TAG_GNU_call_site patch for ICF debug

On 03/15/2011 04:22 AM, Jakub Jelinek wrote: > Here is the > http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01795.html > patch updated to current trunk, bootstrapped/regtested on x86_64-linux > and i686-linux. Ok for trunk? Ok. r~

Re: [PATCH] Adjustment to DW_TAG_GNU_call_site patch for ICF debug

Jakub Jelinek writes: > + { > + int nargs = list_length (TYPE_ARG_TYPES (type)); > + link = CALL_INSN_FUNCTION_USAGE (insn); ../../gcc/var-tracking.c: In function 'prepare_call_arguments': ../../gcc/var-tracking.c:5623:12: error: unused variable 'nargs' [-Werror=unus

Re: [PATCH] Adjustment to DW_TAG_GNU_call_site patch for ICF debug

On Wed, Mar 16, 2011 at 11:11:07AM +0100, Andreas Schwab wrote: > Jakub Jelinek writes: > > > + { > > + int nargs = list_length (TYPE_ARG_TYPES (type)); > > + link = CALL_INSN_FUNCTION_USAGE (insn); > > ../../gcc/var-tracking.c: In function 'prepare_call_arguments': > ../..

[PATCH], Patch #5, Improve vector int initialization on PowerPC

This is a rewrite of patch #3 to improve vector int initialization on the PowerPC 64-bit systems wtih direct move (power8, and forthcoming power9). This patch adds full support for doing vector int initialization in the GPR and vector registers, rather than creating a stack temporary, doing 4

Re: [PATCH] Fixups for Martin's gimple-ssa-sprintf.c patch

On 08/25/2016 10:23 AM, David Malcolm wrote: Martin: here are the fixups for your patch I needed to apply to make it work with mine. I couldn't actually get any of your existing test cases to emit locations within the string literals, due to them all being embedded in macro expansions (pos

Re: [PATCH], Patch #7, Add PowerPC vector initialization tests

On Fri, Aug 26, 2016 at 03:29:50PM -0400, Michael Meissner wrote: > These patches add more tests to the PowerPC vector initialization tests. Four > of the tests added (#4, #5, #8, and #9) just try to do a bunch of vector > initializations for the different vector type (char, short, float, and > d

Re: [PATCH], Patch #7, Add PowerPC vector initialization tests

On Fri, Aug 26, 2016 at 08:24:40PM -0500, Segher Boessenkool wrote: > On Fri, Aug 26, 2016 at 03:29:50PM -0400, Michael Meissner wrote: > > These patches add more tests to the PowerPC vector initialization tests. > > Four > > of the tests added (#4, #5, #8, and #9) just try to do a bunch of vecto

Re: [PATCH] Fixups for Martin's gimple-ssa-sprintf.c patch

On Wed, 2016-08-31 at 10:23 -0600, Martin Sebor wrote: > On 08/25/2016 10:30 AM, Martin Sebor wrote: > > On 08/25/2016 10:23 AM, David Malcolm wrote: > > > Martin: here are the fixups for your patch I needed to apply to > > > make > > > it work with mine.

Re: [PATCH] Fixups for Martin's gimple-ssa-sprintf.c patch

On 08/25/2016 10:30 AM, Martin Sebor wrote: On 08/25/2016 10:23 AM, David Malcolm wrote: Martin: here are the fixups for your patch I needed to apply to make it work with mine. I couldn't actually get any of your existing test cases to emit locations within the string literals, due to the

Re: [PATCH] Fixups for Martin's gimple-ssa-sprintf.c patch

On 08/31/2016 10:26 AM, David Malcolm wrote: On Wed, 2016-08-31 at 10:23 -0600, Martin Sebor wrote: On 08/25/2016 10:30 AM, Martin Sebor wrote: On 08/25/2016 10:23 AM, David Malcolm wrote: Martin: here are the fixups for your patch I needed to apply to make it work with mine. I couldn&#

Re: [PATCH 4/4] (v2) Add -fdiagnostics-generate-patch

On Wed, 2016-08-24 at 21:13 -0400, David Malcolm wrote: > Changed in v2: I dropped -fdiagnostics-apply-fixits > > This patch uses the edit_context machinery to provide a new > -fdiagnostics-generate-patch option. > > If set an edit_context is created for global_dc, and any >

[PATCH], PowerPC, add ISA 3.0 xxperm (power9 patch #12)

This patch adds support for the ISA 3.0 XXPERM instruction, which is like VPERM, except it can operate on any VSX register. Since the instruction is a 3 operand instruction (RT and RA must be the same), I made it so VPERM was preferred. I also added XXPERM fusion support where a XXLOR move

[Patch, MIPS] Patch for PR 68400, a mips16 bug

Here is a patch for PR6400. The problem is that and_operands_ok was checking one operand to see if it was a memory_operand but MIPS16 addressing is more restrictive than what the general memory_operand allows. The fix was to call mips_classify_address if TARGET_MIPS16 is set because it will do a

[PATCH] Follow-up patch on enabling new AVX512 instructions

Hi, this is follow-up with tests for new __target__ attributes and __builtin_cpu_supports update. gcc/ * config/i386/i386.c (processor_features): Add F_AVX5124VNNIW, F_AVX5124FMAPS. (isa_names_table): Handle new features. libgcc/ * config/i386/cpuinfo.c (processor_

[Patch, Fortran] Preparatory patch to change charlen's kind type

Hi all, during hacking in gfortran I found, that for unlimited polymorphic types the size type of a char array stored is hard coded to be 4. This small patch resolves this by using the better suited constant: gfc_charlen_int_kind. This will make the move to larger strings easier. Bootstrapped

Re: [PATCH][Middle-end]patch for fixing PR 86519

_builtin_memcmp” appears in the .expand file varies on different > target or optimization level, in order to avoid such > instability, instead of scanning the .expand file to match the string > “__builtin_memcmp”, scanning the final assembly file to match > the string

Re: [PATCH][Middle-end]patch for fixing PR 86519

> On Aug 14, 2018, at 11:25 PM, Jeff Law wrote: > > On 08/14/2018 08:57 AM, Qing Zhao wrote: >> Hi, >> >> PR 86519:New test case gcc.dg/strcmpopt_6.c fails with its introduction in >> r262636. >> >> gcc/ChangeLog: >> >> +2018-08-14 Qing Zhao >> + >> + PR testsuite/86519 >> +

Re: [PATCH][Middle-end]patch for fixing PR 86519

Hi Qing: > > the change has been committed as: > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263563 > > > Qing > The strcmpopt_6.c test still fails on mips64el target. gcc.dg/strcmpopt_6.c: memcmp found 4 times FAIL: gcc

Re: [PATCH][Middle-end]patch for fixing PR 86519

On 08/17/2018 09:43 PM, Paul Hua wrote: > Hi Qing: > >> >> the change has been committed as: >> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263563 >> >> >> Qing >> > > The strcmpopt_6.c test still fails on mips64el target

Re: [PATCH][Middle-end]patch for fixing PR 86519

Hi Jeff, > On 08/17/2018 09:43 PM, Paul Hua wrote: >> Hi Qing: >> >>> >>> the change has been committed as: >>> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263563 >>> >>> >>> Qing >>> >> >> The strcmpopt_6.c test still fa

[PATCH], Patch #1 of 10, Add instruction format enumeration

This patch implements the insn_form enumeration that identifies which types of instruction format is used for memory instruction. While the PowerPC has additional formats, the instruction formats that we need to use are: INSN_FORM_D -- Traditional D-form instructions (16 bits offset

[PATCH], Patch #2 of 10, Add RTL prefixed attribute

This patch adds the RTL attribute "prefixed" that says this particular instruction is a prefixed instruction. The target hooks FINAL_SCAN_INSN and ASM_OUTPUT_OPCODE are defined. If the insn is prefixed, ASM_OUTPUT_OPCODE will emit a leading 'p' before the instruction is emit

[PATCH], Patch #3 of 10, Add prefixed addressing support

This patch adds prefixed memory support to all offsettable instructions. Unlike previous versions of the patch, this patch combines all of the modifications for addressing to one patch. Previously, I had 3 separate patches (one for PADDI, one for scalar types, and one for vector types). 2019-08

[PATCH], Patch #7 of 10, Add support for PCREL_OPT

This patch adds a new RTL pass that occurs before the final pass to implement the PCREL_OPT optimization that is implemented by the linker. Without this optimization, access to external symbols loads up the address from a .GOT section and does the normal operation. For example: extern

[PATCH], Patch #10 of 10, Add pc-relative tests

This patch adds tests to make sure the appropriate pc-relative instructions are generated for -mcpu=future. The tests in this patch all pass with patches 1-7 applied on a little endian power8 system running Linux. Once patches 1-7 have been applied, can I check these patches into the trunk

[PATCH] [Patch] Rename PSTL macro's consistent with libstdc++ standards.

0001-Patch-Rename-PSTL-macro-s-consistent-with-libstdc-st.patch.bz2 Description: Compressed patch * include/bits/c++config: Rename all macros of the form __PSTL* to _PSTL*. * include/std/algorithm: Likewise. * include/std/execution: Likewise. * include/std

[PATCH][Preprocessor][Version 2]patch to fix PR 90581

Hi, this is the 2nd version of the patch. the main changes are: 1. some typo. 2. enhance the error message to provide user idea on how to increase the limit. bootstrap and regression tested on X86, no issue. Okay for trunk? thanks. Qing gcc/ChangeLog: 2019-06-03 qing zhao

[PATCH][Preprocessor][Version 3]patch to fix PR 90581

Hi, this is the 3rd version of the patch, which fixed the issues Paolo raised in the previous email. Okay for trunk? thanks. gcc/ChangeLog: 2019-06-03 qing zhao * doc/cppopts.texi: Add document for -fmax-include-depth. * doc/invoke.texi (Preprocessor Options): List -fmax

[PATCH 0/3][stage1] [PATCH v2] LTO dump tool

Hi. The patch series is a remake of Hrishikesh's LTO dump tool that was part of GSoC last year. I decided to split the patch into 3 parts, where the first one is purely mechanical splitting code into a newly created one. The second part introduces the new tool. And the last one is abou

Re: [PATCH] PR fortran/87992 -- trivially stupid patch, but ...

On Sun, Dec 16, 2018 at 09:42:25AM -0800, Steve Kargl wrote: > The following patch removes the ICE reported in PR fortran/87992, > and restores the behavior observed with gfortran 7 and 8 (ie, > code compiles). > > The PR marks the code with ice-on-invalid-code. I don't u

Re: [PATCH] PowerPC Prefixed Memory, Patch #3, Update predicates

Hi Mike, On Thu, Jun 27, 2019 at 08:12:35PM -0400, Michael Meissner wrote: > + return (TARGET_CMODEL == CMODEL_MEDIUM && SYMBOL_REF_P (op) > + && SYMBOL_REF_LOCAL_P (op)); Please break the line before that first && as well? > +(define_predicate "pcrel_external_address" > + (match_code "s

Re: [PATCH] PowerPC Prefixed Memory, Patch #3, Update predicates

On 6/28/19 8:20 AM, Segher Boessenkool wrote: > Hi Mike, > > On Thu, Jun 27, 2019 at 08:12:35PM -0400, Michael Meissner wrote: >> + return (TARGET_CMODEL == CMODEL_MEDIUM && SYMBOL_REF_P (op) >> + && SYMBOL_REF_LOCAL_P (op)); > Please break the line before that first && as well? > >> +(define

Re: [PATCH] PowerPC Prefixed Memory, Patch #3, Update predicates

On Fri, Jun 28, 2019 at 08:20:35AM -0500, Segher Boessenkool wrote: > Hi Mike, > > On Thu, Jun 27, 2019 at 08:12:35PM -0400, Michael Meissner wrote: > > + return (TARGET_CMODEL == CMODEL_MEDIUM && SYMBOL_REF_P (op) > > + && SYMBOL_REF_LOCAL_P (op)); > > Please break the line before that firs

[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_ref

[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

[C++ Patch PING] Re: [C++ Patch] Improve compute_array_index_type locations

Hi, gently pinging this older patch of mine: given the previous create_array_type_for_decl change, its gist should not be very controversial... On 06/11/18 10:01, Paolo Carlini wrote: Hi, when I improved create_array_type_for_decl I didn't notice that it calls compute_array_index_ty

[PATCH] V4, patch #1: Rework prefixed/pc-relative lookup

This patch reworks the prefixed and pc-relative memory matching functions. As I said in the intro message, I do not re-use the address mask bits in reg_addr, but instead, I have a separate function that takes an address and decodes it into the various different flavors (single register address, D

[PATCH], V4, patch #4: Enable prefixed/pc-rel addressing

This patch is the patch that goes through and enables prefixed and pc-relative addressing on all modes, except for SDmode. SDmode is special in that for its main use, you need to only use X-form addressing. While you can do D-form addressing to load/store SDmode in GPR registers, I found you

[PATCH], V4.1, patch #2: Add prefixed insn attribute (revised)

This patch revises patch #2, fixing an issue that shows up in compiling large code like the Spec 2017 benchmark suite. The issue was when a vector register uses TImode, it needs to assume the non-prefixed instruction uses the DQ encoding. I also changed the spelling of PC-relative to be

Re: [PATCH], PowerPC IEEE 128-bit patch #7 (revised)

A heads up. I just found some places in the IEEE 128-bit floating point code where it doesn't handle conversions to/from __ibm128. Nor does it generate the same names for -mabi=ieeelongdouble. I will submit a revised patch when it is ready. -- Michael Meissner, IBM IBM, M/S 2506R, 550

[Patch] PowerPC IEEE 128-bit patch #7 (revised #2)

This is the revised patch #7 for the IEEE 128-bit software floating point support in the PowerPC. I have tested this on big endian power7 (both 32/64 bit) and little endian power8 with no regressions. Is this ok to install in the trunk? This patch should allow __float128 support on VSX systems

Re: [patch 9/9] Final patch with all changes

On 07/07/2015 02:51 PM, Andrew MacLeod wrote: > *** sel-sched-ir.h(revision 225452) > --- sel-sched-ir.h(working copy) > *** along with GCC; see the file COPYING3. > *** 22,34 > #define GCC_SEL_SCHED_IR_H > > /* For state_t. */ > - #include "insn-attr.h" > - #includ

Re: [patch 9/9] Final patch with all changes

too. Thanks, Pedro Alves Ah right. Previous version had them removed. Missed them when I rebuilt the patch. Thanks Andrew

Re: [PATCH], PowerPC IEEE 128-bit patch #4c (revised)

Seger pointed out that the altivec_high_bit insn was not safe if it was called when it could not allocate pseudos. I have removed that insn in this patch. I will revise the patch. I had meant to tie it in with easy_altivec_constant originally, and I will do a patch with that change. Is this

Re: [PATCH], PowerPC IEEE 128-bit patch #4c (revised)

On Thu, Jul 30, 2015 at 3:23 PM, Michael Meissner wrote: > Seger pointed out that the altivec_high_bit insn was not safe if it was called > when it could not allocate pseudos. I have removed that insn in this patch. I > will revise the patch. I had meant to tie it in with easy_altivec

Re: [PATCH], Add power9 support to GCC, patch #1

Hi, Some minor things... On Tue, Nov 03, 2015 at 03:29:11PM -0500, Michael Meissner wrote: > * config/rs6000/rs6000.opt (-mfusion-toc): Add new switches for > ISA 3.0 (power9). "-mtoc-fusion" sounds more natural, and is more in line with the other switches I think. > + /* ISA 2.08

Re: [PATCH], Add power9 support to GCC, patch #1

nstructions that were added in version 2.07 of the PowerPC ISA. Also > > +enable the use of built-in functions that allow more direct access to > > +the vector instructions. > > 3.0 here as well? I only found 3 references to 2.08 in the patch. Thanks. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: Re: [PATCH] [PATCH][ARM] Fix thumb-ltu.c testcase.

On 01/06/15 10:50, Ramana Radhakrishnan wrote: On 01/06/15 10:48, Alex Velenko wrote: Hi, This patch fix thumb-ltu.c to pass excess error test. Without default -std=gnu90 flag, this testcase started failing as some functions were called before being predefined. Is patch ok? gcc/testsuite

Re: [PATCH], Add power9 support to GCC, patch #4

This patch adds support for the EXTSWSLI instruction that is being added to PowerPC ISA 3.0 (power9). I have built this patch (along with patches #2 and #3) with a bootstrap build on a power8 little endian system. There were no regressions in the test suite. Is this patch ok to install in the

Re: [PATCH], Add power9 support to GCC, patch #4

On Sun, Nov 08, 2015 at 07:39:14PM -0500, Michael Meissner wrote: > +;; Pretend we have a memory form of extswsli until register allocation is > done > +;; so that we use LWZ to load the value from memory, instead of LWA. We generate sign_extend loads for many cases where zero_extend would be pre

Re: [PATCH], Add power9 support to GCC, patch #4

On Mon, Nov 09, 2015 at 10:29:10AM -0600, Segher Boessenkool wrote: > On Sun, Nov 08, 2015 at 07:39:14PM -0500, Michael Meissner wrote: > > +;; Pretend we have a memory form of extswsli until register allocation is > > done > > +;; so that we use LWZ to load the value from memory, instead of LWA.

Re: [PATCH], Add power9 support to GCC, patch #4

On Sun, Nov 8, 2015 at 4:39 PM, Michael Meissner wrote: > This patch adds support for the EXTSWSLI instruction that is being added to > PowerPC ISA 3.0 (power9). > > I have built this patch (along with patches #2 and #3) with a bootstrap build > on a power8 little endian system.

Re: [PATCH], Add power9 support to GCC, patch #4

On Mon, Nov 09, 2015 at 12:27:34PM -0500, Michael Meissner wrote: > On Mon, Nov 09, 2015 at 10:29:10AM -0600, Segher Boessenkool wrote: > > On Sun, Nov 08, 2015 at 07:39:14PM -0500, Michael Meissner wrote: > > > +;; Pretend we have a memory form of extswsli until register allocation > > > is done

[PATCH] [4.9] Re: [PATCH][5] Backport ISL 0.15 support

On 12.10.2015 12:58, Richard Biener wrote: This backports the patch to allow bootstrapping with ISL 0.15 to the GCC 5 branch (the GCC 4.9 branch will require backporting of some dependencies). I don't think so. 4.8 and 4.9 don't use as much ISL code as 5 does. I had a look at th

[PATCH, GOOGLE] Backport patch r212222 to google 4.9 branch

Hi The more strict devirtualization condition in this patch helps to fix google bug b/19872411. Bootstraped and regression tested on x86-64. OK for google 4.9 branch? patch Description: Binary data

[PATCH] Fix sanitizer/67258 (by cherry picking upstream patch)

Tested on ppc64le. OK for trunk and gcc-5? PR sanitizer/67258 * ubsan/ubsan_type_hash.cc: Cherry pick upstream r244101. Upstream patch: commit 1d2477faafda9ad2cc19927b3c31efd22747f013 Author: Alexey Samsonov Date: Wed Aug 5 19:35:46 2015 + [UBSan] Fix UBSan-vptr false

Re: PATCH: fix breakage from "[PATCH] Fix genmatch linking"

> From: Hans-Peter Nilsson > Date: Fri, 24 Oct 2014 06:32:06 +0200 > The libcpp configure checks are actually run with gcc which is > bogus by itself, but apparently working. I guess the C vs. C++ > declaration etc. differences for libcpp are mostly hidden by > using _GNU_SOURCE (through AC_USE_

Re: PATCH: fix breakage from "[PATCH] Fix genmatch linking"

cludes. > Still, a red herring. Aligning those options *may* cause the > build to succeed, but I think that'd be too much of sweeping the > issue under the carpet. > > It seems "more correct" to just disable the config.cache sharing > between the differently-conf

Re: PATCH: fix breakage from "[PATCH] Fix genmatch linking"

> From: Richard Biener > Date: Fri, 24 Oct 2014 09:56:51 +0200 > On Fri, 24 Oct 2014, Hans-Peter Nilsson wrote: > > Still, I don't understand exactly how your patch > > introduces build-subdirectories where there were none before. > > Maybe that "+all-gcc:

Re: PATCH: fix breakage from "[PATCH] Fix genmatch linking"

On October 24, 2014 6:47:10 PM CEST, Hans-Peter Nilsson wrote: >> From: Richard Biener >> Date: Fri, 24 Oct 2014 09:56:51 +0200 >> On Fri, 24 Oct 2014, Hans-Peter Nilsson wrote: >> > Still, I don't understand exactly how your patch >> > introduces b

[PATCH][Ping v2] Add patch for debugging compiler ICEs

Ping. Original Message Subject:[PATCH][Ping] Add patch for debugging compiler ICEs Date: Wed, 11 Jun 2014 18:15:27 +0400 From: Maxim Ostapenko To: GCC Patches CC: Yury Gribov , Slava Garbuzov , Jakub Jelinek , tsaund...@mozilla.com, chefm...@gmail.com

[PATCH][Ping v3] Add patch for debugging compiler ICEs

Ping. Original Message Subject:[PATCH][Ping v2] Add patch for debugging compiler ICEs Date: Thu, 26 Jun 2014 19:46:08 +0400 From: Maxim Ostapenko To: GCC Patches CC: Yury Gribov , Slava Garbuzov , Jakub Jelinek , tsaund...@mozilla.com, Maxim Ostapenko

[PATCH][Ping v4] Add patch for debugging compiler ICEs

Ping. Added small changes due to previous discussion in community. Original Message Subject:[PATCH][Ping v3] Add patch for debugging compiler ICEs Date: Fri, 04 Jul 2014 18:32:44 +0400 From: Maxim Ostapenko To: GCC Patches CC: Yury Gribov , Slava Garbuzov

[PATCH][Ping v5] Add patch for debugging compiler ICEs

Ping. Original Message Subject:[PATCH][Ping v4] Add patch for debugging compiler ICEs Date: Fri, 11 Jul 2014 17:44:28 +0400 From: Maxim Ostapenko To: GCC Patches CC: Yury Gribov , Slava Garbuzov , Jakub Jelinek , tsaund...@mozilla.com, Maxim Ostapenko

[PATCH] Fix patch mangling with --inline option in mklog

Diego, I noticed that a patch processed with mklog --inline got mangled. In mklog, first we read the .diff file into array diff_lines. Then, in the case of --inline, at the end we expect diff_lines still to contain the .diff file. That's not the case however, and that causes the man

Patch ping^2: [PATCH] -fsanitize=vptr instrumentation (take 2)

On Wed, Nov 12, 2014 at 03:05:46PM +0100, Jakub Jelinek wrote: > On Tue, Oct 28, 2014 at 01:44:50PM +0100, Jakub Jelinek wrote: > > On Mon, Oct 27, 2014 at 05:16:05PM +0100, Jakub Jelinek wrote: > > > Here is an updated patch, ok if bootstrap/testing passes (so far just

Re: [PATCH][AArch64] vrnd<*>_f64 patch for stage-1

On 02/13/2014 03:17 AM, Alex Velenko wrote: > +/* Sets "rmode" field of "FPCR" control register to > + "FPROUNDING_ZERO". */ Comment is wrong, or at least misleading. > +void __inline __attribute__ ((__always_inline__)) > +set_rounding_mode (uint32_t mode) > +{ > + uint32_t r; > + > + /* Rea

Re: [PATCH][AArch64] vrnd<*>_f64 patch for stage-1

= mode << RMODE_START; + + /* Write desired FPCR back. */ + asm volatile ("msr fpcr, %[r]" : : [r] "r" (r) :); +} Fortunately for this testcase, you do always use FPROUNDING_ZERO == 3 when calling this function, so the bugs are hidden. r~ Hi Richard, Thank you for po

Re: [PATCH][AArch64] vrnd<*>_f64 patch for stage-1

On 21 February 2014 12:44, Alex Velenko wrote: > This patch adds vrnd<*>_f64 aarch64 intrinsics. A testcase for those > intrinsics is added. Run a complete LE and BE regression run with no > regressions. > > Is patch OK for stage-1? > > gcc/ > > 2014-02-21

[PATCH] Fix C++ PATCH for C++14 sized deallocation

On Tue, Dec 16, 2014 at 05:54:04PM +0100, Jakub Jelinek wrote: > On Tue, Dec 16, 2014 at 10:16:42AM -0500, Jason Merrill wrote: > > On 12/16/2014 05:09 AM, Andreas Schwab wrote: > > >covariant4.C:(.text._ZN5ModelD2Ev[_ZN5ModelD5Ev]+0x1e): undefined > > >reference to `operator delete(void*, unsigne

<    2   3   4   5   6   7   8   9   10   11   >