Re: [PATCH 2/3] Run profile feedback tests with autofdo

> >But it's not expected that it is not deterministic, so that it changes > >run to run. Do you see that? Or some other problem? Please describe > >it exactly. > It definitely changes run to run for me. And do you have autofdo installed? (create_gcov) -Andi

Re: [PATCH 2/3] Run profile feedback tests with autofdo

On 07/25/2016 10:21 PM, Andi Kleen wrote: On Mon, Jul 25, 2016 at 01:08:43PM +0200, Martin Liška wrote: On 07/15/2016 10:37 AM, Bin.Cheng wrote: On Thu, Jul 14, 2016 at 11:33 PM, Andi Kleen wrote: I haven't seen that. Unstable in what way? For GCC doesn't support FDO,

Re: [PATCH 2/3] Run profile feedback tests with autofdo

On Mon, Jul 25, 2016 at 01:08:43PM +0200, Martin Liška wrote: > On 07/15/2016 10:37 AM, Bin.Cheng wrote: > > On Thu, Jul 14, 2016 at 11:33 PM, Andi Kleen wrote: > > I haven't seen that. Unstable in what way? > For GCC doesn't support FDO, it run below tests as you

[Bug tree-optimization] Fix for PR71994

Hi, For testcase in pr71994, type of bb conditional result and the type of the PHI stmt are different (as om.0_1 is int and the first PHI argument is _bool; PHI stmt uses a constant zero that comes from edge 2). Therefore when we optimize final range test stmt, we end up setting integer 1

Re: [PATCH] Teach VRP to register assertions along default switch labels (PR 18046)

On Mon, Jul 25, 2016 at 6:00 AM, Richard Biener wrote: > On Mon, Jul 25, 2016 at 5:38 AM, Patrick Palka wrote: >> On Fri, 22 Jul 2016, Patrick Palka wrote: >> >>> On Fri, 22 Jul 2016, Patrick Palka wrote: >>> >>> > On Fri, 22 Jul 2016, Patrick

Re: Init df for split pass since some target use REG_NOTE in split pattern

