PC-relative TLS support

Supporting TLS for -mpcrel turns out to be relatively simple, in part due to deciding that !TARGET_TLS_MARKERS with -mpcrel is silly. No assembler that I know of supporting prefix insns lacks TLS marker support. Also, at some point powerpc gcc ought to remove !TARGET_TLS_MARKERS generally and

Re: Patch to support extended characters in C/C++ identifiers

On 8/12/19 6:01 PM, Lewis Hyatt wrote: Hello- The attached patch for libcpp adds support for extended characters (e.g. UTF-8) in identifiers. A preliminary version of the patch was posted on PR c/67224 as Comment 26 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224#c26) and discussed with

Re: PowerPC 'future' patches introduction

Hi Mike, On Wed, Aug 14, 2019 at 04:57:32PM -0400, Michael Meissner wrote: > to the current location instead of a base register, giving pc-relative > addressing. Pc-relative addressing will be supported in the next ABI (3.1) as > an alternative to the current TOC based addressing. That's not an

Re: [PATCH] i386: Expand roundeven for SSE4.1+

On Sun, 14 Jul 2019, Uros Bizjak wrote: > > This patch is for expanding roundeven inline for SSE4.1 and later. > > Note that this patch is to be applied on top of > > . The patch > > is bootstrapped and regression tested on

