Re: [PATCH] PR77359: Properly align local variables in functions calling alloca.

On Thu, Nov 10, 2016 at 6:47 PM, Dominik Vogt wrote: > On Thu, Nov 03, 2016 at 11:40:44AM +0100, Dominik Vogt wrote: >> The attached patch fixes the stack layout problems on AIX and >> Power as described here: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 >>

Re: [PATCH/AARCH64] Handle ILP32 multi-arch

On Tue, Oct 25, 2016 at 3:25 PM, Matthias Klose wrote: > On 07.10.2016 23:08, Andrew Pinski wrote: >> Hi, >> This patch adds ilp32 multi-arch support. This is needed to support >> multi-arch on Debian like systems. >> >> OK? Bootstrapped and tested on aarch64-linux-gnu with

[PATCH/AARCH64] Improved -mcpu/mtune/march=native handling

As I mentioned in my other emails, parsing /proc/cpuinfo has one issue is that the current parsing assumes many different things about the format. So the best way to do this is to parse /sys/devices/system/cpu/cpuN/regs/identification/midr_el1 files instead. To get which cpu are present (though

Re: [PATCH] Fix PR 78243 on PowerPC

On Thu, Nov 10, 2016 at 07:21:15PM -0500, Michael Meissner wrote: > --- gcc/config/rs6000/vsx.md (revision 242048) > +++ gcc/config/rs6000/vsx.md (revision 242049) > @@ -2542,10 +2542,13 @@ (define_insn "vsx_extract__p9" >"VECTOR_MEM_VSX_P (mode) && TARGET_VEXTRACTUB > &&

Re: [PATCH] PR78241, fix loop unroller when niter expr is not reliable

On Wed, Nov 9, 2016 at 2:13 PM, Pat Haugen wrote: > The following fixes a problem introduced by my earlier loop unroller patch, > https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01612.html. In instances where > the niter expr is not reliable we need to still emit an

[PATCH] Fix PR 78243 on PowerPC

Aaron Sawdey has been running the GCC testsuite on the power9 simulator and he noticed that: gcc.c-torture/execute/pr68532.c does not run, and opened bug 78243 for this failure. Now, if you compile pr68532 with normal options (-O2/-O3 and -mcpu=power8 or -mcpu=power9) it works because

Re: [PATCH] PR77359: Properly align local variables in functions calling alloca.

On Fri, Nov 11, 2016 at 12:47:02AM +0100, Dominik Vogt wrote: > On Thu, Nov 03, 2016 at 11:40:44AM +0100, Dominik Vogt wrote: > > The attached patch fixes the stack layout problems on AIX and > > Power as described here: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 > > > > The

Re: [PATCH] PR77359: Properly align local variables in functions calling alloca.

On Thu, Nov 03, 2016 at 11:40:44AM +0100, Dominik Vogt wrote: > The attached patch fixes the stack layout problems on AIX and > Power as described here: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359 > > The patch has been bootstrapped on AIX (32 Bit) and bootstrappend > and regression

Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation

On Thu, Nov 10, 2016 at 02:42:24PM -0800, Andrew Pinski wrote: > On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov > > I ran SPEC2006 on a Cortex-A72. Overall scores were neutral but there were > > some interesting swings. > > 458.sjeng +1.45% > > 471.omnetpp +2.19% > > 445.gobmk -2.01% >

Re: [RFC] Check number of uses in simplify_cond_using_ranges().

On Thu, Nov 10, 2016 at 11:53:07PM +0100, Marc Glisse wrote: > On Thu, 10 Nov 2016, Dominik Vogt wrote: > > >On Wed, Nov 09, 2016 at 03:46:38PM +0100, Richard Biener wrote: > >>On Wed, Nov 9, 2016 at 3:30 PM, Dominik Vogt > >>wrote: > >>>Something like the attached

Re: [PATCH, gcc, wwwdocs] Document upcoming Qualcomm Falkor processor support

On Fri, 11 Nov 2016, Siddhesh Poyarekar wrote: > This patch documents the newly added flag in gcc 7 for the upcoming > Qualcomm Falkor processor core. Looks good to me. Probably a good idea for one of the ARM maintainers to sign off, too. Gerald

Go patch committed: copy signal code from Go 1.7 runtime

This patch to the Go frontend and libgo copies the signal code from the Go 1.7 runtime. This adds a little shell script to auto-generate runtime.sigtable from the known signal names. This forces the main package to always import the runtime package. Otherwise some runtime package global

Re: [RFC] Check number of uses in simplify_cond_using_ranges().

On Thu, 10 Nov 2016, Dominik Vogt wrote: On Wed, Nov 09, 2016 at 03:46:38PM +0100, Richard Biener wrote: On Wed, Nov 9, 2016 at 3:30 PM, Dominik Vogt wrote: Something like the attached patch? Robin and me have spent quite some time to figure out the new pattern.

Re: [PATCH] combine: Do not call simplify from inside change_zero_ext (PR78232)

Hi all, I now committed this, with changelog PR rtl-optimization/78232 * combine.c (try_combine): Add a big comment about why reusing i2dest is undesirable. (change_zero_ext): Do not call simplify_gen_binary, do the simplifications manually. and the patch

Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

FAIL: gfortran.dg/char_result_16.f90 -g -flto (internal compiler error) FAIL: gfortran.dg/char_result_16.f90 -g -flto (test for excess errors) The ICE is for both -m32 and -m64 (module_procedure_3_db_1.f90 is the test posted in my last mail) % gfc module_procedure_3_db_1.f90 -flto

Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation

On Thu, Nov 10, 2016 at 6:25 AM, Kyrill Tkachov wrote: > Hi all, > > This patch implements the new separate shrink-wrapping hooks for aarch64. > In separate shrink wrapping (as I understand it) we consider each register > save/restore as > a 'component' that can be

Re: C++ PATCH for c++/77337 (auto return and constexpr lambda)

On Thu, Nov 10, 2016 at 01:42:20PM -0800, Jason Merrill wrote: > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp1y/auto-fn33.C > @@ -0,0 +1,27 @@ > +// PR c++/77337 > +// { dg-do compile { target c++14 } } > + > +template > +struct fix_type { > + Functor functor; > + > + decltype(auto)

Re: [PATCH][1/2] GIMPLE Frontend, C FE parts (and GIMPLE parser)

On Thu, 10 Nov 2016, Richard Biener wrote: > I'll address those comments. As you did not have any comments on the > c-parser.[CH] parts does that mean you are fine with them? That is, > does the above constitute a complete review of the patch? I am fine with the c-parser.[ch] parts. --

C++ PATCH for c++/77337 (auto return and constexpr lambda)

The constexpr lambda change introduced some problematic dependency ordering, since instantiate constexpr functions aggressively so that they are available for constexpr evaluation. The patch for 65942 delayed that instantiation by triggering it from constexpr evaluation directly rather than

Re: Reject out-of-range bit pos in bit-fields insns operating on a register.

On Nov 10 2016, Jeff Law wrote: > On 11/09/2016 03:40 AM, Andreas Schwab wrote: >> As seen by the testcase in PR77822, combine can generate out-of-range >> bit pos in a bit-field insn, unless the pattern explicitly rejects it. >> This only makes a difference for expressions that

Re: Reject out-of-range bit pos in bit-fields insns operating on a register.

On 11/09/2016 03:40 AM, Andreas Schwab wrote: As seen by the testcase in PR77822, combine can generate out-of-range bit pos in a bit-field insn, unless the pattern explicitly rejects it. This only makes a difference for expressions that are undefined at runtime. Without that we would either

Re: Go patch committed: copy print code from Go 1.7 runtime

On Tue, Oct 18, 2016 at 1:06 AM, Uros Bizjak wrote: > >> This patch copies the code that implements the print and println >> predeclared functions from the Go 1.7 runtime. The compiler is >> changed to use the new names, and to call the printlock and >> printunlock functions

Re: [RFC] Check number of uses in simplify_cond_using_ranges().

On Wed, Nov 09, 2016 at 03:46:38PM +0100, Richard Biener wrote: > On Wed, Nov 9, 2016 at 3:30 PM, Dominik Vogt wrote: > > Something like the attached patch? Robin and me have spent quite > > some time to figure out the new pattern. Two questions: > > > > 1) In the match

[gomp4] remove OMP_CLAUSE_DEVICE_RESIDENT

I've committed this patch to gomp-4_0-branch which removes OMP_CLAUSE_DEVICE_RESIDENT. This standalone clause is no longer necessary, and hasn't been for a while, because device_resident is treated as a data mapping type for OMP_CLAUSE_MAP, and not a clause itself. Cesar 2016-11-10 Cesar

Re: [PATCH] Fix ICE in default_use_anchors_for_symbol_p (PR middle-end/78201)

Hi, On 10 November 2016 at 18:00, Jakub Jelinek wrote: > Hi! > > On arm/aarch64 we ICE because some decls that make it here has non-NULL > DECL_SIZE, which is a VAR_DECL rather than CONST_INT (or DECL_SIZE that > doesn't fit into shwi would ICE similarly). While it is arguably

Re: [ipa-vrp] ice in set_value_range

Hi David, Sorry about the breakage. I have already reverted this patch as this is causing bootstrap failures. I will test it on more targets before submitting this patch again. Thanks, Kugan On 11/11/16 00:25, David Edelsohn wrote: Kugan Is there a PR for this failure? It broke bootstrap

[PATCH, Fortran] PR78277: ICE in is_anonymous_component, at fortran/interface.c:450

All, The attached fixes an ICE-on-invalid-code, specifically due to invalid anonymous structure declarations, as seen in the attached test case. This also improves error handling in such cases- the anonymous structure body will continue to be parsed even if the variable-decl after the opening

Re: [PATCH][1/2] GIMPLE Frontend, C FE parts (and GIMPLE parser)

On November 10, 2016 6:38:12 PM GMT+01:00, Joseph Myers wrote: >On Fri, 28 Oct 2016, Richard Biener wrote: > >> +/* Parse a gimple expression. >> + >> + gimple-expression: >> + gimple-unary-expression >> + gimple-call-statement >> + gimple-binary-expression

Re: [PATCH] Fix PR71762

On November 10, 2016 7:39:57 PM GMT+01:00, Marc Glisse wrote: >On Thu, 10 Nov 2016, Richard Biener wrote: > >> The following fixes PR71762 via reverting the transforms of >> ~X & Y to X < Y and similar because when the bools they apply to >> are expanded to RTL undefined

Re: [PATCH] Fix PR71762

On Thu, 10 Nov 2016, Richard Biener wrote: The following fixes PR71762 via reverting the transforms of ~X & Y to X < Y and similar because when the bools they apply to are expanded to RTL undefined values are not reliably zero-extended and thus the transform is invalid. Ensuring the

[PATCH, gcc, wwwdocs] Document upcoming Qualcomm Falkor processor support

Hi, This patch documents the newly added flag in gcc 7 for the upcoming Qualcomm Falkor processor core. Siddhesh Index: htdocs/gcc-7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v retrieving revision 1.24

Re: [patch, doc] PR 37998 -- Unclear documentation of -fno-common

On Thu, 10 Nov 2016, Sandra Loosemore wrote: > This patch is for a long-standing issue with the way -fno-common is > documented. The specific bug report was about an ambiguous use of the word > "This", but as I looked more at the way this option was described, I realized > the whole thing was

[patch, doc] PR 37998 -- Unclear documentation of -fno-common

This patch is for a long-standing issue with the way -fno-common is documented. The specific bug report was about an ambiguous use of the word "This", but as I looked more at the way this option was described, I realized the whole thing was needlessly confusing because it didn't use the

Re: [PATCH], PowerPC ISA 3.0, allow QImode/HImode to go into vector registers

On Thu, Nov 10, 2016 at 10:05:25AM -0600, Segher Boessenkool wrote: > Hi Mike, > > > I have built the spec 2006 CPU benchmark suite with these changes, and the > > power8 (ISA 2.07) code generation does not change. > > Very good to hear :-) > > Just some nits; okay for trunk with that fixed: >

[gomp4] add support for derived types in ACC UPDATE

OpenACC 2.0a has limited support for fortran derived types. Basically, derived type variables are only supported in ACC UPDATE. Rather than adding generalized support for derived times in the gimplifier, this patch has the fortran FE pass both subarrays and arrays as void pointers with an

Re: [PATCH][1/2] GIMPLE Frontend, C FE parts (and GIMPLE parser)

On Fri, 28 Oct 2016, Richard Biener wrote: > +/* Parse a gimple expression. > + > + gimple-expression: > + gimple-unary-expression > + gimple-call-statement > + gimple-binary-expression > + gimple-assign-expression > + gimple-cast-expression I don't see any comments

Re: [PATCH] dwarf2cfi: Dump row differences before asserting

On Thu, Nov 10, 2016 at 11:29:12AM -0600, Segher Boessenkool wrote: > Ping. > > On Mon, Oct 31, 2016 at 05:15:53PM +, Segher Boessenkool wrote: > > If maybe_record_trace_start fails because the CFI is inconsistent on two > > paths into a block it currently just ICEs. This changes it to also

Re: [PATCH] Introduce -fprofile-update=maybe-atomic

On 11/10/2016 08:24 AM, Martin Liška wrote: On 11/10/2016 05:17 PM, David Edelsohn wrote: Maybe instead of adding "maybe", we need to change the severity of the warning so that the warning is not emitted by default. Adding the warning option to -Wextra can be solution. Is it acceptable

Re: [PATCH] dwarf2cfi: Dump row differences before asserting

Ping. On Mon, Oct 31, 2016 at 05:15:53PM +, Segher Boessenkool wrote: > If maybe_record_trace_start fails because the CFI is inconsistent on two > paths into a block it currently just ICEs. This changes it to also dump > the CFI on those two paths in the dump file; debugging it without that

[PATCH][ARM] Improve max_insns_skipped logic

Improve the logic when setting max_insns_skipped. Limit the maximum size of IT to MAX_INSN_PER_IT_BLOCK as otherwise multiple IT instructions are needed, increasing codesize. Given 4 works well for Thumb-2, use the same limit for ARM for consistency. ChangeLog: 2016-11-04 Wilco Dijkstra

Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions

2016-11-10 20:14 GMT+03:00 Vladimir N Makarov : > > > On 11/10/2016 11:27 AM, Andrew Senkevich wrote: >> >> Hi, >> >> this patch enabled AVX512_4FMAPS and AVX512_4VNNIW instructions. >> >> It requires additional patch for register allocator from Vladimir >> Makarov to be

Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions

2016-11-10 19:36 GMT+03:00 Jakub Jelinek : > On Thu, Nov 10, 2016 at 07:27:00PM +0300, Andrew Senkevich wrote: >> Hi, >> >> this patch enabled AVX512_4FMAPS and AVX512_4VNNIW instructions. >> >> It requires additional patch for register allocator from Vladimir >> Makarov to be

Re: [PATCH 2/2][AArch64] Add bfx attribute

> On 10 Nov 2016, at 18:14, Wilco Dijkstra wrote: > > I think the XGene-1 scheduler might need a similar change as currently all > AArch64 > shifts are modelled as 2-cycle operations. Thanks for the heads-up. We’ll indeed need to update this. Regards, Philipp.

[PATCH][AArch64] Improve TI mode address offsets

Improve TI mode address offsets - these may either use LDP of 64-bit or LDR of 128-bit, so we need to use the correct intersection of offsets. When splitting a large offset into base and offset, use a signed 9-bit unscaled offset. Remove the Ump constraint on movti and movtf instructions as this

Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions

On 11/10/2016 11:27 AM, Andrew Senkevich wrote: Hi, this patch enabled AVX512_4FMAPS and AVX512_4VNNIW instructions. It requires additional patch for register allocator from Vladimir Makarov to be committed before. I've just committed the necessary patch.

[PATCH 2/2][AArch64] Add bfx attribute

The second patch updates the Cortex-A57 scheduler now that we can differentiate between shifts and bitfield inserts. The Cortex-A57 Software Optimization Guide indicates that BFM operations use the integer multi-cycle pipeline, while ARM UXTB/H instructions use the Integer 1 or Integer 0

Re: gomp-nvptx branch - middle-end changes

gcc/ * internal-fn.c (expand_GOMP_SIMT_LANE): New. (expand_GOMP_SIMT_VF): New. (expand_GOMP_SIMT_LAST_LANE): New. (expand_GOMP_SIMT_ORDERED_PRED): New. (expand_GOMP_SIMT_VOTE_ANY): New. (expand_GOMP_SIMT_XCHG_BFLY): New.

Re: gomp-nvptx branch - libgomp changes

libgomp/ * Makefile.am (libgomp_la_SOURCES): Add atomic.c, icv.c, icv-device.c. * Makefile.in. Regenerate. * configure.ac [nvptx*-*-*] (libgomp_use_pthreads): Set and use it... (LIBGOMP_USE_PTHREADS): ...here; new define. * configure: Regenerate. *

A RA patch necessary for new Intel insns generation

Hi, the following patch is necessary for generation of new Intel insns requiring 4 aligned zmm regs. Committed as rev. 242043. Index: ChangeLog === --- ChangeLog (revision 242040) +++ ChangeLog (working copy) @@ -1,3 +1,12 @@

[PATCH 1/2][AArch64] Add bfx attribute

Currently the SBFM, UBFM and BFM instructions all use the attribute "bfm". SBFM and UBFM include all shifts on AArch64, which are simpler than bitfield insert. Add a new bfx attribute for these instructions so that they can be modelled more accurately in the future. There is no difference in

gomp-nvptx branch status

Hello, I'd like to provide an overview of the gomp-nvptx branch status. In response to this message I'll send two more emails, with libgomp and middle-end changes on the branch. Some of the changes to libgomp such as build machinery adaptations have already received substantial comments in 2015,

[PATCH][AArch64] Tweak Cortex-A57 vector cost

The existing vector costs stop some beneficial vectorization. This is mostly due to vector statement cost being set to 3 as well as vector loads having a higher cost than scalar loads. This means that even when we vectorize 4x, it is possible that the cost of a vectorized loop is similar to

[committed] Bump fortran _OPENMP macro and openmp_version

Hi! I think it is better to announce 4.5 than 4.0 at the current state. Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk. 2016-11-10 Jakub Jelinek gcc/fortran/ * cpp.c (cpp_define_builtins): Define _OPENMP to 201511 instead of

[PATCH] Fix ICE in default_use_anchors_for_symbol_p (PR middle-end/78201)

Hi! On arm/aarch64 we ICE because some decls that make it here has non-NULL DECL_SIZE, which is a VAR_DECL rather than CONST_INT (or DECL_SIZE that doesn't fit into shwi would ICE similarly). While it is arguably a FE bug that it creates for VLA initialization from STRING_CST such a decl, I

Re: [C++ PATCH] Only warn with -Wc++1z-compat about mangling of visible symbols

OK. On Thu, Nov 10, 2016 at 8:52 AM, Jakub Jelinek wrote: > Hi! > > It seems -Wabi/-Wc++1z-compat warns about mangling changes even for symbols > that are > not visible outside of its TU (so likely only inline asm or tools > looking at .symtab STB_LOCAL symbols would notice).

[C++ PATCH] Only warn with -Wc++1z-compat about mangling of visible symbols

Hi! It seems -Wabi/-Wc++1z-compat warns about mangling changes even for symbols that are not visible outside of its TU (so likely only inline asm or tools looking at .symtab STB_LOCAL symbols would notice). Perhaps that is fine for -Wabi that isn't enabled in -Wall/-Wextra, but -Wc++1z-compat

Re: [PATCH, LIBGCC] Avoid count_leading_zeros with undefined result (PR 78067)

On Thu, 10 Nov 2016, James Greenhalgh wrote: > > On Wed, Nov 09, 2016 at 10:16:35PM +, Joseph Myers wrote: > > On Wed, 9 Nov 2016, Bernd Edlinger wrote: > > > > > Yes, but maybe introduce a test if the half-wide value fits? > > > > > > like: > > > > > > #define M_OK2(M, T) ((M) > sizeof(T) *

Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation

On 10/11/16 16:26, Segher Boessenkool wrote: Hi! Hi, Great to see this. Just a few comments... On Thu, Nov 10, 2016 at 02:25:47PM +, Kyrill Tkachov wrote: +/* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS. */ + +static sbitmap +aarch64_get_separate_components (void) +{ + /*

Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions

On Thu, Nov 10, 2016 at 07:27:00PM +0300, Andrew Senkevich wrote: > Hi, > > this patch enabled AVX512_4FMAPS and AVX512_4VNNIW instructions. > > It requires additional patch for register allocator from Vladimir > Makarov to be committed before. Your MUA ate tabs (and in the ChangeLog you're

[PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions

Hi, this patch enabled AVX512_4FMAPS and AVX512_4VNNIW instructions. It requires additional patch for register allocator from Vladimir Makarov to be committed before. gcc/ * common/config/i386/i386-common.c (OPTION_MASK_ISA_AVX5124FMAPS_SET,

Re: [PATCH][AArch64] Separate shrink wrapping hooks implementation

Hi! Great to see this. Just a few comments... On Thu, Nov 10, 2016 at 02:25:47PM +, Kyrill Tkachov wrote: > +/* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS. */ > + > +static sbitmap > +aarch64_get_separate_components (void) > +{ > + /* Calls to alloca further extend the stack

Re: [PATCH] Introduce -fprofile-update=maybe-atomic

On 11/10/2016 05:17 PM, David Edelsohn wrote: > Maybe instead of adding "maybe", we need to change the severity of the > warning so that the warning is not emitted by default. Adding the warning option to -Wextra can be solution. Is it acceptable approach? Martin

Re: [PATCH] Introduce -fprofile-update=maybe-atomic

On 11/10/2016 07:55 AM, David Edelsohn wrote: gcc.c now imposes profile-update=atomic if -pthread is used, even if the target does not support profile-update=atomic. ah, that's where this is coming from. nathan -- Nathan Sidwell

Re: [PATCH] Introduce -fprofile-update=maybe-atomic

On Thu, Nov 10, 2016 at 10:58 AM, Martin Liška wrote: > On 11/10/2016 04:43 PM, Nathan Sidwell wrote: >> On 11/10/2016 05:19 AM, Martin Liška wrote: >> On 10/13/2016 05:34 PM, Martin Liška wrote: > Hello. > > As it's very hard to guess from GCC driver whether a

Re: [PATCH] Introduce -fprofile-update=maybe-atomic

On Thu, Nov 10, 2016 at 11:14 AM, Nathan Sidwell wrote: > On 11/10/2016 07:43 AM, Nathan Sidwell wrote: >> >> On 11/10/2016 05:19 AM, Martin Liška wrote: >> On 10/13/2016 05:34 PM, Martin Liška wrote: > > Hello. > > As it's very hard to guess from GCC driver

Re: [PATCH] Introduce -fprofile-update=maybe-atomic

On 11/10/2016 07:43 AM, Nathan Sidwell wrote: On 11/10/2016 05:19 AM, Martin Liška wrote: On 10/13/2016 05:34 PM, Martin Liška wrote: Hello. As it's very hard to guess from GCC driver whether a target supports atomic updates for GCOV counter or not, I decided to come up with a new option

Re: [PATCH], PowerPC ISA 3.0, allow QImode/HImode to go into vector registers

Hi Mike, > I have built the spec 2006 CPU benchmark suite with these changes, and the > power8 (ISA 2.07) code generation does not change. Very good to hear :-) Just some nits; okay for trunk with that fixed: > +(define_split > + [(set (match_operand:EXTHI 0 "altivec_register_operand" "") > +

Re: [PATCH] Introduce -fprofile-update=maybe-atomic

On 11/10/2016 04:43 PM, Nathan Sidwell wrote: > On 11/10/2016 05:19 AM, Martin Liška wrote: > >>> On 10/13/2016 05:34 PM, Martin Liška wrote: Hello. As it's very hard to guess from GCC driver whether a target supports atomic updates for GCOV counter or not, I decided to

Re: [PATCH, LIBGCC] Avoid count_leading_zeros with undefined result (PR 78067)

On Wed, Nov 09, 2016 at 10:16:35PM +, Joseph Myers wrote: > On Wed, 9 Nov 2016, Bernd Edlinger wrote: > > > Yes, but maybe introduce a test if the half-wide value fits? > > > > like: > > > > #define M_OK2(M, T) ((M) > sizeof(T) * CHAR_BIT / 2 - 1) > > Something like that. In patch form, that

Re: [PATCH] Introduce -fprofile-update=maybe-atomic

On Thu, Nov 10, 2016 at 10:43 AM, Nathan Sidwell wrote: > On 11/10/2016 05:19 AM, Martin Liška wrote: > >>> On 10/13/2016 05:34 PM, Martin Liška wrote: Hello. As it's very hard to guess from GCC driver whether a target supports atomic updates for GCOV

Re: Fix compilation errors with libstdc++v3 for AVR target and allow --enable-libstdcxx

On Thu, Nov 10, 2016 at 1:39 PM, Felipe Magno de Almeida wrote: > Hello, > > Sorry for top-posting, but this is a ping for the attached patch. > > The patch doesn't seem to have been applied nor refused. So I'm > pinging to see if I need to change something? I already

Re: [PATCH] Introduce -fprofile-update=maybe-atomic

On 11/10/2016 05:19 AM, Martin Liška wrote: On 10/13/2016 05:34 PM, Martin Liška wrote: Hello. As it's very hard to guess from GCC driver whether a target supports atomic updates for GCOV counter or not, I decided to come up with a new option value (maybe-atomic), that would be transformed

Re: Fix compilation errors with libstdc++v3 for AVR target and allow --enable-libstdcxx

Hello, Sorry for top-posting, but this is a ping for the attached patch. The patch doesn't seem to have been applied nor refused. So I'm pinging to see if I need to change something? I already have a copyright assignment now. I'm attaching a updated patch that doesn't conflict in the Changelog

[PATCH] Support no newline in print_gimple_stmt

I've just noticed that tree-ssa-dse wrongly prints a new line to dump file. For the next stage1, I'll go through usages of print_gimple_stmt and remove extra new lines like: gcc/auto-profile.c: print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM); gcc/auto-profile.c- fprintf (dump_file,

Unreviewed libstdc++ patch

The libstdc++ part of the following patch [fixincludes, v3] Don't define libstdc++-internal macros in Solaris 10+ https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00330.html has remained unreviewed for a week. Bruce already approved the fixincludes part. In the meantime, full

[PATCH][ARM] PR78255: wrong code generation for indirect sibling calls

Hi, As reported in PR78255 there is currently an issue with indirect sibling calls in ARM when the address of the sibling call is loaded into 'r3' and that same register is chosen to align the stack. See the report for further information. As I mentioned in the bugzilla ticket I am not sure

Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

Hi Dominique. snip > I have a last glitch (which can be deferred if needed): snip Fixed by the new patch, which is attached. Bootstraps and regtests OK. OK for trunk? Paul 2016-11-10 Paul Thomas PR fortran/44265 * gfortran.h : Add fn_result_spec

[PATCH][AArch64] Separate shrink wrapping hooks implementation

Hi all, This patch implements the new separate shrink-wrapping hooks for aarch64. In separate shrink wrapping (as I understand it) we consider each register save/restore as a 'component' that can be performed independently of the other save/restores in the prologue/epilogue and can be moved

Re: [PATCH] Fix PR78189

On 10 November 2016 at 09:34, Richard Biener wrote: > On Wed, 9 Nov 2016, Christophe Lyon wrote: > >> On 9 November 2016 at 09:36, Bin.Cheng wrote: >> > On Tue, Nov 8, 2016 at 9:11 AM, Richard Biener wrote: >> >> On Mon, 7 Nov 2016,

Re: [ARM] PR 78253 do not resolve weak ref locally

On 10 November 2016 at 11:05, Richard Earnshaw wrote: > On 09/11/16 21:29, Christophe Lyon wrote: >> Hi, >> >> PR 78253 shows that the handling of weak references has changed for >> ARM with gcc-5. >> >> When r220674 was committed, default_binds_local_p_2 gained a

Re: [Patch, Fortran, committed] PR 46459: ICE (segfault): Invalid read in compare_actual_formal [error recovery]

Hi Andre, > well, is it really that obvious? well ... what can I say. If you wanna be strict about it, I guess there is no such thing as an "obvious patch". There is basically always something that you can miss, or that can be improved. Mikael's patch was obvious to me in the sense that it is

[PATCH] Fix PR71762

The following fixes PR71762 via reverting the transforms of ~X & Y to X < Y and similar because when the bools they apply to are expanded to RTL undefined values are not reliably zero-extended and thus the transform is invalid. Ensuring the zero-extension is too costly IMHO and the proper fix is

Re: [ipa-vrp] ice in set_value_range

Kugan Is there a PR for this failure? It broke bootstrap on AIX as well and I only was able to track it to your patch last night. Thanks, David

Re: [PATCH] Introduce -fprofile-update=maybe-atomic

PING^2 On 10/31/2016 10:13 AM, Martin Liška wrote: > PING^1 > > On 10/13/2016 05:34 PM, Martin Liška wrote: >> Hello. >> >> As it's very hard to guess from GCC driver whether a target supports atomic >> updates >> for GCOV counter or not, I decided to come up with a new option value >>

Re: [PATCH] have __builtin_object_size handle POINTER_PLUS with non-const offset (pr 77608)

On Tue, Nov 8, 2016 at 5:03 AM, Martin Sebor wrote: > It's taken me longer than I expected to finally get back to this > project. Sorry about the delay. > > https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01110.html > > Attached is an updated patch with this enhancement and

[PATCH] Fix print_node for CONSTRUCTORs

Hello. Following patch fixes indentation of print_node when printing a constructor that has some equal elements. Current implementation caches tree to prevent deep debug outputs. Such behavior is undesired for ctor elements. Apart from that, I switch to hash_set for a table that is used for tree

Re: RFA: PATCH to gengtype to avoid putting tree_node support in front end objects

On Thu, Oct 27, 2016 at 09:36:09AM -0400, Jason Merrill wrote: > Currently, the way gengtype works it scans the list of source files > with front end files at the end, and pushes data structures onto a > stack. It then processes the stack in LIFO order, so that data > structures from front ends

Re: [PATCH] DWARF: make signedness explicit for enumerator const values

On Thu, 2016-10-13 at 18:12 +0200, Pierre-Marie de Rodat wrote: > Currently, the DWARF description does not specify the signedness of the > representation of enumeration types. This is a problem in some > contexts where DWARF consumers need to determine if value X is greater > than value Y. > >

Re: [PATCH, vec-tails] Support loop epilogue vectorization

On Thu, 10 Nov 2016, Richard Biener wrote: > On Tue, 8 Nov 2016, Yuri Rumyantsev wrote: > > > Richard, > > > > Here is updated 3 patch. > > > > I checked that all new tests related to epilogue vectorization passed with > > it. > > > > Your comments will be appreciated. > > A lot better now.

Re: [PATCH, vec-tails] Support loop epilogue vectorization

On Tue, 8 Nov 2016, Yuri Rumyantsev wrote: > Richard, > > Here is updated 3 patch. > > I checked that all new tests related to epilogue vectorization passed with it. > > Your comments will be appreciated. A lot better now. Instead of the ->aux dance I now prefer to pass the original loops

Re: [PATCH] libiberty: Add Rust symbol demangling.

On Thu, 2016-11-03 at 18:39 +0100, Mark Wielaard wrote: > Adds Rust symbol demangler. Rust mangles symbols using GNU_V3 style, > adding a hash and various special character subtitutions. This adds > a new rust style to cplus_demangle and adds 3 helper functions > rust_demangle, rust_demangle_sym

Patch ping: Fix dwarf2out related bootstrap failure on Solaris (PR debug/78191)

On Thu, Nov 03, 2016 at 05:42:51PM +0100, Jakub Jelinek wrote: > Bootstrapped/regtested on x86_64-linux and i686-linux and Rainer has kindly > tested it on Solaris, ok for trunk? > > 2016-11-03 Jakub Jelinek > > * dwarf2out.c (size_of_discr_list): Fix typo in function

Re: [PATCH] Remove unneeded gcc_assert in gimplifier (PR sanitizer/78270)

On Thu, Nov 10, 2016 at 12:02:45PM +0100, Martin Liška wrote: > >From fb4b852a17656309e6acfb8da97cf9bce4b3b176 Mon Sep 17 00:00:00 2001 > From: marxin > Date: Wed, 9 Nov 2016 11:52:00 +0100 > Subject: [PATCH] Create live_switch_vars conditionally (PR sanitizer/78270) > >

Re: [PATCH] debug/PR78112: remove recent duplicates for DW_TAG_subprogram attributes

On 11/09/2016 10:02 AM, Richard Biener wrote: Using scan-assembler-times on the dwarf? I always have a bad feeling about this kind of check as I imagine it can break very easily with legit changes. But I have nothing better to contribute, so I’ve added one such testcase. ;-) Ok to commit?

[PATCH] [ARC] New option handling, refurbish multilib support.

Hi, Please find the revised patch which includes the refurbishing of mmpy-option option, and a new comment on DEFAULT_arc_fpu_build define. As for the last suggestion, my proposal is to have a latter patch on the topic of .cpu, synced with a related binutils patch. OK to apply? Claudiu gcc/

Re: [PATCH] Remove unneeded gcc_assert in gimplifier (PR sanitizer/78270)

On 11/09/2016 02:47 PM, Martin Liška wrote: > On 11/09/2016 02:29 PM, Jakub Jelinek wrote: >> On Wed, Nov 09, 2016 at 02:16:45PM +0100, Martin Liška wrote: >>> As shown in the attached test-case, the assert cannot always be true. >>> Patch can bootstrap on ppc64le-redhat-linux and survives

Re: [PATCH] loop distribution bug fix

On Thu, Nov 10, 2016 at 6:25 AM, Jim Wilson wrote: > This fixes a bug in code adding edges to the dependence graph. Values > for this_dir can be -1 (backward edge), 0 (no edge), 1 (forward edge), > and 2 (both backward and forward edges). There can be multiple >

[Patch 4/5] OpenACC tile clause support, Fortran front-end parts

The Fortran front-end patches. These were originally written by Cesar. Thanks, Chung-Lin 2016-XX-XX Cesar Philippidis fortran/ * openmp.c (resolve_oacc_positive_int_expr): Promote the warning to an error. (resolve_oacc_loop_blocks): Use

[Patch 5/5] OpenACC tile clause support, libgomp testsuite patches

Some additional tests and adjustments to existing ones were made. 2016-XX-XX Nathan Sidwell Chung-Lin Tang libgomp/ * testsuite/libgomp.oacc-c-c++-common/tile-1.c: New. *

[Patch 3/5] OpenACC tile clause support, C/C++ front-end parts

These are the patches for the C/C++ front-ends, along with the testsuite patches. Thanks, Chung-Lin 2016-XX-XX Nathan Sidwell c/ * c-parser.c (c_parser_omp_clause_collapse): Disallow tile. (c_parser_oacc_clause_tile): Disallow collapse. Fix

  1   2   >