Hi Jeff: Oop, patch in attachment, and I hit this bug in gcc.dg/torture/vshuf-v2di.c with our nds32 internal branch. Hi Richard: I think we really need reg dead note for some optimization, and btw, here is our split pattern: (define_split [(set (match_operand:DI 0

Re: [PATCH 1/6] add auto_sbitmap class

On Mon, Jul 25, 2016 at 09:30:07AM -0600, Jeff Law wrote: > On 07/24/2016 10:28 AM, Richard Biener wrote: > > On July 24, 2016 1:44:44 PM GMT+02:00, tbsaunde+...@tbsaunde.org wrote: > > > From: Trevor Saunders > > > > > > gcc/ChangeLog: > > > > > > 2016-07-24 Trevor

Re: libgo patch committed: Update to 1.7rc3

On Mon, Jul 25, 2016 at 8:57 AM, Lynn A. Boger wrote: > libgo version bump to indicate the change in Go version? Thanks for the reminder. Done with the appended patch. Ian Index: gcc/go/gofrontend/MERGE

Re: [PATCH 2/6] use auto_sbitmap in various places

On Mon, Jul 25, 2016 at 11:18:07AM -0600, Jeff Law wrote: > On 07/24/2016 05:44 AM, tbsaunde+...@tbsaunde.org wrote: > > From: Trevor Saunders > > > > gcc/ChangeLog: > > > > 2016-07-24 Trevor Saunders > > > > * bt-load.c

Re: libgo patch committed: Update to 1.7rc3

On Mon, Jul 25, 2016 at 8:11 AM, Rainer Orth wrote: > >> I have committed a patch to update libgo to the 1.7rc3 release >> candidate. This is very close to the upcoming 1.7 release. As usual >> with libgo updates, the patch is too large to include in this e-mail

Re: [PATCH, rs6000] Correct effective target in gcc.target/powerpc/pr63354.c

On Mon, Jul 25, 2016 at 03:29:55PM -0500, Bill Schmidt wrote: > The subject test case uses the -mprofile-kernel option, which is not > permitted in 32-bit mode. It currently restricts the effective target > to powerpc64, which is not sufficient when using -m32 on 64-bit hardware. > This patch

warn on dead function calls [2/4] libsupc++/eh_alloc.cc fallout

Many warnings for dead-calls are emitted with patch on call to operator new in libsupc++/eh_alloc.cc, which I am not sure are correct or false positives, for instance: /home/prathamesh.kulkarni/gcc-svn/trunk/libstdc++-v3/libsupc++/eh_alloc.cc:170:22: warning: Call from void*

warn for dead function calls [4/4] stor-layout.c fallout

The following is an interesting case which broke stor-layout.c. The patch warned for the following call to be dead from bit_field_mode_iterator::next_mode() to get_mode_alignment (): /* Stop if the mode requires too much alignment. */ if (GET_MODE_ALIGNMENT (m_mode) > m_align

[RFC] warn on dead function calls in ipa-pure-const [1/4]

Hi, The attached patch emits warnings for functions found to be pure or const by the ipa-pure-const pass. It does not warn for functions with unused return values that have been declared as pure or const by the user since this is already handled in C and C++ FE's. I have split it into parts to

warn for dead function calls [3/4] testsuite fallout

Hi, The following test-cases broke due to the warning. I think however the warning is right for all the cases: a) g++.dg/tree-ssa/invalid-dom.C: I believe the call from main() to E::bar() is dead call ? b) libffi/testsuite/libffi.call/float.c: Call from main() to floating() is dead call. c)

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

On 25 July 2016 at 18:18, ayush goel wrote: > On top of the previously filed patch for importing gnulib (the link > isn’t available on the archive yet, however this contains some of the > information: >

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

On 07/25/2016 12:32 PM, Richard Biener wrote: On July 25, 2016 8:01:17 PM GMT+02:00, Jeff Law wrote: On 07/22/2016 05:36 AM, Richard Biener wrote: The thing that needs work I think is re-running of if-conversion. I wonder if we could revamp if-conversion to work on a subset

Re: Gimple loop splitting v2

On Wed, Dec 2, 2015 at 5:23 AM, Michael Matz wrote: > Hi, > > On Tue, 1 Dec 2015, Jeff Law wrote: > >> > So, okay for trunk? >> -ENOPATCH > > Sigh :) > Here it is. I found one problem with it. Take: void f(int *a, int M, int *b) { for(int i = 0; i <= M; i++) { if (i <

[PATCH, rs6000] Correct effective target in gcc.target/powerpc/pr63354.c

Hi, The subject test case uses the -mprofile-kernel option, which is not permitted in 32-bit mode. It currently restricts the effective target to powerpc64, which is not sufficient when using -m32 on 64-bit hardware. This patch changes the effective target restriction to lp64 to correct this.

[PATCH] Remove dead call to gimple_bb in slsr_process_phi

Hi, As reported on the gcc mailing list, slsr_process_phi contains a dead call to gimple_bb. I looked into why this wasn't noticed before, and concluded that we don't actually need the call. To reach this point, the phi argument must not correspond to a strength-reduction candidate in the

Re: Init df for split pass since some target use REG_NOTE in split pattern

On 07/25/2016 12:35 PM, Richard Biener wrote: On July 25, 2016 5:56:29 PM GMT+02:00, Jeff Law wrote: On 07/25/2016 12:36 AM, Kito Cheng wrote: Hi all: Some target(for example i386, sh and h8300) use find_regno_note in split pattern but df infrastructure seem not initialize

[committed] Fix selftest::temp_source_file ctor

Temporary source files created by the selftests weren't generated correctly if they contained a "%" character (seen whilst writing selftests for the locations-within-string-literals patch I'm working on). Root cause was a buggy fprintf in the selftest::temp_source_file ctor. Fixed thusly.

C++ PATCH for c++/71837 (pack expansion in init-capture)

This useless testcase uses a pack expansion as the parenthesized initializer for an init-capture, which is only valid when the parameter pack has a single argument. This patch avoids an ICE by leaving the TREE_LIST around the pack expansion and dealing with it at substitution time. Tested

C++ PATCH for c++/71833 (member template with two template parameter packs)

My patch for 54440 coerce_template_parameter_pack mysteriously assumed that the index of the first argument we want to pack into the trailing pack somehow matched the index of the parameter pack in the parameter list. I don't know what I was thinking. Tested x86_64-pc-linux-gnu, applying to

Re: Init df for split pass since some target use REG_NOTE in split pattern

On July 25, 2016 5:56:29 PM GMT+02:00, Jeff Law wrote: >On 07/25/2016 12:36 AM, Kito Cheng wrote: >> Hi all: >> >> Some target(for example i386, sh and h8300) use find_regno_note in >> split pattern but df infrastructure seem not initialize at split >pass, >> so it may got wrong

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

On July 25, 2016 8:01:17 PM GMT+02:00, Jeff Law wrote: >On 07/22/2016 05:36 AM, Richard Biener wrote: >> The thing that needs work I think is re-running of if-conversion. >I wonder if we could revamp if-conversion to work on a subset of the >CFG? I can see that potentially

C++ PATCH for c++/65970 (constexpr infinite loop)

An infinite loop in a constexpr function led to a compiler hang. Fixed by putting an upper bound on loop iterations in constexpr evaluation. Tested x86_64-pc-linux-gnu, applying to trunk. commit 6c93c22a799e5ea5e1cdfe661476cf123ed1a4e8 Author: Jason Merrill Date: Mon Jul 25

C++ PATCH for c++/71972 (ICE with constexpr array element self-modification)

Here, when we start to modify an array element, we add a constructor_elt for it to the CONSTRUCTOR. When calculating the value to store there we found this empty element and tried to use it, leading to an ICE because it was NULL. Tested x86_64-pc-linux-gnu, applying to trunk. commit

Re: GCC testsuite maintenance (was: [PATCH] Fix OpenACC vector_length parsing in fortran)

On Jul 25, 2016, at 9:37 AM, Joseph Myers wrote: > > On Fri, 15 Jul 2016, Thomas Schwinge wrote: > >>> No, we want to have as little churn as possible in existing tests, the >>> general policy is to add new tests (not just for OpenACC/OpenMP, but for >>> all

Re: C++ PATCH for c++/71913 (copy elision choices)

On Mon, Jul 25, 2016 at 7:15 AM, Renlin Li wrote: > Hi Jason, > > On 22/07/16 04:01, Jason Merrill wrote: >> >> 71913 is a case where unsafe_copy_elision_p was being too >> conservative. We can allow copy elision in a new expression; the only >> way we could end up

Re: [PATCH] correct atomic_compare_exchange_n return type (c++/71675)

On Mon, Jul 25, 2016 at 1:56 PM, Jeff Law wrote: > On 07/25/2016 05:03 AM, Renlin Li wrote: >> >> Hi Martin, >> >> I observed the following error: >> >> ERROR: gcc.dg/atomic/pr71675.c -O2 -flto -fuse-linker-plugin >> -fno-fat-lto-objects : syntax error in target selector

Re: [PATCH, vec-tails 07/10] Support loop epilogue combining

On 07/22/2016 05:36 AM, Richard Biener wrote: The thing that needs work I think is re-running of if-conversion. I wonder if we could revamp if-conversion to work on a subset of the CFG? I can see that potentially being useful in other contexts. Would that work for you Richi? We've already

Re: [PATCH] correct atomic_compare_exchange_n return type (c++/71675)

On 07/25/2016 05:03 AM, Renlin Li wrote: Hi Martin, I observed the following error: ERROR: gcc.dg/atomic/pr71675.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects : syntax error in target selector "target c11" for " dg-do 3 compile { target c11 } " It seems we don't have a c11 effective

Re: [PATCH] predict.c: merge multi-edges

On 07/22/2016 05:38 AM, Martin Liška wrote: On 07/22/2016 12:53 PM, Segher Boessenkool wrote: Hi Martin, On Fri, Jul 22, 2016 at 10:17:51AM +0200, Martin Liška wrote: /* We can not predict the probabilities of outgoing edges of bb. Set them - evenly and hope for the best. */ + evenly

Re: [PATCH] Replacing gcc's dependence on libiberty's md5 to gnulib's md5

Link for the patch importing gnulib inside gcc’s tree: https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html Apologies for the confusion -Ayush On 25 July 2016 at 10:52:00 PM, ayush goel (ayushgoel1...@gmail.com) wrote: > On top of the previously filed patch for importing gnulib (the link

Re: [PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

The link for that patch importing gnulib inside gcc’s tree: https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html Apologies for the confusion. On 25 July 2016 at 10:48:20 PM, ayush goel (ayushgoel1...@gmail.com) wrote: > > On top of the previously filed patch for importing gnulib (the link

Re: [C PATCH] Don't mark C99 inline functions as always_inline (PR c/71969)

On 07/23/2016 10:38 AM, Richard Biener wrote: On July 22, 2016 5:09:07 PM GMT+02:00, Jakub Jelinek wrote: Hi! As Richard reported on IRC, we are marking C99 inline (without extern) functions as effectively always_inline, even when the intent has been to do this only for the

[PATCH] Replacing gcc's dependence on libiberty's md5 to gnulib's md5

On top of the previously filed patch for importing gnulib (the link isn’t available on the archive yet, however this contains some of the information: http://gcc.1065356.n5.nabble.com/Importing-gnulib-into-the-gcc-tree-td1275807.html#a1279573) now I have replaced another function from libiberty

Re: [PATCH] Invalidate argument slots for const/pure calls

On 07/23/2016 12:32 PM, John David Anglin wrote: The attached patch fixes PR middle-end/71712. We need to invalidate the argument slots in const/pure calls as they are owned by the callee. The caller can't assume they are preserved across the call. Fix is similar to that for PR71532.

[PATCH] Replacing gcc's dependence on libiberty's fnmatch to gnulib's fnmatch

On top of the previously filed patch for importing gnulib (the link isn’t available on the archive yet, however this contains some of the information: http://gcc.1065356.n5.nabble.com/Importing-gnulib-into-the-gcc-tree-td1275807.html#a1279573) now I have replaced another function from libiberty

Re: [PATCH 2/6] use auto_sbitmap in various places

On 07/24/2016 05:44 AM, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2016-07-24 Trevor Saunders * bt-load.c (compute_out): Use auto_sbitmap class. (link_btr_uses): Likewise. * cfganal.c

Re: [Patch, testuite, committed] Fix some more tests that fail for non 32-bit int targets

On Jul 25, 2016, at 5:00 AM, Senthil Kumar Selvaraj wrote: > > The below patch fixes tests that fail for the avr target, because they > assume ints are atleast 32 bits wide and pointers and longs have the > same size. > > I've required int32plus support

Re: [PR70920] transform (intptr_t) x eq/ne CST to x eq/ne (typeof x) cst

On 25 July 2016 at 14:32, Richard Biener wrote: > On Mon, 25 Jul 2016, Prathamesh Kulkarni wrote: > >> Hi Richard, >> The attached patch tries to fix PR70920. >> It adds your pattern from comment 1 in the PR >> (with additional gating on INTEGRAL_TYPE_P to avoid regressing >>

Re: GCC testsuite maintenance (was: [PATCH] Fix OpenACC vector_length parsing in fortran)

On Fri, 15 Jul 2016, Thomas Schwinge wrote: > > No, we want to have as little churn as possible in existing tests, the > > general policy is to add new tests (not just for OpenACC/OpenMP, but for > > all functionality). > > Hmm, that's something I had not been aware of, and I can't find this >

[committed] testsuite: add two more label_values annotations

Hi, I've applied the following patch as obvious to mark two more tests as taking addresses of labels (this cannot work on nvptx). The issue on pr16973.c was uncovered in the fallout of my (now reverted) toplevel-reorder patch; the other test, pr71494.c, fails regardless of that. 2016-07-25

Re: libgo patch committed: Update to 1.7rc3

libgo version bump to indicate the change in Go version? On 07/22/2016 01:15 PM, Ian Lance Taylor wrote: I have committed a patch to update libgo to the 1.7rc3 release candidate. This is very close to the upcoming 1.7 release. As usual with libgo updates, the patch is too large to include in

Re: Init df for split pass since some target use REG_NOTE in split pattern

On 07/25/2016 12:36 AM, Kito Cheng wrote: Hi all: Some target(for example i386, sh and h8300) use find_regno_note in split pattern but df infrastructure seem not initialize at split pass, so it may got wrong note since it's out-of-date. ChangeLog 2016-07-25 Kito Cheng

Re: [PATCH] Teach VRP to register assertions along default switch labels (PR 18046)

On 07/24/2016 11:56 AM, Andrew Pinski wrote: On Sun, Jul 24, 2016 at 9:49 AM, Patrick Palka wrote: On Sat, Jul 23, 2016 at 9:13 PM, kugan wrote: On 23/07/16 05:26, Patrick Palka wrote: This patch teaches VRP to register along a

Re: [patch] Get rid of stack trampolines for nested functions

On 07/25/2016 06:56 AM, Eric Botcazou wrote: Another UNITS_PER_WORD that I think ought to be POINTER_SIZE/BITS_PER_UNIT. Probably worth a pass over the patch to look for this throughout. Yes, it was very likely enabled only on platforms with word-sized pointers. That's what I suspected.

Re: [PATCH 1/6] add auto_sbitmap class

On 07/24/2016 10:28 AM, Richard Biener wrote: On July 24, 2016 1:44:44 PM GMT+02:00, tbsaunde+...@tbsaunde.org wrote: From: Trevor Saunders gcc/ChangeLog: 2016-07-24 Trevor Saunders * sbitmap.h (auto_sbitmap): New class. OK.

Re: libgo patch committed: Update to 1.7rc3

Hi Ian, > I have committed a patch to update libgo to the 1.7rc3 release > candidate. This is very close to the upcoming 1.7 release. As usual > with libgo updates, the patch is too large to include in this e-mail > message. I've appended the changes to the gccgo-specific directories. this

Re: Gimple loop splitting

Hi, On Sun, 24 Jul 2016, Andrew Pinski wrote: > What ever happened to this patch? It got accepted but I deferred inclusion in GCC 6 because it was late in the cycle then and performance results didn't show super improvements (only looked at cpu2006). No regressions, but no nice speedups

[PR71078] x / abs(x) -> copysign (1.0, x)

Hi, The attached patch tries to fix PR71078. I am not sure if I have got the converts right. I put (convert? @0) and (convert1? (abs @1)) to match for cases when operands's types may be different from outermost type like in pr71078-3.c test-case (included in patch). Bootstrap+test in progress on

Re: [patch] Get rid of stack trampolines for nested functions

> So does this require that every function have an 8-byte alignment > boundary? or just those that appear in nested functions? If the > former, how do you get routines written in assembler, or produced by > third-party compilers, to comply? The former. You need to be able to control what

[PATCH] do not take mutex in _Unwind_Find_registered_FDE if there is no registered objects

_Unwind_Find_FDE calls _Unwind_Find_registered_FDE and it takes lock even when there is no registered objects. As far as I see only statically linked applications call __register_frame_info* functions, so for dynamically linked executables taking the lock to check unseen_objects and seen_objects

Re: [patch] Get rid of stack trampolines for nested functions

On 25/07/16 14:25, Eric Botcazou wrote: >> If I understand how this is supposed to work then this is not >> future-proof against changes to the architecture. The bottom two bits >> in both AArch32 (arm) and AArch64 are reserved for future use by the >> architecture; they must not be used by

[PATCH 7/7, GCC, ARM, V8M] Added support for ARMV8-M Security Extension cmse_nonsecure_caller intrinsic

This patch adds support ARMv8-M's Security Extension's cmse_nonsecure_caller intrinsic. This intrinsic is used to check whether an entry function was called from a non-secure state. See Section 5.4.3 of ARM®v8-M Security Extensions: Requirements on Development Tools

Re: [patch] Get rid of stack trampolines for nested functions

> If I understand how this is supposed to work then this is not > future-proof against changes to the architecture. The bottom two bits > in both AArch32 (arm) and AArch64 are reserved for future use by the > architecture; they must not be used by software for tricks like this. I see, thanks for

[PATCH 6/7, GCC, ARM, V8M] ARMv8-M Security Extension's cmse_nonsecure_call: use __gnu_cmse_nonsecure_call

This patch extends support for the ARMv8-M Security Extensions 'cmse_nonsecure_call' to use a new library function '__gnu_cmse_nonsecure_call'. This library function is responsible for (without using r0-r3 or d0-d7): 1) saving and clearing all callee-saved registers using the secure stack 2)

[PATCH 5/7, GCC, ARM, V8M] Handling ARMv8-M Security Extension's cmse_nonsecure_call attribute

This patch adds support for the ARMv8-M Security Extensions 'cmse_nonsecure_call' attribute. This attribute may only be used for function types and when used in combination with the '-mcmse' compilation flag. See Section 5.5 of ARM®v8-M Security Extensions

[PATCH 4/7, GCC, ARM, V8M] ARMv8-M Security Extension's cmse_nonsecure_entry: clear registers

This patch extends support for the ARMv8-M Security Extensions 'cmse_nonsecure_entry' attribute to safeguard against leak of information through unbanked registers. When returning from a nonsecure entry function we clear all caller-saved registers that are not used to pass return values, by

[PATCH 3/7, GCC, ARM, V8M] ARMv8-M Security Extension's cmse_nonsecure_entry: __acle_se label and bxns return

This patch extends support for the ARMv8-M Security Extensions 'cmse_nonsecure_entry' attribute in two ways: 1) Generate two labels for the function, the regular function name and one with the function's name appended to '__acle_se_', this will trigger the linker to create a secure gateway veneer

[PATCH] Fix PR71984

The following should fix PR71984 which stems from a bogus (but harmless for CONCAT) use of GET_MODE_UNIT_SIZE vs. GET_MODE_SIZE (where the former is really really badly named...). In the process of fixing it I also hardened it against VOIDmode which might have occured for CONCAT as well given we

[PATCH 2/7, GCC, ARM, V8M] Handling ARMv8-M Security Extension's cmse_nonsecure_entry attribute

This patch adds support for the ARMv8-M Security Extensions 'cmse_nonsecure_entry' attribute. In this patch we implement the attribute handling and diagnosis around the attribute. See Section 5.4 of ARM®v8-M Security Extensions

[PATCH 1/7, GCC, ARM, V8M] Add support for ARMv8-M's Secure Extensions flag and intrinsics

This patch adds the support of the '-mcmse' option to enable ARMv8-M's Security Extensions and supports the following intrinsics: cmse_TT cmse_TT_fptr cmse_TTT cmse_TTT_fptr cmse_TTA cmse_TTA_fptr cmse_TTAT cmse_TTAT_fptr cmse_check_address_range cmse_check_pointed_object cmse_is_nsfptr

[PATCH 0/7, GCC, V8M] ARMv8-M Security Extensions

[PATCH 0/7, GCC, V8M] ARMv8-M Security Extensions Hello, This is a respin of a previous patch series for ARMv8-M Security Extensions. In this version I have removed one patch, rebased the rest and changed some of them. This patch series aims at implementing support for ARMv8-M's Security

Re: [AArch64][3/3] Migrate aarch64_expand_prologue/epilogue to aarch64_add_constant

On 25/07/16 10:34, Jiong Wang wrote: > On 21/07/16 11:08, Richard Earnshaw (lists) wrote: >> On 20/07/16 16:02, Jiong Wang wrote: >>> Richard, >>>Thanks for the review, yes, I believe using aarch64_add_constant is >>> unconditionally >>> safe here. Because we have generated a stack tie to

Re: [patch] Get rid of stack trampolines for nested functions

On 29/06/16 23:08, Eric Botcazou wrote: > Index: config/aarch64/aarch64.h > === > --- config/aarch64/aarch64.h (revision 237789) > +++ config/aarch64/aarch64.h (working copy) > @@ -779,6 +779,9 @@ typedef struct > correctly. */

Re: [patch] libstdc++: fix ext/rope::dump() bug

On 25/07/16 20:26 +0800, Georeth Chow wrote: Hello, maintainers. Recently, I tried to figure out how the rope container works by dumping the content. I found that the implementation of rope::dump() has a misspell bug which use a static member function as a enum value. It seems that the

Re: [patch] Get rid of stack trampolines for nested functions

> Should UNITS_PER_WORD here be POINTER_SIZE/BITS_PER_UNIT right? Hmm, yes, presumably, it's the size of the static chain and so a pointer. > Another UNITS_PER_WORD that I think ought to be > POINTER_SIZE/BITS_PER_UNIT. Probably worth a pass over the patch to > look for this throughout. Yes,

Re: [PATCH] nvptx: do not implicitly enable -ftoplevel-reorder

On Mon, 25 Jul 2016, Nathan Sidwell wrote: > On 07/22/16 11:19, Alexander Monakov wrote: > > > I hope I've satisfactorily explained the failures you've pointed out (thanks > > for the data). I think I should leave the choice of what to do next (revert > > the patch or leave it in and install

[patch] libstdc++: fix ext/rope::dump() bug

Hello, maintainers. Recently, I tried to figure out how the rope container works by dumping the content. I found that the implementation of rope::dump() has a misspell bug which use a static member function as a enum value. It seems that the original SGI STL implementation doesn't have this bug.

Re: [PATCH] Adapt the numbering scheme (PR gcov-profile/64874)

On 07/25/16 04:42, Martin Liška wrote: I like the change suggested by Jakub, I've updated the numbering scheme, as well as comments in gcov-io.h. ok. I'm not too fussed about a problem that is 25 years away and would result in contusion of code (then) instrumented 30 years ago. nathan

[Patch, testuite, committed] Fix some more tests that fail for non 32-bit int targets

Hi, The below patch fixes tests that fail for the avr target, because they assume ints are atleast 32 bits wide and pointers and longs have the same size. I've required int32plus support for one test, and for the other two, I've introduced a cast to intptr_t to avoid the pointer <->

Re: [PATCH] nvptx: do not implicitly enable -ftoplevel-reorder

On 07/22/16 11:19, Alexander Monakov wrote: I hope I've satisfactorily explained the failures you've pointed out (thanks for the data). I think I should leave the choice of what to do next (revert the patch or leave it in and install fixups where appropriate) up to you? Please revert the

[PATCH] Remove special streaming of builtins

So I needed to fix that builtins appearing in BLOCK_VARs and the solution I came up with accidentially disabled streaming via the special path. Thus the following patch removes the special-casing completely and makes the BLOCK_VARs handling work the same way as for regular externs (by streaming a

Re: [AArch64][0/14] ARMv8.2-A FP16 extension support

On Thu, Jul 07, 2016 at 05:12:48PM +0100, Jiong Wang wrote: > Hello, > > As a follow up of > > https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01240.html, > > This patch set adds ARMv8.2-A FP16 scalar and vector intrinsics support, > gcc middle-end will also be aware of some standard operations

Re: [PATCH] Don't call get_working_sets w/ LTO and -fauto-profile (PR, gcov-profile/70993)

On Mon, Jul 25, 2016 at 1:05 PM, Martin Liška wrote: > Hi. > > Currently, call to get_working_sets is only called from tree_profiling > (called from 'pass_ipa_tree_profile' and is guarded in gate with > !flag_auto_profile). > I would like to apply the same logic in lto-cgraph.c.

Re: [RFC][IPA-VRP] Early VRP Implementation

On Fri, Jul 22, 2016 at 2:10 PM, kugan wrote: > Hi Richard, > > Thanks for the review. > > On 18/07/16 21:51, Richard Biener wrote: >> >> On Fri, Jul 15, 2016 at 9:33 AM, kugan >> wrote: >>> >>> Hi Andrew, >>> >>> On 15/07/16

Re: [AArch64][10/14] ARMv8.2-A FP16 lane scalar intrinsics

On Thu, Jul 07, 2016 at 05:18:29PM +0100, Jiong Wang wrote: > This patch adds ARMv8.2-A FP16 lane scalar intrinsics. OK. Thanks, James > > gcc/ > 2016-07-07 Jiong Wang > > * config/aarch64/arm_neon.h (vfmah_lane_f16): New. > (vfmah_laneq_f16): Likewise. >

Re: [AArch64][9/14] ARMv8.2-A FP16 three operands scalar intrinsics

On Thu, Jul 07, 2016 at 05:18:15PM +0100, Jiong Wang wrote: > This patch add ARMv8.2-A FP16 three operands scalar intrinsics. OK. Thanks, James > gcc/ > 2016-07-07 Jiong Wang > > * config/aarch64/aarch64-simd-builtins.def: Register new builtins. > *

Re: C++ PATCH for c++/71913 (copy elision choices)

Hi Jason, On 22/07/16 04:01, Jason Merrill wrote: 71913 is a case where unsafe_copy_elision_p was being too conservative. We can allow copy elision in a new expression; the only way we could end up initializing a base subobject without knowing it would be through a placement new, in which case

Re: [AArch64][8/14] ARMv8.2-A FP16 two operands scalar intrinsics

On Wed, Jul 20, 2016 at 06:00:58PM +0100, Jiong Wang wrote: > On 07/07/16 17:17, Jiong Wang wrote: > >This patch add ARMv8.2-A FP16 two operands scalar intrinsics. > > The updated patch resolve the conflict with > >https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00309.html > > The change is

Re: [AArch64][7/14] ARMv8.2-A FP16 one operand scalar intrinsics

On Wed, Jul 20, 2016 at 06:00:53PM +0100, Jiong Wang wrote: > On 07/07/16 17:17, Jiong Wang wrote: > >This patch add ARMv8.2-A FP16 one operand scalar intrinsics > > > >Scalar intrinsics are kept in arm_fp16.h instead of arm_neon.h. > > The updated patch resolve the conflict with > >

Re: [PATCH 2/3] Run profile feedback tests with autofdo

On 07/15/2016 10:37 AM, Bin.Cheng wrote: > On Thu, Jul 14, 2016 at 11:33 PM, Andi Kleen wrote: > I haven't seen that. Unstable in what way? For GCC doesn't support FDO, it run below tests as you said: PASS: gcc.dg/tree-prof/20041218-1.c compilation, -g

Re: [AArch64][6/14] ARMv8.2-A FP16 reduction vector intrinsics

On Thu, Jul 07, 2016 at 05:16:58PM +0100, Jiong Wang wrote: > This patch add ARMv8.2-A FP16 reduction vector intrinsics. OK. Thanks, James > gcc/ > 2016-07-07 Jiong Wang > > * config/aarch64/arm_neon.h (vmaxv_f16): New. > (vmaxvq_f16): Likewise. >

Re: [AArch64][5/14] ARMv8.2-A FP16 lane vector intrinsics

On Thu, Jul 07, 2016 at 05:16:28PM +0100, Jiong Wang wrote: > This patch add ARMv8.2-A FP16 lane vector intrinsics. > > Lane intrinsics are generally derivatives of multiply intrinsics, > including multiply accumulate. All necessary backend support for them > are there already except fmulx, the

[PATCH] Don't call get_working_sets w/ LTO and -fauto-profile (PR, gcov-profile/70993)

Hi. Currently, call to get_working_sets is only called from tree_profiling (called from 'pass_ipa_tree_profile' and is guarded in gate with !flag_auto_profile). I would like to apply the same logic in lto-cgraph.c. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Re: [AArch64][4/14] ARMv8.2-A FP16 three operands vector intrinsics

On Thu, Jul 07, 2016 at 05:16:01PM +0100, Jiong Wang wrote: > This patch add ARMv8.2-A FP16 three operands vector intrinsics. > > Three operands intrinsics only contain fma and fms. OK. Thanks, James > > 2016-07-07 Jiong Wang > > gcc/ > *

Re: [AArch64][3/14] ARMv8.2-A FP16 two operands vector intrinsics

On Wed, Jul 20, 2016 at 06:00:46PM +0100, Jiong Wang wrote: > On 07/07/16 17:15, Jiong Wang wrote: > >This patch add ARMv8.2-A FP16 two operands vector intrinsics. > > The updated patch resolve the conflict with > >https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00309.html > > The change is

Re: [PATCH] correct atomic_compare_exchange_n return type (c++/71675)

Hi Martin, I observed the following error: ERROR: gcc.dg/atomic/pr71675.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects : syntax error in target selector "target c11" for " dg-do 3 compile { target c11 } " It seems we don't have a c11 effective target check available in dejagnu

Re: [AArch64][2/14] ARMv8.2-A FP16 one operand vector intrinsics

On Wed, Jul 20, 2016 at 06:00:34PM +0100, Jiong Wang wrote: > On 07/07/16 17:14, Jiong Wang wrote: > >This patch add ARMv8.2-A FP16 one operand vector intrinsics. > > > >We introduced new mode iterators to cover HF modes, qualified patterns > >which was using old mode iterators are switched to new

[Fortran, Patch, pr70524, v1] [5/6/7 Regression] ICE when using -frepack-arrays -Warray-temporaries

Hi all, the attached patch fixes the ICE when the options in the title are used. Two issues caused this ICE: 1. the error-printing routines relied on the locus.nextc which was not set by the gfc_set_backend_locus() and is now set by the patch (locally, not in gfc_set_backend_locus()). 2. the

[PATCHv2, PING][ARM] -mpure-code option for ARM

On 11/07/16 17:56, Andre Vieira (lists) wrote: > On 07/07/16 13:30, mickael guene wrote: >> Hi Andre, >> >> Another feedback on your purecode patch. >> You have to disable casesi pattern since then it will >> generate wrong code with -mpure-code option. >> Indeed it will generate an 'adr rx,

Re: [PATCH/AARCH64] Add scheduler for vulcan.

On Wed, Jul 20, 2016 at 03:07:45PM +0530, Virendra Pathak wrote: > Hi gcc-patches group, > > Please find the patch for adding the basic scheduler for vulcan > in the aarch64 port. > > Tested the patch with compiling cross aarch64-linux-gcc, > bootstrapped native aarch64-unknown-linux-gnu and >

[PATCH] Use std::mt19937, std::thread and std::atomic to simplify tests

These tests that hammer shared_ptr and weak_ptr to test the thread-safety of the reference counting were originally written for the TR1 smart pointers, and so pre-date std::thread etc. This refactors them to use C++11 std::thread and std::atomic (with relaxed memory ordering, since we don't need

Re: [PATCH] Call get_ops just for SSA_NAMEs (PR tree-optimization/71987)

On Mon, Jul 25, 2016 at 10:56 AM, Martin Liška wrote: > Hi. > > As other calls of get_ops is guarded with TREE_CODE (x) == SSA_NAME, I guess > the > same should be done for the call that causes the ICE. > > Patch can bootstrap on ppc64le-redhat-linux and survives regression

Re: [PATCH] Fix memory leak introduced in r238336

On Mon, Jul 25, 2016 at 10:58 AM, Martin Liška wrote: > Hi. > > This is quite obvious change. > > I've been waiting for bootstrap and regression tests on ppc64le-redhat-linux. > Ready after it finishes? Ok. Richard. > Martin

Re: [PATCH] Handle loops with loop->latch == NULL (PR gcov-profile/71868)

On Mon, Jul 25, 2016 at 10:55 AM, Martin Liška wrote: > Hi. > > As discussed with Honza, we should sum all edge frequencies when a loop > has multiple latches. > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > Ready to be installed? - if

Re: [RFC][IPA-VRP] Disable setting param of __builtin_constant_p to null

On Mon, Jul 25, 2016 at 8:59 AM, kugan wrote: > Hi, > >>> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c >>> index ecfab1f..23c12b5 100644 >>> --- a/gcc/tree-vrp.c >>> +++ b/gcc/tree-vrp.c >>> @@ -3759,8 +3759,10 @@ extract_range_basic (value_range *vr, gimple >>>

  1   2   >