[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 #9 of 10, Add tests with large memory offsets

This patch adds tests for all of the types using large address offsets that would not fit into 16 bits, and verifies that prefixed instructions are generated. The tests in this patch all succeed when patches 1-7 are applied on a little endian power8 system. Can I check these patches into the

[PATCH], Patch #8 of 10, Miscellaneous future tests

This patch adds miscellaneous tests for the new prefixed addressing. With patches 1-7 applied, these patches all succeed. Can I check these patches into the trunk? 2019-08-14 Michael Meissner * gcc/testsuite/gcc.target/powerpc/prefix-odd-memory.c: New test. *

[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 #6 of 10, Add 'future' support to function attributes

This patch adds support for using cpu=future in the "target" function attribute, "target" pragma support, and "target_clones" function attributes. In addition, it adds support for the following arguments to __builtin_cpu_supports: "arch_3_1" Whether ISA 3.1 is supported by the

Re: [PATCH 0/8] eBPF support for GCC

> The second patch adds the new GCC port proper. Machine description, > implementation of target hooks and macros, command-line options and > the like. Looks like [PATCH 2/8] didn't make it to the mailing list for some reason (maybe it exceeded a size limit?) Yeah the

[PATCH 2/8] bpf: new GCC port

This patch adds a port for the Linux kernel eBPF architecture to GCC. ChangeLog: * configure.ac: Support for bpf-*-* targets. * configure: Regenerate. contrib/ChangeLog: * config-list.mk (LIST): Disable go in bpf-*-* targets. gcc/ChangeLog: * config.gcc: Support for bpf-*-*

Re: [PATCHv4] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

On 8/14/19 2:00 PM, Richard Biener wrote: > On Thu, 8 Aug 2019, Bernd Edlinger wrote: > >> On 8/2/19 9:01 PM, Bernd Edlinger wrote: >>> On 8/2/19 3:11 PM, Richard Biener wrote: On Tue, 30 Jul 2019, Bernd Edlinger wrote: > > I have no test coverage for the movmisalign optab

[PATCH], Patch #5 of 10, Make -mpcrel default for -mcpu=future

This patch changes the default for -mcpu=future to turn on pc-relative addressing by default. I have built each of the patches in turn on a little endian power8 system doing a bootstrap and make check. There were no regressions. Can I check this patch into the trunk once the previous patches

Re: [PATCH 0/8] eBPF support for GCC

On Wed, 2019-08-14 at 23:36 +0200, Jose E. Marchesi wrote: > Hi people! > [...] > The second patch adds the new GCC port proper. Machine description, > implementation of target hooks and macros, command-line options and > the like. Looks like [PATCH 2/8] didn't make it to the mailing list for

[PATCH], Patch #4 of 10, Adjust costs based on insn sizes

Some of the cost functions in the PowerPC compiler uses the length of the instruction to factor in the costs. This patches adjusts this calculation so that prefixed instructions are treated as the same cost as non-prefixed instructions. I forgot to mention in the previous patchs, all 10 of the

[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).

[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 emitted. For example, a

[PATCH 6/8] bpf: adjust GCC testsuite to eBPF limitations

This patch makes many tests in gcc.dg and gcc.c-torture to be skipped in bpf-*-* targets. This is due to the many limitations imposed by eBPF to what would be perfectly valid C code: no support for indirect calls, no support for more than 5 arguments to function calls, no support for indirect

[PATCH 7/8] bpf: manual updates for eBPF

gcc/ChangeLog: * doc/invoke.texi (Option Summary): Cover eBPF. (eBPF Options): New section. * doc/extend.texi (BPF Built-in Functions): Likewise. (BPF Kernel Helpers): Likewise. --- gcc/ChangeLog | 7 +++ gcc/doc/extend.texi | 171

[PATCH 4/8] bpf: gcc.target eBPF testsuite

This patch adds a new testsuite to gcc.target, with eBPF specific tests. Tests are included for: - Target specific diagnostics. - All built-in functions. testsuite/ChangeLog: * gcc.target/bpf/bpf.exp: New file. * gcc.target/bpf/builtin-load.c: Likewise. *

[PATCH 8/8] bpf: add myself as the maintainer for the eBPF port

ChangeLog: * MAINTAINERS: Add myself as the maintainer for the eBPF port. --- ChangeLog | 4 MAINTAINERS | 1 + 2 files changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 912663c4497..cbd6f904944 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -57,6 +57,7 @@ arm

[PATCH 5/8] bpf: make target-supports.exp aware of eBPF

This patch makes the several effective target checks in target-supports.exp to be aware of eBPF targets. gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_effective_target_malloc): New function. (check_effective_target_trampolines): Adapt to eBPF.

[PATCH 0/8] eBPF support for GCC

Hi people! This patch series introduces a port of GCC to eBPF, which is a virtual machine that resides in the Linux kernel. Initially intended for user-level packet capture and filtering, eBPF is nowadays generalized to serve as a general-purpose infrastructure also for non-networking purposes.

[PATCH 1/8] Update config.sub and config.guess.

* config.sub: Import upstream version 2019-06-30. * config.guess: Import upstream version 2019-07-24. --- ChangeLog| 5 ++ config.guess | 264 +++ config.sub | 50 +-- 3 files changed, 240 insertions(+), 79

[PATCH 3/8] bpf: new libgcc port

This patch adds an eBPF port to libgcc. As of today, compiled eBPF programs do not support a single-entry point schema. Instead, a BPF "executable" is a relocatable ELF object file containing multiple entry points, in certain named sections. Also, the BPF loaders in the kernel do not execute

[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

C++ PATCH to implement C++20 P1143R2, constinit (PR c++/91360)

This patch implements the C++20 specifier constinit, as described in . It makes sure that the compiler requires constant initialization of a variable (it can only be applied to variables with static or thread storage duration). Note the variable is *not* const; it is

PowerPC 'future' patches introduction

I will be submitting 10 patches will that will add support to GCC for a possible future PowerPC processor. These patches add support for new instructions that extend the offsettable memory instructions (D, DS, or DQ instruction formats) to have 34 bit offsets (instead of 16, 14, or 12 bits

Re: [SVE] PR86753

Richard Biener writes: > On Wed, Aug 14, 2019 at 6:49 PM Richard Biener > wrote: >> >> On Wed, Aug 14, 2019 at 5:06 PM Prathamesh Kulkarni >> wrote: >> > >> > Hi, >> > The attached patch tries to fix PR86753. >> > >> > For following test: >> > void >> > f1 (int *restrict x, int *restrict y, int

Re: [PATCH] fold more string comparison with known result (PR 90879)

On 8/13/19 4:46 PM, Jeff Law wrote: On 8/13/19 3:43 PM, Martin Sebor wrote: On 8/13/19 2:07 PM, Jeff Law wrote: On 8/9/19 10:51 AM, Martin Sebor wrote: PR tree-optimization/90879 - fold zero-equality of strcmp between a longer string and a smaller array gcc/c-family/ChangeLog: PR

[PATCH] Deprecate std::__is_nullptr_t type trait

This non-standard extension is redundant and unused by the library. * include/std/type_traits (__is_nullptr_t): Add deprecated attribute. We support std::is_null_pointer so don't need a non-standard trait that does the same thing. Tested x86_64-linux, committed to trunk. commit

Re: [PATCH] Properly register dead cgraph_nodes in passes.c.

On 8/9/19 6:41 AM, Martin Liška wrote: > Hi. > > The patch prevents crashes caused by fact that do_per_function_toporder > uses get_uid () to register all dead cgraph_nodes. That does not work > now as cgraph_nodes are directly released via ggc_free and so that one > will see a garbage here.

[PATCH, i386]: Use *mmx_pinsrb some more

We can generate {v,}pinsrb in ix86_expand_vector_init_one_nonzero and ix86_expand_vector_init_one_var. {v,}pinsrd is already generated where optimal. 2019-08-14 Uroš Bizjak * config/i386/i386-expand.c (ix86_expand_vector_init_one_nonzero) : Use vector_set path for

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

On Thu, Aug 8, 2019 at 3:25 PM Marek Polacek wrote: > > On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote: > > On 8/6/19 3:20 PM, Marek Polacek wrote: > > > On Mon, Aug 05, 2019 at 03:54:19PM -0400, Jason Merrill wrote: > > > > On 7/31/19 3:26 PM, Marek Polacek wrote: > > > > > One of

Re: [PATCH 0/3] add support for POD struct convention (PR 61339)

On 7/12/19 9:24 AM, Jakub Jelinek wrote: > I'd just arrange that when being compiled with clang we compile with > -Wno-mismatched-tags to get rid of their misdesigned warning and not add > such misdesigned warning to GCC, that will just help people spread this > weirdo requirement further. FWIW

Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

On Mon, Aug 5, 2019 at 2:22 PM Jason Merrill wrote: > On 8/5/19 11:34 AM, Jakub Jelinek wrote: > > On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote: > >> I agree. But for those who want a monotonically increasing > >> identifier, there's already one in git: CommitDate. In the

Re: Add TIGERLAKE and COOPERLAKE to GCC

On 8/14/19 1:38 AM, Cui, Lili wrote: > Resend this mail for GCC Patches rejected my message, thanks. > > -Original Message- > > Hi Uros and all: > > This patch is about to add TIGERLAKE and COOPERLAKE to GCC. > TIGERLAKE is based on ICELAKE_CLIENT and plus new ISA >

Re: Add IFN_COND functions for shifting

On 8/14/19 6:27 AM, Richard Sandiford wrote: > This patch adds support for IFN_COND shifts left and shifts right. > This is mostly mechanical, but since we try to handle conditional > operations in the same way as unconditional operations in match.pd, > we need to support IFN_COND shifts by

Re: [PATCH] Add generic support for "noinit" attribute

On Wed, 14 Aug 2019 at 19:07, Christophe Lyon wrote: > > On Wed, 14 Aug 2019 at 17:59, Tamar Christina wrote: > > > > Hi Christoph, > > > > The noinit testcase is currently failing on x86_64. > > > > Is the test supposed to be running there? > > > No, there's an effective-target to skip it. >

Re: enforce canonicalization of value_range's

On 8/13/19 6:51 PM, Aldy Hernandez wrote: >> Presumably this was better than moving the implementation earlier. > > Actually, it was for ease of review.  I made some changes to the > function, and I didn't want the reviewer to miss them because I had > moved the function wholesale.  I can move

Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

On Wed, 2019-08-14 at 16:53 +0100, Jonathan Wakely wrote: > On 14/08/19 10:39 -0400, David Malcolm wrote: > > On Wed, 2019-08-14 at 12:02 +0100, Jonathan Wakely wrote: > > > On 13/08/19 16:07 -0400, Jason Merrill wrote: > > > > On 8/13/19 9:32 AM, Jonathan Wakely wrote: > > > > > *

[COMMITTED] Set memory alignment in expand_builtin_init_descriptor

Committed as r274487 with approval in https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00974.html Index: gcc/builtins.c === --- gcc/builtins.c (revision 274486) +++ gcc/builtins.c (revision 274487) @@ -5756,6 +5756,7 @@

Re: types for VR_VARYING

On 8/13/19 6:39 PM, Aldy Hernandez wrote: > > > On 8/12/19 7:46 PM, Jeff Law wrote: >> On 8/12/19 12:43 PM, Aldy Hernandez wrote: >>> This is a fresh re-post of: >>> >>> https://gcc.gnu.org/ml/gcc-patches/2019-07/msg6.html >>> >>> Andrew gave me some feedback a week ago, and I obviously 

[PATCH] Simplify and generalize rust-demangle's unescaping logic.

Previously, rust-demangle.c was special-casing a fixed number of '$uXY$' escapes, but 'XY' can technically be any hex value, representing some Unicode codepoint. This patch adds more general support for '$u...$' escapes, similar to https://github.com/alexcrichton/rustc-demangle/pull/29, but only

Re: Rewrite some jump.c routines to use flags

On Fri, 12 Jul 2019, Richard Sandiford wrote: > At least AIUI, __builtin_isunordered etc. don't raise an exception even > for signalling NaNs. __builtin_isunordered should raise "invalid" for signaling NaNs. (isunordered is the IEEE 754 operation compareQuietUnordered, and IEEE 754 specifies

Re: [PATCH] Automatics in equivalence statements

On 8/14/19 2:45 AM, Mark Eggleston wrote: > I now have commit access. > > gcc/fortran > >     Jeff Law >     Mark Eggleston > >     * gfortran.h: Add gfc_check_conflict declaration. >     * symbol.c (check_conflict): Rename cfg_check_conflict and remove >     static. >     * symbol.c

Re: [PATCH] Add generic support for "noinit" attribute

On Wed, 14 Aug 2019 at 17:59, Tamar Christina wrote: > > Hi Christoph, > > The noinit testcase is currently failing on x86_64. > > Is the test supposed to be running there? > No, there's an effective-target to skip it. But I notice a typo: +/* { dg-require-effective-target noinit */ (missing

Re: [PATCH 2/2] Clean next_nested properly.

On 8/14/19 5:17 AM, Martin Liska wrote: > > gcc/ChangeLog: > > 2019-08-14 Martin Liska > > PR ipa/91438 > * cgraph.c (cgraph_node::remove): When setting > n->origin = NULL for all nested functions, reset > also next_nested. > --- > gcc/cgraph.c | 11 +++ > 1

Re: [PATCH 1/2] Add ::verify for cgraph_node::origin/nested/next_nested.

On 8/14/19 5:15 AM, Martin Liska wrote: > > gcc/ChangeLog: > > 2019-08-14 Martin Liska > > * cgraph.c (cgraph_node::verify_node): Verify origin, nested > and next_nested. > --- > gcc/cgraph.c | 24 > 1 file changed, 24 insertions(+) > OK. Jeff

Re: [PATCH] Make GIMPLE forwprop DCE dead stmts

On 8/14/19 7:36 AM, Richard Biener wrote: > > The following patch makes forwprop DCE the stmts that become dead > because of propagation of copies and constants. For this to work > we actually have to do that reliably rather than relying on > fold_stmt doing this for us. > > This hits

Re: types for VR_VARYING

On 8/14/19 8:15 AM, Aldy Hernandez wrote: > > > On 8/14/19 9:50 AM, Andrew MacLeod wrote: >> On 8/13/19 8:39 PM, Aldy Hernandez wrote: >>> >>> >>> Yes, it was 2X. >>> >>> I noticed that Richi made some changes to the lattice handling for >>> VARYING while the discussion was on-going.  I missed

Re: [SVE] PR86753

On Wed, Aug 14, 2019 at 6:49 PM Richard Biener wrote: > > On Wed, Aug 14, 2019 at 5:06 PM Prathamesh Kulkarni > wrote: > > > > Hi, > > The attached patch tries to fix PR86753. > > > > For following test: > > void > > f1 (int *restrict x, int *restrict y, int *restrict z) > > { > > for (int i =

Re: [SVE] PR86753

On Wed, Aug 14, 2019 at 5:06 PM Prathamesh Kulkarni wrote: > > Hi, > The attached patch tries to fix PR86753. > > For following test: > void > f1 (int *restrict x, int *restrict y, int *restrict z) > { > for (int i = 0; i < 100; ++i) > x[i] = y[i] ? z[i] : 10; > } > > vect dump shows: >

Re: [PATCH] fix and improve strlen conditional handling of merged stores (PR 91183, 91294, 91315)

Do you want me to post another revision with the gimple_assign_single_p test removed? I think remove that hunk, bootstrap, test, commit and post for archival purposes.  I do not think another round of review is necessary. Done in r274486 (also attached). I should add that the early store

Re: [PATCH] fix and improve strlen conditional handling of merged stores (PR 91183, 91294, 91315)

On 8/12/19 1:57 PM, Jeff Law wrote: On 8/9/19 5:42 PM, Martin Sebor wrote: @@ -3408,7 +3457,13 @@ static bool   }       gimple *stmt = SSA_NAME_DEF_STMT (exp); -  if (gimple_code (stmt) != GIMPLE_PHI) +  if (gimple_assign_single_p (stmt)) +    { +  tree rhs =

Re: [PATCH 0/3] Libsanitizer: merge from trunk

On 8/14/19 2:50 AM, Martin Liška wrote: > On 8/13/19 5:02 PM, Jeff Law wrote: >> On 8/13/19 7:07 AM, Martin Liska wrote: >>> Hi. >>> >>> For this year, I decided to make a first merge now and the >>> next (much smaller) at the end of October. >>> >>> The biggest change is rename of many files from

Re: [PATCH] fold more string comparison with known result (PR 90879)

On 8/12/19 7:40 AM, Michael Matz wrote: Hi, On Fri, 9 Aug 2019, Martin Sebor wrote: The solution introduced in C99 is a flexible array. C++ compilers usually support it as well. Those that don't are likely to support the zero-length array (even Visual C++ does). If there's a chance that

Re: [PATCH 2/3] C++20 constexpr lib part 2/3 - swappish functions.

On 14/08/19 11:06 -0400, Ed Smith-Rowland wrote: I this OK after it passes testing? Ed 2019-08-14 Edward Smith-Rowland <3dw...@verizon.net> Implement C++20 p0879 - Constexpr for swap and swap related functions. * include/bits/algorithmfwd.h

RE: [PATCH] Add generic support for "noinit" attribute

Hi Christoph, The noinit testcase is currently failing on x86_64. Is the test supposed to be running there? Thanks, Tamar -Original Message- From: gcc-patches-ow...@gcc.gnu.org On Behalf Of Christophe Lyon Sent: Wednesday, August 14, 2019 2:18 PM To: Christophe Lyon ; Martin Sebor ;

Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

On 14/08/19 10:39 -0400, David Malcolm wrote: On Wed, 2019-08-14 at 12:02 +0100, Jonathan Wakely wrote: On 13/08/19 16:07 -0400, Jason Merrill wrote: > On 8/13/19 9:32 AM, Jonathan Wakely wrote: > > * g++.dg/lookup/missing-std-include-6.C: Don't check > > make_unique in > > test that

Re: [PATCH 2/3] C++20 constexpr lib part 2/3 - swappish functions.

On 8/13/19 7:14 AM, Jonathan Wakely wrote: On 01/08/19 13:16 -0400, Ed Smith-Rowland via libstdc++ wrote: Greetings, Here is a patch for C++20 p0879 - Constexpr for swap and swap related functions. This essentially constexprifies the rest of . Built and tested with C++20 (and pre-c++20) on

[SVE] PR86753

Hi, The attached patch tries to fix PR86753. For following test: void f1 (int *restrict x, int *restrict y, int *restrict z) { for (int i = 0; i < 100; ++i) x[i] = y[i] ? z[i] : 10; } vect dump shows: vect_cst__42 = { 0, ... }; vect_cst__48 = { 0, ... }; vect__4.7_41 = .MASK_LOAD

Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

On 8/14/19 10:39 AM, David Malcolm wrote: On Wed, 2019-08-14 at 12:02 +0100, Jonathan Wakely wrote: On 13/08/19 16:07 -0400, Jason Merrill wrote: On 8/13/19 9:32 AM, Jonathan Wakely wrote: * g++.dg/lookup/missing-std-include-6.C: Don't check make_unique in test that runs for C++11.

Re: C++ PATCH for c++/91391 - bogus -Wcomma-subscript warning

On 8/14/19 9:15 AM, Marek Polacek wrote: Ping. On Wed, Aug 07, 2019 at 04:05:53PM -0400, Marek Polacek wrote: When implementing -Wcomma-subscript I failed to realize that a comma in a template-argument-list shouldn't be warned about. But we can't simply ignore any commas inside < ... >

Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

On Wed, 2019-08-14 at 12:02 +0100, Jonathan Wakely wrote: > On 13/08/19 16:07 -0400, Jason Merrill wrote: > > On 8/13/19 9:32 AM, Jonathan Wakely wrote: > > > * g++.dg/lookup/missing-std-include-6.C: Don't check > > > make_unique in > > > test that runs for C++11. > > > > I'm not

Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

On Wed, Aug 14, 2019 at 7:02 AM Jonathan Wakely wrote: > > On 13/08/19 16:07 -0400, Jason Merrill wrote: > >On 8/13/19 9:32 AM, Jonathan Wakely wrote: > >> * g++.dg/lookup/missing-std-include-6.C: Don't check make_unique in > >> test that runs for C++11. > > > >I'm not comfortable

Re: types for VR_VARYING

On 8/14/19 9:50 AM, Andrew MacLeod wrote: On 8/13/19 8:39 PM, Aldy Hernandez wrote: Yes, it was 2X. I noticed that Richi made some changes to the lattice handling for VARYING while the discussion was on-going.  I missed these, and had failed to adapt the patch for it.  I would

Re: [PATCH 5/9] Come up with an abstraction.

On Wed, Aug 14, 2019 at 3:19 PM Martin Liška wrote: > > On 8/14/19 3:04 PM, Richard Biener wrote: > > On Mon, Aug 12, 2019 at 3:56 PM Martin Liška wrote: > >> > >> On 8/12/19 2:43 PM, Richard Biener wrote: > >>> On Mon, Aug 12, 2019 at 1:49 PM Martin Liška wrote: > > On 8/12/19 1:40

Re: types for VR_VARYING

On 8/13/19 8:39 PM, Aldy Hernandez wrote: Yes, it was 2X. I noticed that Richi made some changes to the lattice handling for VARYING while the discussion was on-going.  I missed these, and had failed to adapt the patch for it.  I would appreciate a final review of the attached patch,

[PATCH] Make GIMPLE forwprop DCE dead stmts

The following patch makes forwprop DCE the stmts that become dead because of propagation of copies and constants. For this to work we actually have to do that reliably rather than relying on fold_stmt doing this for us. This hits fortran/trans-intrinsic.c in a way that we do "interesting" jump

Re: [PATCH 5/9] Come up with an abstraction.

On 8/14/19 3:04 PM, Richard Biener wrote: > On Mon, Aug 12, 2019 at 3:56 PM Martin Liška wrote: >> >> On 8/12/19 2:43 PM, Richard Biener wrote: >>> On Mon, Aug 12, 2019 at 1:49 PM Martin Liška wrote: On 8/12/19 1:40 PM, Richard Biener wrote: > On Mon, Aug 12, 2019 at 1:19 PM Martin

Re: [PATCH] Add generic support for "noinit" attribute

On Wed, 14 Aug 2019 at 14:14, Richard Sandiford wrote: > > Sorry for the slow response, I'd missed that there was an updated patch... > > Christophe Lyon writes: > > 2019-07-04 Christophe Lyon > > > > * lib/target-supports.exp (check_effective_target_noinit): New > > proc. > >

Re: C++ PATCH for c++/91391 - bogus -Wcomma-subscript warning

Ping. On Wed, Aug 07, 2019 at 04:05:53PM -0400, Marek Polacek wrote: > When implementing -Wcomma-subscript I failed to realize that a comma in > a template-argument-list shouldn't be warned about. > > But we can't simply ignore any commas inside < ... > because the following > needs to be

Re: [PATCH 5/9] Come up with an abstraction.

On Mon, Aug 12, 2019 at 3:56 PM Martin Liška wrote: > > On 8/12/19 2:43 PM, Richard Biener wrote: > > On Mon, Aug 12, 2019 at 1:49 PM Martin Liška wrote: > >> > >> On 8/12/19 1:40 PM, Richard Biener wrote: > >>> On Mon, Aug 12, 2019 at 1:19 PM Martin Liška wrote: > > On 8/8/19 5:55

Add IFN_COND functions for shifting

This patch adds support for IFN_COND shifts left and shifts right. This is mostly mechanical, but since we try to handle conditional operations in the same way as unconditional operations in match.pd, we need to support IFN_COND shifts by scalars as well as vectors. E.g.: IFN_COND_SHL (cond,

Re: [PATCH] Add generic support for "noinit" attribute

Sorry for the slow response, I'd missed that there was an updated patch... Christophe Lyon writes: > 2019-07-04 Christophe Lyon > > * lib/target-supports.exp (check_effective_target_noinit): New > proc. > * gcc.c-torture/execute/noinit-attribute.c: New test.

Re: [PATCHv4] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

On Thu, 8 Aug 2019, Bernd Edlinger wrote: > On 8/2/19 9:01 PM, Bernd Edlinger wrote: > > On 8/2/19 3:11 PM, Richard Biener wrote: > >> On Tue, 30 Jul 2019, Bernd Edlinger wrote: > >> > >>> > >>> I have no test coverage for the movmisalign optab though, so I > >>> rely on your code review for that

[PATCH 2/2] Clean next_nested properly.

gcc/ChangeLog: 2019-08-14 Martin Liska PR ipa/91438 * cgraph.c (cgraph_node::remove): When setting n->origin = NULL for all nested functions, reset also next_nested. --- gcc/cgraph.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff

[PATCH 1/2] Add ::verify for cgraph_node::origin/nested/next_nested.

gcc/ChangeLog: 2019-08-14 Martin Liska * cgraph.c (cgraph_node::verify_node): Verify origin, nested and next_nested. --- gcc/cgraph.c | 24 1 file changed, 24 insertions(+) diff --git a/gcc/cgraph.c b/gcc/cgraph.c index ed46d81a513..eb38b905879

[PATCH 0/2] Fix dangling pointer in next_nested.

Hi. First patch is about addition of a nested/origin/next_nested verification. The verification can find the issue in Ada run-time library on x86_64 without bootstrap. The second patch is fix where we need to clean up the field. Patch can bootstrap on x86_64-linux-gnu and survives regression

Re: [PATCH] PR libstdc++/90361 add missing macro definition

On 12/08/19 17:41 +0100, Jonathan Wakely wrote: The src/c++17/string-inst.cc file needs to override the default string ABI so that it still contains the expected symbols even when the library is configured with --with-default-libstdcxx-abi=gcc4-compatible. PR libstdc++/90361 *

Re: [PATCHv3] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

On Fri, 2 Aug 2019, Bernd Edlinger wrote: > On 8/2/19 3:11 PM, Richard Biener wrote: > > On Tue, 30 Jul 2019, Bernd Edlinger wrote: > > > >> > >> I have no test coverage for the movmisalign optab though, so I > >> rely on your code review for that part. > > > > It looks OK. I tried to make it

[committed][AArch64] Use SVE BIC for conditional arithmetic

This patch uses BIC to pattern-match conditional AND with an inverted third input. It also adds extra tests for AND, ORR and EOR. Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf. Applied as r274480. Richard 2019-08-14 Richard Sandiford Kugan

Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

On 13/08/19 16:07 -0400, Jason Merrill wrote: On 8/13/19 9:32 AM, Jonathan Wakely wrote: * g++.dg/lookup/missing-std-include-6.C: Don't check make_unique in test that runs for C++11. I'm not comfortable removing this test coverage entirely. Doesn't it give a useful diagnostic in

[committed][AArch64] Use SVE UXT[BHW] as a form of predicated AND

UXTB, UXTH and UXTW are equivalent to predicated ANDs with the constants 0xff, 0x and 0x respectively. This patch uses them in the patterns for IFN_COND_AND. Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf. Applied as r274479. Richard 2019-08-14 Richard

[committed][AArch64] Add SVE conditional conversion patterns

This patch adds patterns to match conditional conversions between integers and like-sized floats. The patterns are actually more general than that, but the other combinations can only be tested via the ACLE. Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf. Applied as

[committed][AArch64] Add SVE conditional floating-point unary patterns

This patch adds patterns to match conditional unary operations on floating-point modes. At the moment we rely on combine to merge separate arithmetic and vcond_mask operations, and since the latter doesn't accept zero operands, we miss out on the opportunity to use the movprfx /z alternative.

[committed][AArch64] Add SVE conditional integer unary patterns

This patch adds patterns to match conditional unary operations on integers. At the moment we rely on combine to merge separate arithmetic and vcond_mask operations, and since the latter doesn't accept zero operands, we miss out on the opportunity to use the movprfx /z alternative. (This

[PING] [PATCHv4] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

Hi! I'd like to ping for this patch: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00546.html Thanks Bernd.

Re: [PATCH 2/2] Add more entries to the C++ get_std_name_hint array

On 13/08/19 16:08 -0400, Jason Merrill wrote: On 8/13/19 9:36 AM, Jonathan Wakely wrote: This adds some commonly-used C++11/14 names, and some new C++17/20 names. The latter aren't available when using the -std=gnu++14 default, so the fix-it suggesting to use a newer dialect is helpful. *

[Ada] Improve performance of Containers.Functional_Base

This patch modifies the implementation of Functional_Base to damp the cost of its subprograms at runtime in specific cases. Instead of copying the entire underlying array to create a new container, containers can share the same Array_Base attribute. Performance on common use cases of formal and

[Ada] Fix internal error on inlined subprogram instance

This fixes a long-standing oddity in the procedure analyzing the instantiation of a generic subprogram, which would set the Is_Generic_Instance flag on the enclosing package generated for the instantiation but only to reset it a few lines below. Now this flag is relied upon by the machinery which

[Ada] Compiler speedup with inlining across units

This change is aimed at speeding up the inlining across units done by the Ada compiler when -gnatn is specified and in the presence of units instantiating a lot of generic packages. The current implementation is as follows: when a generic package is being instantiated, the compiler scans its spec

[Ada] Check SPARK restriction on Old/Loop_Entry with pointers

SPARK RM rule 3.10(14) restricts the use of Old and Loop_Entry attributes on prefixes of an owning or observing type (i.e. a type with access inside). There is no impact on compilation. Tested on x86_64-pc-linux-gnu, committed on trunk 2019-08-14 Yannick Moy gcc/ada/ *

[Ada] Alignment may be specified as zero

An Alignment clause or an aspect_specification for Alignment may be specified as 0, which is treated the same as 1. Tested on x86_64-pc-linux-gnu, committed on trunk 2019-08-14 Bob Duff gcc/ada/ * sem_ch13.adb (Get_Alignment_Value): Return 1 for Alignment 0, and do not give

[Ada] Incorrect error on inline protected function

This patch fixes a bug where if a protected function has a pragma Inline, and has no local variables, and the body consists of a single extended_return_statement, and the result type is an indefinite composite subtype, and inlining is enabled, the compiler gives an error, even though the program

[Ada] Fix spurious ownership error in GNATprove

Like Is_Path_Expression, function Is_Subpath_Expression should consider the possibility that the subpath is a type conversion or type qualification over the actual subpath node. This avoids spurious ownership errors in GNATprove. There is no impact on compilation. Tested on x86_64-pc-linux-gnu,

[Ada] Warn about unknown condition in Compile_Time_Warning

The compiler now warns if the condition in a pragma Compile_Time_Warning or Compile_Time_Error does not have a compile-time-known value. The warning is not given for pragmas in a generic template, but is given for pragmas in an instance. The -gnatw_c and -gnatw_C switches turn the warning on and

[Ada] Crash on quantified expression in disabled assertion

The defining identifier of a quantified expression may be the freeze point of its type. If the quantified expression appears in an assertion that is disavbled, the freeze node for that type may appear in a tree that will be discarded when the enclosing pragma is elaborated. To ensure that the

[Ada] Strengthen Locked flag

This patch strengthens the Locked flag, by Asserting that it is False on operations that might cause reallocation. No change in behavior (except in the presence of compiler bugs), so no test. Tested on x86_64-pc-linux-gnu, committed on trunk 2019-08-14 Bob Duff gcc/ada/ *

  1   2   >