Re: [PATCH], Enable -mfloat128 by default on PowerPC VSX systems

Here is a respin of the patch to enable -mfloat128 on PowerPC Linux systems now that the libquadmath patch has been applied. I rebased the patches against the top of the trunk on Tuesday (subversion id 251609). I tweaked the documentation a bit based on your comments. I built the patch on the

Re: [PATCH] Fix ICE in categorize_decl_for_section with TLS decl (PR middle-end/82095)

On September 5, 2017 11:16:53 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >If a DECL_THREAD_LOCAL_P decl has NULL DECL_INITIAL and >-fzero-initialized-in-bss (the default), we ICE starting with >r251602, which changed bss_initializer_p: >+ /* Do not put constants into the .bss

Re: [RFA] [PATCH][PR tree-optimization/64910] Fix reassociation of binary bitwise operations with 3 operands

On 09/05/2017 11:26 AM, Jeff Law wrote: > On 09/05/2017 12:38 AM, Christophe Lyon wrote: >> Hi Jeff, >> >> >> On 3 September 2017 at 16:44, Jeff Law wrote: >>> On 01/13/2016 05:30 AM, Richard Biener wrote: On Wed, Jan 13, 2016 at 7:39 AM, Jeff Law wrote:

Re: [PATCH, gcc-7-branch] Backport PR80038

On 2017-08-24 20:17 +0800, Xi Ruoyao wrote: > On 2017-08-22 10:17 +0200, Richard Biener wrote: > > > > Ok for the gcc 7 branch. > > > > Well, I think I should say I don't have SVN write access... Still not installed. Make a rediff. We don't have a Cilk maintainer now... Someone please

Re: [Ping^2][PATCH, DWARF] Add DW_CFA_AARCH64_negate_ra_state to dwarf2.def/h and dwarfnames.c

On 09/05/2017 09:05 PM, Jiong Wang wrote: > 2017-08-22 9:18 GMT+01:00 Jiong Wang : >> On 10/08/17 17:39, Jiong Wang wrote: >>> >>> Hi, >>> >>> A new vendor CFA DW_CFA_AARCH64_negate_ra_state was introduced for >>> ARMv8.3-A >>> return address signing, it is multiplexing

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 06/08 - V3

Hi! On Sat, Sep 02, 2017 at 12:31:16AM -0600, Jeff Law wrote: > On 08/29/2017 05:14 PM, Segher Boessenkool wrote: > > Actually, everywhere it is used it has a Pmode == SImode wart before > > it, to emit the right update_stack insn... So fold that into this > > function, name it

Re: Add support to trace comparison instructions and switch statements

On Tue, Sep 05, 2017 at 09:03:52PM +0800, 吴潍浠(此彼) wrote: > Attachment is my updated path. > The implementation of parse_sanitizer_options is not elegance enough. Mixing > handling flags of fsanitize is easy to make mistakes. To avoid too many further iterations, I took the liberty to tweak your

[committed] Fix OpenMP lowering related ICE (PR middle-end/81768)

Hi! On the following testcase we ICE because during OpenMP lowering we failed to recompute ADDR_EXPR invariants after a VAR_DECL has been replaced by a target mapping. Normally this is done in lower_omp_regimplify_p, but the OMP_FOR initial/final trees don't go through that. Fixed thusly,

[committed] Fix OpenMP simd expansion ICE (PR middle-end/81768)

Hi! On the following testcase when trying to gimplify a COND_EXPR that we expect to stay a COND_EXPR in GIMPLE, the gimplifier actually produces code with branches and labels, which is of course invalid inside of a bb. The reason for that is that a former global VAR_DECL is being replaced

Re: [PING**2] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

Bernd Edlinger wrote: > No, the split condition does not begin with "&& TARGET_32BIT...". > Therefore the split is enabled in TARGET_NEON after reload_completed. > And it is invoked from adddi3_neon for all alternatives without vfp > registers: Hmm that's a huge mess. I'd argue that any

[PATCH] Fix rs6000 sysv4 -fPIC hot/cold partitioning handling (PR target/81979)

Hi! CCing Andrew, because powerpcspe needs the same thing. On powerpc with sysv4 -fPIC we emit something like .LCL0: .long .LCTOC1-.LCF0 before we start emitting the function, and in the prologue we emit .LCF0: and some code. This fails to assemble if the prologue is emitted in a

[PATCH] Fix ICE in categorize_decl_for_section with TLS decl (PR middle-end/82095)

Hi! If a DECL_THREAD_LOCAL_P decl has NULL DECL_INITIAL and -fzero-initialized-in-bss (the default), we ICE starting with r251602, which changed bss_initializer_p: + /* Do not put constants into the .bss section, they belong in a readonly + section. */ + return (!TREE_READONLY (decl) +

[C++ PATCH] class scope using decls

I found do_class_using_decl confusing because of its old-style early declarations and use of read-once local variables. Committed the attached, which I found easier to understand. nathan -- Nathan Sidwell 2017-09-05 Nathan Sidwell * name-lookup.c (do_class_using_decl):

[C++ PATCH] more conversion operator changes

This patch moves add_method's management of METHOD_VEC into a new function in name-lookup.c. That function will create a slot, if there isn't one with the requested name -- we know in that case that add_method will succeed in adding the new method. The one quirk is the IDENTIFIER_BINDING

[Ping^2][PATCH, DWARF] Add DW_CFA_AARCH64_negate_ra_state to dwarf2.def/h and dwarfnames.c

2017-08-22 9:18 GMT+01:00 Jiong Wang : > On 10/08/17 17:39, Jiong Wang wrote: >> >> Hi, >> >> A new vendor CFA DW_CFA_AARCH64_negate_ra_state was introduced for >> ARMv8.3-A >> return address signing, it is multiplexing DW_CFA_GNU_window_save in CFA >> vendor >>

[C++ PATCH] CONV_OP accessors

the conv op accessor macros are overly conservative. We never call DECL_CONV_FN_P when DECL_NAME is null, and we never call DECL_CONV_FN_TYPE when the fn isn't a conversion operator. Removed those checks from these macros. Further, we never use DECL_TEMPLATE_CONV_FN_P, execpt to set that

[C++ PATCH] two cleanups

I noticed an 'if (cond)' nested inside an 'if (exact-same-cond)'. Fixed thusly. Also, pt.c was using '"\' to deal with a long error message, and not 5 lines further just having an overly long line. Fixed by using strinc constant concatenation. I also added a %<...%> around a fragment that

Re: [PATCH v2] Python testcases to check DWARF output

On Sep 4, 2017, at 2:22 AM, Pierre-Marie de Rodat wrote: > > I would like to ping for the patch I submitted at > . Thank you in > advance! I've included the dwarf people on the cc list. Seems like they may have an

Re: [PATCH][GCC][AArch64] Dot Product SIMD patterns [Patch (5/8)]

> > > From: James Greenhalgh > Sent: Monday, September 4, 2017 12:01 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd; Richard Earnshaw; Marcus Shawcroft > Subject: Re: [PATCH][GCC][AArch64] Dot Product SIMD patterns

Re: [PING**2] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

On 5 September 2017 at 19:53, Kyrill Tkachov wrote: > > On 05/09/17 18:48, Bernd Edlinger wrote: >> >> On 09/05/17 17:02, Wilco Dijkstra wrote: >>> >>> Bernd Edlinger wrote: >>> Combine creates an invalid insn out of these two insns: >>> >>> Yes it looks like a

Re: [PATCH] scheduler bug fix for AArch64 insn fusing SCHED_GROUP usage

ping^2 On Fri, Jul 21, 2017 at 3:09 PM, Jim Wilson wrote: > Ping. > > https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00779.html > > On Thu, Jul 13, 2017 at 3:00 PM, Jim Wilson wrote: >> The AArch64 port uses SCHED_GROUP to mark instructions that get

Re: [PING**2] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

On 05/09/17 18:48, Bernd Edlinger wrote: On 09/05/17 17:02, Wilco Dijkstra wrote: Bernd Edlinger wrote: Combine creates an invalid insn out of these two insns: Yes it looks like a latent bug. We need to use arm_general_register_operand as arm_adddi3/subdi3 only allow integer registers. You

Re: [PING**2] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

On 09/05/17 17:02, Wilco Dijkstra wrote: > Bernd Edlinger wrote: > >> Combine creates an invalid insn out of these two insns: > > Yes it looks like a latent bug. We need to use arm_general_register_operand > as arm_adddi3/subdi3 only allow integer registers. You don't need a new > predicate >

Re: [PING**2] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

Hi Bernd, On 05/09/17 15:25, Bernd Edlinger wrote: Hi Christophe, On 09/05/17 10:45, Christophe Lyon wrote: Hi Bernd, On 4 September 2017 at 16:52, Kyrill Tkachov wrote: On 29/04/17 18:45, Bernd Edlinger wrote: Ping... I attached a rebased version since

Re: [PATCH 0/2] add unique_ptr class

On 09/05/2017 05:52 PM, Manuel López-Ibáñez wrote: > On 05/08/17 20:05, Pedro Alves wrote: >> That'd be an "obvious" choice, and I'm not terribly against it, >> though I wonder whether it'd be taking over a name that has a wider >> scope than intended? I.e., GNU is a larger set of projects than

Re: [RFA] [PATCH][PR tree-optimization/64910] Fix reassociation of binary bitwise operations with 3 operands

On 09/05/2017 12:38 AM, Christophe Lyon wrote: > Hi Jeff, > > > On 3 September 2017 at 16:44, Jeff Law wrote: >> On 01/13/2016 05:30 AM, Richard Biener wrote: >>> On Wed, Jan 13, 2016 at 7:39 AM, Jeff Law wrote: On 01/12/2016 08:11 AM, Richard Biener

Re: [PATCH][aarch64] Enable ifunc resolver attribute by default

On 05/09/17 18:09, Steve Ellcey wrote: > On Mon, 2017-09-04 at 15:40 +0100, Szabolcs Nagy wrote: > >> this is not the right default for bionic, uclibc and musl >> >> (gcc does not distinguish between supporting ifunc in the >> compiler vs runtime, so when ifunc is enabled it is assumed >> the c

Re: [PATCH][ARM] Improve max_insns_skipped logic

On 05/09/17 11:32, Wilco Dijkstra wrote: Kyrill Tkachov wrote: I like the simplifications in the selection logic here :) However, changing the value for ARM from 6 to 4 looks a bit arbitrary to me. There's probably a reason why default values for ARM and Thumb-2 are different (maybe not a

Re: [PATCH][aarch64] Enable ifunc resolver attribute by default

On Mon, 2017-09-04 at 15:40 +0100, Szabolcs Nagy wrote: > this is not the right default for bionic, uclibc and musl > > (gcc does not distinguish between supporting ifunc in the > compiler vs runtime, so when ifunc is enabled it is assumed > the c runtime will have support too, hence libatomic

Re: [PATCH v2, rs6000] Fix PR81833

Hi! On Tue, Aug 29, 2017 at 04:47:18PM -0500, Bill Schmidt wrote: > Thanks for approving the previous patch with changes. I've made those and > also > modified the test case to require VSX hardware for execution. I duplicated > the > test so we get coverage on P7 BE 32/64 and P8 BE/LE. I'd

Re: [PATCH 0/2] add unique_ptr class

On 05/08/17 20:05, Pedro Alves wrote: That'd be an "obvious" choice, and I'm not terribly against it, though I wonder whether it'd be taking over a name that has a wider scope than intended? I.e., GNU is a larger set of projects than the GNU toolchain. For example, there's Gnulib, which

Re: PING: [Updated, PATCH] i386: Avoid stack realignment if possible

On Fri, Sep 1, 2017 at 11:48 AM, H.J. Lu wrote: > On Sun, Aug 13, 2017 at 3:02 PM, H.J. Lu wrote: >> On Mon, Aug 07, 2017 at 08:58:49AM -0700, H.J. Lu wrote: >>> On Tue, Jul 25, 2017 at 7:54 AM, Uros Bizjak wrote: >>> > On Tue, Jul

Re: [PATCH, middle-end]: Introduce memory_blockage named insn pattern

Uros Bizjak writes: > On Tue, Sep 5, 2017 at 12:35 PM, Alexander Monakov wrote: >> On Tue, 5 Sep 2017, Uros Bizjak wrote: >>> This patch allows to emit memory_blockage pattern instead of default >>> asm volatile as a memory blockage. This patch is needed,

Re: [PING][PATCH 2/3] retire mem_signal_fence pattern

Hi, On 5 September 2017 at 13:40, Uros Bizjak wrote: > On Tue, Sep 5, 2017 at 12:28 PM, Alexander Monakov wrote: >> On Mon, 4 Sep 2017, Uros Bizjak wrote: >>> introduced a couple of regressions on x86 (-m32, 32bit) testsuite: >>> >>> New failures: >>>

Re: [PATCH] Another type demotion issue with ubsan (PR sanitizer/82072)

On 09/04/2017 08:21 AM, Marek Polacek wrote: > Vittorio reported another issue with convert_to_integer_1: for > u = -l; > where u is unsigned and l is long long the function does: > > 911 return convert (type, > 912 fold_build1 (ex_form, typex, > 913

PING: [PATCH] Add -static-pie to GCC driver to create static PIE

On Mon, Aug 28, 2017 at 10:13 AM, H.J. Lu wrote: > On Mon, Aug 28, 2017 at 9:10 AM, Joseph Myers wrote: >> On Tue, 8 Aug 2017, H.J. Lu wrote: >> >>> This patch adds -static-pie to GCC driver to create static PIE. A static >>> position independent

Re: [PING**2] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

Bernd Edlinger wrote: > Combine creates an invalid insn out of these two insns: Yes it looks like a latent bug. We need to use arm_general_register_operand as arm_adddi3/subdi3 only allow integer registers. You don't need a new predicate s_register_operand_nv. Also I'd prefer something like

Re: remove unused argument in duplicate_thread_path()

On 09/05/2017 06:39 AM, Aldy Hernandez wrote: > It looks like all remaining uses of duplicate_thread_path (ahem, one), > pass a NULL to the REGION_COPY argument. > > OK? > OK. jeff

[PING][PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

Hello, this is a ping for that patch: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01958.html Thanks.

[PATCH, openacc, og7, committed] Make reduction copy clauses 'private'

As we discussed, we are to support a behavior where within individual gangs, worker/vector level reductions will correctly work with results immediately available. This is on top of the implicit 'copy' clause added when we have loop reductions. This patch adds a capability to mark map clauses

Re: [PING**2] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

Hi Christophe, On 09/05/17 10:45, Christophe Lyon wrote: > Hi Bernd, > > > On 4 September 2017 at 16:52, Kyrill Tkachov > wrote: >> >> On 29/04/17 18:45, Bernd Edlinger wrote: >>> >>> Ping... >>> >>> I attached a rebased version since there was a merge conflict in

Re: [PATCH v2, middle-end]: Introduce memory_blockage named insn pattern

On Tue, 5 Sep 2017, Uros Bizjak wrote: > Revised patch, incorporates fixes from Alexander's review comments. > > I removed some implementation details from Alexander's description of > memory_blockage named pattern. Well, to me it wasn't really obvious why a named pattern was needed in the

RE: [RFC, vectorizer] Allow single element vector types for vector reduction operations

> -Original Message- > From: Richard Biener [mailto:rguent...@suse.de] > Sent: 05 September 2017 14:13 > To: Tamar Christina > Cc: Andrew Pinski; Andreas Schwab; Jon Beniston; gcc-patches@gcc.gnu.org; > nd > Subject: RE: [RFC, vectorizer] Allow single element vector types for vector >

[PATCH v2, middle-end]: Introduce memory_blockage named insn pattern

Revised patch, incorporates fixes from Alexander's review comments. I removed some implementation details from Alexander's description of memory_blockage named pattern. 2017-09-05 Uros Bizjak * target-insns.def: Add memory_blockage. * optabs.c

RE: [RFC, vectorizer] Allow single element vector types for vector reduction operations

On Tue, 5 Sep 2017, Tamar Christina wrote: > > > > -Original Message- > > From: Richard Biener [mailto:rguent...@suse.de] > > Sent: 05 September 2017 13:51 > > To: Tamar Christina > > Cc: Andrew Pinski; Andreas Schwab; Jon Beniston; gcc-patches@gcc.gnu.org; > > nd > > Subject: RE: [RFC,

RE: [RFC, vectorizer] Allow single element vector types for vector reduction operations

> -Original Message- > From: Richard Biener [mailto:rguent...@suse.de] > Sent: 05 September 2017 13:51 > To: Tamar Christina > Cc: Andrew Pinski; Andreas Schwab; Jon Beniston; gcc-patches@gcc.gnu.org; > nd > Subject: RE: [RFC, vectorizer] Allow single element vector types for vector >

Re: Add support to trace comparison instructions and switch statements

Hi Attachment is my updated path. The implementation of parse_sanitizer_options is not elegance enough. Mixing handling flags of fsanitize is easy to make mistakes. ChangeLog: gcc/ChangeLog: 2017-09-05 Wish Wu * asan.c (initialize_sanitizer_builtins):

Re: [5/9] Add mode_for_int_vector helper functions

On Tue, Sep 5, 2017 at 2:33 PM, Richard Sandiford wrote: > Richard Biener writes: >> On Mon, Sep 4, 2017 at 1:36 PM, Richard Sandiford >> wrote: >>> There are at least a few places that want to create an

RE: [RFC, vectorizer] Allow single element vector types for vector reduction operations

On Tue, 5 Sep 2017, Richard Biener wrote: > On Tue, 5 Sep 2017, Tamar Christina wrote: > > > Hi Richard, > > > > That was an really interesting analysis, thanks for the details! > > > > Would you be submitting the patch you proposed at the end as a fix? > > I'm testing it currently.

remove unused argument in duplicate_thread_path()

It looks like all remaining uses of duplicate_thread_path (ahem, one), pass a NULL to the REGION_COPY argument. OK? curr Description: Binary data

Re: [PATCH] Handle wide-chars in native_encode_string

On Tue, 5 Sep 2017, Richard Biener wrote: > don't have any BITS_PER_UNIT != 8 port (we had c4x). I'm not > sure what constraints we have on CHAR_TYPE_SIZE vs. BITS_PER_UNIT, > or for what port it would make sense to have differing values. BITS_PER_UNIT = size of QImode = unit that target

Re: [5/9] Add mode_for_int_vector helper functions

Richard Biener writes: > On Mon, Sep 4, 2017 at 1:36 PM, Richard Sandiford > wrote: >> There are at least a few places that want to create an integer vector >> with a specified element size and element count, or to create the >> integer

Re: [PATCH, middle-end]: Introduce memory_blockage named insn pattern

On Tue, Sep 5, 2017 at 2:03 PM, Alexander Monakov wrote: > On Tue, 5 Sep 2017, Uros Bizjak wrote: >> However, this definition can't be generic, since unspec is used. > > I see, if the only reason this needs a named pattern is lack of generic UNSPEC > values, I believe it would

Re: [PATCH, middle-end]: Introduce memory_blockage named insn pattern

On Tue, 5 Sep 2017, Uros Bizjak wrote: > However, this definition can't be generic, since unspec is used. I see, if the only reason this needs a named pattern is lack of generic UNSPEC values, I believe it would be helpful to mention that in the documentation. A few comments on the patch: > @@

Re: [PING][PATCH 2/3] retire mem_signal_fence pattern

On Tue, Sep 5, 2017 at 12:28 PM, Alexander Monakov wrote: > On Mon, 4 Sep 2017, Uros Bizjak wrote: >> introduced a couple of regressions on x86 (-m32, 32bit) testsuite: >> >> New failures: >> FAIL: gcc.target/i386/pr71245-1.c scan-assembler-not (fistp|fild) >> FAIL:

Re: [9/9] Make bitsize_mode_for_mode return an opt_mode

On Mon, Sep 4, 2017 at 1:43 PM, Richard Sandiford wrote: > 2017-09-04 Richard Sandiford Ok. Richard. > gcc/ > * machmode.h (bitwise_mode_for_mode): Return opt_mode. > * stor-layout.c (bitwise_mode_for_mode):

Re: [8/9] Make mode_for_size_tree return an opt_mode

On Mon, Sep 4, 2017 at 1:42 PM, Richard Sandiford wrote: > ...for consistency with mode_for_size Ok. Thanks, Richard. > 2017-09-04 Richard Sandiford > > gcc/ > * stor-layout.h (mode_for_size_tree): Return an opt_mode. >

Re: [6/9] Make mode_for_vector return an opt_mode

On Mon, Sep 4, 2017 at 1:39 PM, Richard Sandiford wrote: > ...following on from the mode_for_size change. The patch also removes > machmode.h versions of the stor-layout.c comments, since the comments > in the .c file are more complete. Ok. Richard. > 2017-09-04

Re: [7/9] Make targetm.get_mask_mode return an opt_mode

On Mon, Sep 4, 2017 at 1:41 PM, Richard Sandiford wrote: > ...for consistency with mode_for_vector. Ok. Richard. > 2017-09-04 Richard Sandiford > > gcc/ > * target.def (get_mask_mode): Change return type to opt_mode. >

Re: [5/9] Add mode_for_int_vector helper functions

On Mon, Sep 4, 2017 at 1:36 PM, Richard Sandiford wrote: > There are at least a few places that want to create an integer vector > with a specified element size and element count, or to create the > integer equivalent of an existing mode. This patch adds helpers >

Re: [4/9] Make mode_for_size return an opt_mode

On Mon, Sep 4, 2017 at 1:35 PM, Richard Sandiford wrote: > ...to make it consistent with int_mode_for_size etc. > > require () seems like the right choice in replace_reg_with_saved_mem > because we use the chosen mode for saving and restoring registers, > which

Re: [3/9] (decimal_)float_mode_for_size in real.h

On Mon, Sep 4, 2017 at 1:31 PM, Richard Sandiford wrote: > This patch makes the binary float macros in real.h use > float_mode_for_size and adds a corresponding decimal_float_mode_for_size > for the decimal macros. Ok. Richard. > 2017-09-04 Richard Sandiford

Re: [2/9] Make more use of int_mode_for_size

On Mon, Sep 4, 2017 at 1:31 PM, Richard Sandiford wrote: > This patch converts more places that could use int_mode_for_size instead > of mode_for_size. This is in preparation for an upcoming patch that > makes mode_for_size itself return an opt_mode. > > require ()

Re: [1/9] Make more use of int_mode_for_mode

On Mon, Sep 4, 2017 at 1:26 PM, Richard Sandiford wrote: > This patch converts more places that could use int_mode_for_mode > instead of mode_for_size. This is in preparation for an upcoming > patch that makes mode_for_size itself return an opt_mode. > > The reason

Re: [C++/ARM Patch] PR 81942 ("ICE on empty constexpr constructor with C++14")

On 09/05/2017 06:19 AM, Paolo Carlini wrote: in this ICE on valid, a gcc_assert fires when a GOTO_EXPR is handled by cxx_eval_constant_expression which is the translation of a "return;" on a targetm.cxx.cdtor_returns_this target (like ARM): I think the right way to handle this is marking

Re: [PATCH, middle-end]: Introduce memory_blockage named insn pattern

On Tue, Sep 5, 2017 at 12:35 PM, Alexander Monakov wrote: > On Tue, 5 Sep 2017, Uros Bizjak wrote: >> This patch allows to emit memory_blockage pattern instead of default >> asm volatile as a memory blockage. This patch is needed, so targets >> (e.g. x86) can define and emit

Re: [PATCH] [PR79542][Ada] Fix ICE in dwarf2out.c with nested func. inlining

On 09/04/2017 11:26 AM, Richard Biener wrote: No more pending issues and yes, I guess the fix is ok for the branch. Ok, thanks! This is now comitted on the 7 release branch. -- Pierre-Marie de Rodat

Re: [00/77] Add wrapper classes for machine_modes

On 9/3/17, Gerald Pfeifer wrote: > Hi Richard, > > I'm afraid your patchset has broken bootstrap on i686-unknown-freebsd10.3, > in fact, it appears on FreeBSD in general (amd64-unknown-freebsd11 as > well): > > > /scratch/tmp/gerald/GCC-HEAD/gcc/builtins.c:4913:6: error:

RE: [RFC, vectorizer] Allow single element vector types for vector reduction operations

On Tue, 5 Sep 2017, Tamar Christina wrote: > Hi Richard, > > That was an really interesting analysis, thanks for the details! > > Would you be submitting the patch you proposed at the end as a fix? I'm testing it currently. Richard. > Thanks, > Tamar > > > -Original Message- > >

Re: [PATCH, middle-end]: Introduce memory_blockage named insn pattern

On Tue, 5 Sep 2017, Uros Bizjak wrote: > This patch allows to emit memory_blockage pattern instead of default > asm volatile as a memory blockage. This patch is needed, so targets > (e.g. x86) can define and emit more optimal memory blockage pseudo > insn. Optimal in what sense? What pattern do

Re: [PING][PATCH 2/3] retire mem_signal_fence pattern

On Tue, Sep 5, 2017 at 12:28 PM, Alexander Monakov wrote: > On Mon, 4 Sep 2017, Uros Bizjak wrote: >> introduced a couple of regressions on x86 (-m32, 32bit) testsuite: >> >> New failures: >> FAIL: gcc.target/i386/pr71245-1.c scan-assembler-not (fistp|fild) >> FAIL:

Re: [PATCH][ARM] Improve max_insns_skipped logic

Kyrill Tkachov wrote: > I like the simplifications in the selection logic here :) > However, changing the value for ARM from 6 to 4 looks a bit arbitrary to me. > There's probably a reason why default values for ARM and Thumb-2 are > different > (maybe not a good one) and I'd rather not change

Re: [PATCH] Add noexcept to shared_ptr owner comparisons (LWG 2873)

On 05/09/17 08:30 +0200, Christophe Lyon wrote: Hi Jonathan On 5 June 2017 at 11:34, Jonathan Wakely wrote: C++17 requires these to be noexcept, and there's no reason not to do it for earlier standard modes too. * include/bits/shared_ptr_base.h

Re: [PING][PATCH 2/3] retire mem_signal_fence pattern

On Mon, 4 Sep 2017, Uros Bizjak wrote: > introduced a couple of regressions on x86 (-m32, 32bit) testsuite: > > New failures: > FAIL: gcc.target/i386/pr71245-1.c scan-assembler-not (fistp|fild) > FAIL: gcc.target/i386/pr71245-2.c scan-assembler-not movlps Sorry. I suggest that the tests be

[PATCH, middle-end]: Introduce memory_blockage named insn pattern

Hello! This patch allows to emit memory_blockage pattern instead of default asm volatile as a memory blockage. This patch is needed, so targets (e.g. x86) can define and emit more optimal memory blockage pseudo insn. And let's call scheduler memory barriers a "memory blockage" pseudo insn, not

RE: [RFC, vectorizer] Allow single element vector types for vector reduction operations

Hi Richard, That was an really interesting analysis, thanks for the details! Would you be submitting the patch you proposed at the end as a fix? Thanks, Tamar > -Original Message- > From: Richard Biener [mailto:rguent...@suse.de] > Sent: 05 September 2017 10:38 > To: Andrew Pinski >

[C++/ARM Patch] PR 81942 ("ICE on empty constexpr constructor with C++14")

Hi, Hi, in this ICE on valid, a gcc_assert fires when a GOTO_EXPR is handled by cxx_eval_constant_expression which is the translation of a "return;" on a targetm.cxx.cdtor_returns_this target (like ARM): ;; Function constexpr A::A() (null) ;; enabled by -tree-original { // predicted

Re: [00/77] Add wrapper classes for machine_modes

Jakub Jelinek writes: > On Sun, Sep 03, 2017 at 09:18:33PM +0100, Richard Sandiford wrote: >> Gerald Pfeifer writes: >> > Hi Richard, >> > >> > I'm afraid your patchset has broken bootstrap on i686-unknown-freebsd10.3, >> > in fact, it appears on FreeBSD in

Re: [Libgomp, Fortran] Fix canadian cross build

On Tue, Sep 05, 2017 at 10:58:22AM +0200, Yvan Roux wrote: > ping > > https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01784.html This really needs to be reviewed by a build machinery maintainer. > > config/ChangeLog > > 2017-06-23 Yvan Roux > > > >

Re: [00/77] Add wrapper classes for machine_modes

On Sun, Sep 03, 2017 at 09:18:33PM +0100, Richard Sandiford wrote: > Gerald Pfeifer writes: > > Hi Richard, > > > > I'm afraid your patchset has broken bootstrap on i686-unknown-freebsd10.3, > > in fact, it appears on FreeBSD in general (amd64-unknown-freebsd11 as well): > >

Fix PR ada/62235

Tested on x86_64-suse-linux, applied on mainline and 7 branch. 2017-09-05 Eric Botcazou PR ada/62235 * gcc-interface/decl.c (gnat_to_gnu_entity): Skip regular processing for Itypes that are E_Record_Subtype with a cloned subtype. : Use

Re: [RFC, vectorizer] Allow single element vector types for vector reduction operations

On Mon, 4 Sep 2017, Andrew Pinski wrote: > On Mon, Sep 4, 2017 at 7:28 AM, Tamar Christina > wrote: > >> > vect__5.25_58 = VIEW_CONVERT_EXPR >> intD.11>(vect__4.21_65); > >> > vect__5.25_57 = VIEW_CONVERT_EXPR >>

[Ada] Get rid of call to int->fp conversion routine

Tested on x86_64-suse-linux, applied on mainline. 2017-09-05 Eric Botcazou * gcc-interface/trans.c (convert_with_check): Use a custom base type if the base type of the expression has a different machine mode. Rename a couple of parameters and

[Ada] Fix bogus constraint error on value conversion with -gnatVa

Tested on x86_64-suse-linux, applied on mainline. 2017-09-05 Eric Botcazou * gcc-interface/trans.c (Attribute_to_gnu) : Do notstrip conversions around prefixes that are not references. -- Eric BotcazouIndex: gcc-interface/trans.c

[Ada] Fix ICE on type witn zero precision

This is a regression present on the mainline, 7 and 6 branches, in the form of an ICE during tree-ccp, which is confused by a type witn zero precision. Tested on x86_64-suse-linux, applied on mainline, 7 and 6 branches. 2017-09-05 Eric Botcazou *

Re: [PATCH, GCC/ARM, ping] Remove ARMv8-M code for D17-D31

Ping? Best regards, Thomas On 25/08/17 12:18, Thomas Preudhomme wrote: Hi, I've now also added a couple more changes: * size to_clear_bitmap according to maxregno to be consistent with its use * use directly TARGET_HARD_FLOAT instead of clear_vfpregs Original message below (ChangeLog

Re: [PATCH, GCC/testsuite/ARM, ping3] Fix coprocessor intrinsic test failures on ARMv8-A

Ping? Best regards, Thomas On 23/08/17 11:59, Thomas Preudhomme wrote: Ping? Best regards, Thomas On 17/07/17 09:51, Thomas Preudhomme wrote: Ping? Best regards, Thomas On 12/07/17 14:31, Thomas Preudhomme wrote: Coprocessor intrinsic tests in gcc.target/arm/acle test whether

[Ada] Small housekeeping work

Tested on x86_64-suse-linux, applied on mainline. 2017-09-05 Eric Botcazou * gcc-interface/gigi.h (renaming_from_generic_instantiation_p):Turn to (renaming_from_instantiation_p): ...this. * gcc-interface/decl.c (gnat_to_gnu_entity): Use inline

Re: [Libgomp, Fortran] Fix canadian cross build

On 18 August 2017 at 10:27, Yvan Roux wrote: > On 4 August 2017 at 15:52, Yvan Roux wrote: >> On 11 July 2017 at 12:25, Yvan Roux wrote: >>> On 3 July 2017 at 11:21, Yvan Roux wrote: On 23 June 2017 at

[Ada] Fix ICE on Taft-Amendment types

This is a regression recently introduced on the mainline for Taft-Amendment types, when the restriction on inter-unit inlining was lifted. Tested on x86_64-suse-linux, applied on mainline. 2017-09-05 Eric Botcazou * gcc-interface/trans.c

Re: [75/77] Use scalar_mode in the AArch64 port

On Thu, Jul 13, 2017 at 10:04:58AM +0100, Richard Sandiford wrote: > Similar to the previous scalar_int_mode patch. OK. Thanks, James > > 2017-07-13 Richard Sandiford > Alan Hayward > David Sherwood

Re: [61/77] Use scalar_int_mode in the AArch64 port

On Thu, Jul 13, 2017 at 10:00:03AM +0100, Richard Sandiford wrote: > This patch makes the AArch64 port use scalar_int_mode in various places. > Other ports won't need this kind of change; we only need it for AArch64 > because of the variable-sized SVE modes. > > The only change in functionality

Re: [PING**2] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

Hi Bernd, On 4 September 2017 at 16:52, Kyrill Tkachov wrote: > > On 29/04/17 18:45, Bernd Edlinger wrote: >> >> Ping... >> >> I attached a rebased version since there was a merge conflict in >> the xordi3 pattern, otherwise the patch is still identical. >> It

[Ada] Enhance -gnatR3 output for simple dynamic record types

This changes the terse -gnatR3 output for simple dynamic record types like: package Q is type My_Index is range 1 .. 1024 * 1024; type Arr is array (My_Index range <>) of Short_Integer; function N return My_Index; end Q; with Q; use Q; package P is type R is record I1 : Integer;

[Ada] Do not generate useless temporary for allocator

This is a regression present on the mainline, 7 and 6 branches: the compiler generates an useless temporary for an allocator. Tested on x86_64-suse-linux, applied on mainline, 7 and 6 branches. 2017-09-05 Eric Botcazou * gcc-interface/trans.c (Call_to_gnu):

Re: [PATCH] Handle wide-chars in native_encode_string

On Mon, 4 Sep 2017, Joseph Myers wrote: > On Mon, 4 Sep 2017, Richard Biener wrote: > > > always have a consistend "character" size and how the individual > > "characters" are encoded. The patch assumes that the array element > > type of the STRING_CST can be used to get access to individual >

[Ada] Fix ICE on multi-dimensional array

This is a regression present on the mainline, 7 and 6 branches, in the form of an ICE during tree-sra, which is confused by an unconstrained array type. Tested on x86_64-suse-linux, applied on mainline, 7 and 6 branches. 2017-09-05 Eric Botcazou *

[PATCH] Fix PR82102

The following fixes PR82102, GIMPLE_NOPs don't have a lhs so we have to care for that case. Tested on x86_64-unknown-linux-gnu, applied as obvious. Richard. 2017-09-05 Richard Biener PR tree-optimization/82102 * tree-ssa-pre.c (fini_eliminate): Check if

[testsuite, committed] Fix call arguments mismatch in gcc.c-torture/compile/pr82052.c

[ was: Re: [PATCH][committed] Always initialize hash table elements ] On 09/01/2017 05:39 PM, Jeff Law wrote: * gcc.c-torture/compile/pr82052.c: New test. diff --git a/gcc/testsuite/gcc.c-torture/compile/pr82052.c b/gcc/testsuite/gcc.c-torture/compile/pr82052.c +short fn2()

Re: [RFA] [PATCH][PR tree-optimization/64910] Fix reassociation of binary bitwise operations with 3 operands

Hi Jeff, On 3 September 2017 at 16:44, Jeff Law wrote: > On 01/13/2016 05:30 AM, Richard Biener wrote: >> On Wed, Jan 13, 2016 at 7:39 AM, Jeff Law wrote: >>> On 01/12/2016 08:11 AM, Richard Biener wrote: On Tue, Jan 12, 2016 at 6:10 AM, Jeff Law

  1   2   >