[PATCH][arm][committed] Clean up code iterator usage in satsi* patterns

Hi all, GCC 10 now supports having RTL codes being code attributes (thanks Richard) allowing us to map smax to smin and vice versa. This means we can clean up their use in the saturation patterns that do the cross product of [smin, smax] and use the pattern predicate to cancel out the nonsense

Re: cp: implementation of p1301 for C++

I think I got the tabs right...? You would not believe how unbelievably hard it is, just to mail a diff! - 07-24-2019ThePhD gcc/ * escaped_string.h: New. Refactored out of tree.c to make more broadly available (e.g. to parser.c, cvt.c). * tree.c: remove escaped_string class gcc/c-

[PATCH] Adjust extract_range_from_multiplicative_op

To not extract type from op0. Bootstrapped and tested on x86_64-unknown-linux-gnu. 2019-07-25 Richard Biener * tree-vrp.c (extract_range_from_multiplicative_op): Add type parameter and use it instead of guessing expression type from the first operand. (extrac

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

On Thu, 25 Jul 2019, Martin Liška wrote: DCE has special code to avoid removing the LHS of malloc when it is unused. Is there something different about operator new that makes it not need the same handling? If you take gcc.dg/torture/pr51692.c and replace __builtin_calloc (1, sizeof (double

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

On Thu, 25 Jul 2019, Martin Jambor wrote: > Hello, > > On Tue, Jul 23 2019, Richard Biener wrote: > > The following fixes the runtime regression of 456.hmmer caused > > by matching ICC in code generation and using cmov more aggressively > > (through GIMPLE level MAX_EXPR usage). Appearantly (dis

[patch, fortran] Improve dependency checking

Hello world, the attached pach does some more work in gfc_check_dependency for the case where an identity between arguments would also lead to problems. It does not lead to removal of the warning with -Warray-temporaries, because that is still generated by the call to library function. Instead,

Re: [PATCH], Patch #10, move PowerPC data structures & helper functions from rs6000.c to rs6000-internal.h

Hi Mike, On Mon, Jul 22, 2019 at 06:37:35PM -0400, Michael Meissner wrote: > On Mon, Jul 22, 2019 at 03:56:26PM -0500, Segher Boessenkool wrote: > > That still needs an explanation: why is this a good thing, why do you > > want that change? Sometimes that is obvious of course, but here it is > >

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

On 7/25/19 2:18 PM, Marc Glisse wrote: > On Thu, 25 Jul 2019, Martin Liška wrote: > >>> DCE has special code to avoid removing the LHS of malloc when it is unused. >>> Is there something different about operator new that makes it not need the >>> same handling? > > If you take gcc.dg/torture/pr

Re: [PATCH V2, rs6000] Support vrotr3 for int vector types

Hi Kewen, On Tue, Jul 23, 2019 at 02:28:28PM +0800, Kewen.Lin wrote: > --- a/gcc/config/rs6000/altivec.md > +++ b/gcc/config/rs6000/altivec.md > @@ -1666,6 +1666,60 @@ >"vrl %0,%1,%2" >[(set_attr "type" "vecsimple")]) > > +;; Here these vrl_and are for vrotr3 expansion. > +;; since SHIFT

Re: [patch, fortran] Improve dependency checking

On Thu, Jul 25, 2019 at 02:57:35PM +0200, Thomas Koenig wrote: > Index: dependency.h > === > --- dependency.h (Revision 273733) > +++ dependency.h (Arbeitskopie) > @@ -37,7 +37,7 @@ int gfc_check_fncall_dependency (gfc_expr *

Re: [PATCH][ARM] Fix low reg issue in Thumb-2 movsi patterns

Hi Richard, > I think this should be "lk*r", not "l*rk".  SP is only going to crop up > in rare circumstances, but we are always going to need this pattern if > it does and hiding this from register preferencing is pointless.  It's > not like the compiler is going to start allocating SP in the

Re: [PATCH, rs6000] Fix PR91050 by adding a DRIVER_SELF_SPECS spec

On 7/25/19 2:50 AM, Iain Sandoe wrote: > This will break Darwin which has used DRIVER_SELF_SPECS in config/darwin.h > since they were introduced (and the equivalent before). > > This is because Darwin has driver self-specs common to the PPC and X86 ports. > > If this change is seen the way to go,

Re: [patch, fortran] Improve dependency checking

Hi Steve, -int gfc_dep_resolver(gfc_ref *, gfc_ref *, gfc_reverse *); +int gfc_dep_resolver(gfc_ref *, gfc_ref *, gfc_reverse *, bool identical = false); This is changing the prototype. I would expect to see int gfc_dep_resolver(gfc_ref *, gfc_ref *, gfc_reverse *, bool); Usig C++'s optio

Re: [PATCH, rs6000] Fix PR91050 by adding a DRIVER_SELF_SPECS spec

Hi Peter, > On 25 Jul 2019, at 15:41, Peter Bergner wrote: > > On 7/25/19 2:50 AM, Iain Sandoe wrote: >> This will break Darwin which has used DRIVER_SELF_SPECS in config/darwin.h >> since they were introduced (and the equivalent before). >> >> This is because Darwin has driver self-specs commo

Re: [PATCH, rs6000] Fix PR91050 by adding a DRIVER_SELF_SPECS spec

Hi Peter, On Thu, Jul 25, 2019 at 09:41:10AM -0500, Peter Bergner wrote: > On 7/25/19 2:50 AM, Iain Sandoe wrote: > > This will break Darwin which has used DRIVER_SELF_SPECS in config/darwin.h > > since they were introduced (and the equivalent before). > > > > This is because Darwin has driver se

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

On 7/25/19 3:30 PM, Martin Liška wrote: > On 7/25/19 2:18 PM, Marc Glisse wrote: >> On Thu, 25 Jul 2019, Martin Liška wrote: >> DCE has special code to avoid removing the LHS of malloc when it is unused. Is there something different about operator new that makes it not need the sam

tips for reviewing code

Here's a short article that I think is worth a read whether you mainly review code or usually find yourself on the receiving end. https://developers.redhat.com/blog/2019/07/08/10-tips-for-reviewing-code-you-dont-like Martin

Re: [patch, fortran] Improve dependency checking

On Thu, Jul 25, 2019 at 04:42:44PM +0200, Thomas Koenig wrote: > Hi Steve, > > >> -int gfc_dep_resolver(gfc_ref *, gfc_ref *, gfc_reverse *); > >> +int gfc_dep_resolver(gfc_ref *, gfc_ref *, gfc_reverse *, bool identical > >> = false); > > This is changing the prototype. I would expect to see >

Re: [patch, fortran] Improve dependency checking

Hi Steve, Ah, I don't speak C++, and didn't know one could corrupt a C prototype in this manner. A quick glance of gfortran.h indeed shows a few more occurences of "bool xxx = false". I suppose the patch is then OK. I don't use many C++ features, but I use this one because I feel it should re

Subject: [PATCH] [PR 89330] Remove non-useful speculations from new_edges

Hi, the following patch prevents the call speculation machinery from deallocating call graph edges from under the indirect inlining machinery and it also fixes a potential issue in speculation which could in some cases undo an earlier inlining decision, something that the inliner is not built to e

Re: [PATCH, rs6000] Fix PR91050 by adding a DRIVER_SELF_SPECS spec

Uros and Jan, I should have CC'd you for the i386 portion of the patch. Are you ok with the i386.h change if Iain's x86 Darwin testing comes out clean? Peter On 7/25/19 9:41 AM, Peter Bergner wrote: > On 7/25/19 2:50 AM, Iain Sandoe wrote: >> This will break Darwin which has used DRIVER_SELF_S

Re: [patch] More precise message with -Winline

Eric Botcazou writes: > Hi, > > for EH cleanups, the branch probability heuristics can consider that edges > are > never taken, i.e. their profile count is set to zero. In this case, no > matter > how you tweak the inlining parameters, you cannot get function calls inlined, > but -Winline n

[Darwin, testsuite, committed] Address PR91087 - XFAIL parts of pr16855.C.

The testcase is failing to instrument part of the source because of a platform bug in the ordering of static DTORs. It seems unlikely that this is generically fixable in the toolchain (and given that it's likely to be a dynamic loader change would not be expected to be applied retrospectively to O

patch to fix PR91223

The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91223 The patch was successfully bootstrapped and tested on x86-64. Committed as rev. 273810. Index: ChangeLog === --- ChangeLog (revision 273809) +++ ChangeLo

Re: [Darwin, testsuite, committed] Address PR91087 - XFAIL parts of pr16855.C.

Hi Iain, > The testcase is failing to instrument part of the source because of a platform > bug in the ordering of static DTORs. It seems unlikely that this is > generically > fixable in the toolchain (and given that it's likely to be a dynamic loader > change would not be expected to be applied

Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization

On 7/24/19 11:08 PM, JiangNing OS wrote: -Original Message- From: Martin Sebor Sent: Thursday, July 25, 2019 2:08 AM To: Jeff Law ; JiangNing OS ; gcc-patches@gcc.gnu.org Subject: Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization On 7/24/19 11:12

Re: [patch] More precise message with -Winline

> That seems misleading, unless the exception is really never thrown. See my earlier answer to Richard. -- Eric Botcazou

Re: [Darwin, testsuite, committed] Address PR91087 - XFAIL parts of pr16855.C.

Hi Rainer, > On 25 Jul 2019, at 19:40, Rainer Orth wrote: > >> The testcase is failing to instrument part of the source because of a >> platform >> bug in the ordering of static DTORs. It seems unlikely that this is >> generically >> fixable in the toolchain (and given that it's likely to be

Re: [PATCH] handle multibyte stores larger than char in strlen (PR 91183, 86888)

On 7/24/19 8:39 PM, Jeff Law wrote: On 7/24/19 8:17 PM, Martin Sebor wrote: Committed in r273783 after retesting and including a test for the warning that I had left out of the patch I posted here. Martin PS I suspect some of the tests I added might need tweaking on big-endian systems.  I'll d

[PATCH], PowerPC #11, Add DS offset mode to rs6000.c's reg_addr

This patch adds a new address mask field to the reg_addr structure in rs6000.c. The new address mask says that a particular register type (gpr, fpr, altivec) needs to use DS style offset addressing for a given mode (i.e. the bottom 2 bits must be 0). In working on this, I discovered that the instr

[PATCH], PowerPC #12, Add instruction format enumeration

This is patch #12 which adds a new enumeration for instruction format. As we discussed in patch #9, offset_format wasn't the best name. This patch adds the INSN_FORM enumeration that lists the 3 traditional offset instruction formats (D/DS/DQ), indexed only instruction formats, and prefixed instr

Re: Subject: [PATCH] [PR 89330] Remove non-useful speculations from new_edges

> Hi, > > the following patch prevents the call speculation machinery from > deallocating call graph edges from under the indirect inlining machinery > and it also fixes a potential issue in speculation which could in some > cases undo an earlier inlining decision, something that the inliner is >

[PATCH], PowerPC #13, Add support for matching prefixed insns

This is patch #13 which adds new support for matching insn addresses, particularly prefixed insns. In particular the main feature of this patch is a function called 'addr_validate_p' that given an address, a mask of address types you want to match, and an instruction format enumeration, it will re

[PATCH], PowerPC #14, Add pc-relative support to load up addresses

This is patch #14, and it adds support to load up addresses with pc-relative addressing. Note, a later patch will add support for actually using the pc-relative support directly. In theory with patches 11-14 applied, you could use -mpcrel. However, for now, -mpcrel will not be enabled by default

[PATCH], PowerPC #15, Rename some prefixed addressing functions

This is patch #15, and it shortens some of the previous names that I had created. The motavation by making the names smaller is make the ChangeLog files either to write with the 79 character limit. I have done a bootstrap on a little endian power8 system, and there were no regressions in the test

[PATCH], PowerPC #16, Update a comment and move a predicate

This is patch #16 that fixes some things when I noticed when I was creating patch #15. I separated it out just to simplify things. It updates a comment in talking about pc-relative external addresses that was wrong. In also moves a predicate so that all of the pcrel_* predicates could be togethe

[PATCH], PowerPC #17, adds the prefixed RTL attribute & automatically emit a leading 'p'

This is patch #17 that adds support for automatically detecting prefixed instructions and changing the length to 12 bytes, and emitting a 'p' before the instruction. At the moment, only loading up pc-relative addresses will have the prefixed RTL set, since I have enabled the prefixed instruction s

[PATCH], PowerPC #18, Add prefixed support for scalars

This is patch #18, it finaly adds prefixed instruction support for the scalar types. There are some things I need to check out for for vector types and 128-bit floating point, so those are not enabled for now. The earlier patch that changed the length of many of the load/stores to '*' means that

[PATCH], PowerPC #19, Add 'future' cost structure

This is patch #19. It is a fairly simple patch to clone the power9 costs and use that for costs on the 'future' machine. As I write this message, I am waiting for the full bootstrap and make of the patch on a little endian power8 system. Assuming there are no regressions, can I check this into t

[PATCH], PowerPC #20, Add placeholder for 'future' scheduling

This is patch #20. It adds a placeholder for scheduling on the 'future' machine. This code currently uses the power9.md with all of the names changed for 'future', and targetting off of 'tune=future'. This placeholder hopefully will be filled in later when we can add more accurate scheduling inf

[PATCH 1/2] Implement p1301 - [[nodiscard("should have a reason")]]

From: ThePhD --- gcc/c-family/c-lex.c | 38 ++-- gcc/cp/cvt.c | 204 +++--- gcc/cp/parser.c | 23 +- gcc/cp/tree.c | 56 +++-- gcc/escaped_string.h

Re: cp: implementation of p1301 for C++

The HTML formatting was off (again), so I used git send-email as someone recommended to me in the IRC. Patch is here: https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01670.html I... think it's good, there? Apologies for all the noise; it's a bit hard getting used to these tools. Sincerely, JeanHeyd

Re: [PATCH] handle multibyte stores larger than char in strlen (PR 91183, 86888)

On 7/25/19 1:42 PM, Martin Sebor wrote: > On 7/24/19 8:39 PM, Jeff Law wrote: >> On 7/24/19 8:17 PM, Martin Sebor wrote: Committed in r273783 after retesting and including a test for the warning that I had left out of the patch I posted here. Martin PS I suspect some o

[PATCH V3, rs6000] Support vrotr3 for int vector types

Hi Segher, on 2019/7/25 下午9:49, Segher Boessenkool wrote: > Hi Kewen, > > On Tue, Jul 23, 2019 at 02:28:28PM +0800, Kewen.Lin wrote: >> --- a/gcc/config/rs6000/altivec.md >> +++ b/gcc/config/rs6000/altivec.md >> @@ -1666,6 +1666,60 @@ >>"vrl %0,%1,%2" >>[(set_attr "type" "vecsimple")]) >>

[PATCH V4, rs6000] Support vrotr3 for int vector types

Hi Segher, You can just ignore the previous version and review the current with one comment change and "=" line move. Sorry for the inconvenience. Thanks, Kewen diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md index b6a22d9010c..217c7afdf17 100644 --- a/gcc/config/rs6000

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

On 7/24/19 12:33 PM, Richard Biener wrote: > On July 24, 2019 8:18:57 PM GMT+02:00, Jeff Law > wrote: >> On 7/24/19 11:00 AM, Richard Biener wrote: [ Big snip, ignore >> missing reply attributions... ] >> it. But I'd claim that if callers are required not to change these ranges, then th

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

On 7/24/19 12:33 PM, Richard Biener wrote: > On July 24, 2019 8:18:57 PM GMT+02:00, Jeff Law > wrote: >> On 7/24/19 11:00 AM, Richard Biener wrote: [ Big snip, ignore >> missing reply attributions... ] >> it. But I'd claim that if callers are required not to change these ranges, then th

Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization

On 7/24/19 12:07 PM, Martin Sebor wrote: > > I don't know what Jakub had in mind but the mapping I envision is > one like hash_map that would make it possible to set > a bit for each distinct warning for every tree node.  It would let > us set a bit for -Wuninitialized while leaving the bit for >

Deque iterators lexicographical_compare overloads

And here are the lexicographical_compare overloads. I am submitting this seperately from the others cause some might argue that it is a lot of code for a scope limited to the moment to unsigned byte types. I had to overload __lexicographical_compare_aux here cause the std::lexicographical_co

[PATCH] Fix bad comment copy/paste

Committed as trivial.     * testsuite/util/testsuite_iterators.h     (bidirectional_iterator_wrapper): Fix type comment.     (random_access_iterator_wrapper): Likewise. François diff --git a/libstdc++-v3/testsuite/util/testsuite_iterators.h b/libstdc++-v3/testsuite/util/testsuite_iterators.h in

Re: [PATCH, rs6000] Fix PR91050 by adding a DRIVER_SELF_SPECS spec

Hi Peter, > On 25 Jul 2019, at 04:30, Peter Bergner wrote: > > The -mdejagnu-cpu= option was added as a way for a test case to ensure a > particular -mcpu= option is used to compile the test, regardless of whether > the user attempts to override it (purposely or accidentally) via RUNTESTFLAGS. >

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

On 7/25/19 2:53 AM, Marc Glisse wrote: > I would also mark DECL_IS_OPERATOR_DELETE_P the other operators delete, > because of the name of the macro, but it is not important for this patch. I'm planning to install the patch as is right after I'll get an approval of the 1/2 part. Feel free to pre

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

On Wed, Jul 24, 2019 at 9:50 PM Andrew MacLeod wrote: > > On 7/24/19 2:18 PM, Jeff Law wrote: > > On 7/24/19 11:00 AM, Richard Biener wrote: > [ Big snip, ignore missing reply attributions... ] > > it. But I'd claim that if callers are required not to change these > ranges, then the callers are fu

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

Hello, On Tue, Jul 23 2019, Richard Biener wrote: > The following fixes the runtime regression of 456.hmmer caused > by matching ICC in code generation and using cmov more aggressively > (through GIMPLE level MAX_EXPR usage). Appearantly (discovered > by manual assembler editing) using the SSE un

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

On Wed, Jul 24, 2019 at 9:02 PM Jeff Law wrote: > > On 7/11/19 12:45 AM, Martin Liška wrote: > > On 7/9/19 11:00 PM, Jason Merrill wrote: > > > Ok, I hopefully addressed the suggested improvements to the patch. > > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > > >

[PATCH] value-range lattice const correctness

The following makes vr_values::get_value_range return a const value_range * since the ranges are not to be modified in place but modifications have to go through the lattice update functions. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2019-07-25 Richard Biener