Re: libsanitizer merge from upstream r208536

On 05/23/2014 10:34 AM, Jakub Jelinek wrote: Otherwise libasan apps will simply stop working altogether if LD_PRELOAD is set, to whatever library, even if it doesn't define any symbols you care about. Right but I'm not sure whether failing fast here is necessarily bad. I think it is very bad.

[PATCH] Fix PR rtl-optimization/61278

Hi, The patch fixes PR rtl-optimization/61278. Root cause for issue is that df_live does not exist at -O1. Bootstrap and no make check regression on X86-64. OK for trunk? Thanks! -Zhenqiang ChangeLog: 2014-05-23 Zhenqiang Chen PR rtl-optimization/61278 * shrink-wrap.c (move

Re: [PATCH, sched] Cleanup and improve multipass_dfa_lookahead_guard

../../gcc/config/ia64/ia64.c: In function 'int ia64_first_cycle_multipass_dfa_lookahead_guard(rtx, int)': ../../gcc/config/ia64/ia64.c:7551:1: error: control reaches end of non-void function [-Werror=return-type] Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7

Re: libsanitizer merge from upstream r208536

On Thu, May 22, 2014 at 7:31 AM, Konstantin Serebryany wrote: > On Wed, May 21, 2014 at 11:43 PM, Jakub Jelinek wrote: >> On Wed, May 21, 2014 at 04:09:19PM +0400, Konstantin Serebryany wrote: >>> A new patch based on r209283. >>> This one has the H.J.'s patches for x32. >> >> Ok for trunk then.

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 11:20 AM, Yury Gribov wrote: > On 05/23/2014 10:34 AM, Jakub Jelinek wrote: Otherwise libasan apps will simply stop working altogether if LD_PRELOAD is set, to whatever library, even if it doesn't define any symbols you care about. >>> >>> >>> Right but

Re: [PATCH, sched] Cleanup and improve multipass_dfa_lookahead_guard

On May 23, 2014, at 7:23 PM, Andreas Schwab wrote: > ../../gcc/config/ia64/ia64.c: In function 'int > ia64_first_cycle_multipass_dfa_lookahead_guard(rtx, int)': > ../../gcc/config/ia64/ia64.c:7551:1: error: control reaches end of non-void > function [-Werror=return-type] Fixed, sorry about the

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 11:20:01AM +0400, Yury Gribov wrote: > >Even before this exaggerated check asan imposes far more restrictions than > >good, and this just makes asan less usable just for fear that it wouldn't > >work right. > > Ok, we seem to approach this from two different angles. > I usu

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 11:32 AM, Ramana Radhakrishnan wrote: > On Thu, May 22, 2014 at 7:31 AM, Konstantin Serebryany > wrote: >> On Wed, May 21, 2014 at 11:43 PM, Jakub Jelinek wrote: >>> On Wed, May 21, 2014 at 04:09:19PM +0400, Konstantin Serebryany wrote: A new patch based on r209283.

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 11:34:38AM +0400, Konstantin Serebryany wrote: > Failing to intercept something may cause not just false negatives, but > also false positives. > These cases are often exceptionally hard to debug, so any checking that > the interception machinery works as intended is good. O

Re: libsanitizer merge from upstream r208536

> On ARM the asan tests have always been a random generator of PASS / > FAIL on qemu despite efforts to "nobble" qemu for /proc/self/maps > outputs. This should improve once upstream Asan sets up an ARM build bot. This has been discussed recently but noone has yet volunteered to do the server i

Re: libsanitizer merge from upstream r208536

On 05/23/14 08:50, Yury Gribov wrote: > On ARM the asan tests have always been a random generator of PASS / > FAIL on qemu despite efforts to "nobble" qemu for /proc/self/maps > outputs. This should improve once upstream Asan sets up an ARM build bot. This has been discussed recently but n

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 11:56 AM, Ramana Radhakrishnan wrote: > On 05/23/14 08:50, Yury Gribov wrote: >> >> > On ARM the asan tests have always been a random generator of PASS / >> > FAIL on qemu despite efforts to "nobble" qemu for /proc/self/maps >> > outputs. >> >> This should improve onc

[PATCH] Fix PR61266

The following reverts the un-XFAILing and adjusts the testcase according to reality (as already noted in testcase comments). Committed. Richard. 2014-05-23 Richard Biener PR testsuite/61266 * gcc.dg/Wstrict-overflow-18.c: Revert un-XFAILing and adjust testcase to ref

Re: libsanitizer merge from upstream r208536

Hi, On 05/23/2014 09:47 AM, Jakub Jelinek wrote: On Fri, May 23, 2014 at 11:34:38AM +0400, Konstantin Serebryany wrote: Failing to intercept something may cause not just false negatives, but also false positives. These cases are often exceptionally hard to debug, so any checking that the interc

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

Hello, Does this touch or address the problem raised in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46219#c3 ? [Uros Bizjak] >> For some reason, memory operand is prohibited in a sibcall, see >> predicates.md [...] [Richard Henderson] > That would be because we have no good way to say: global m

Re: libsanitizer merge from upstream r208536

Paolo, I've checked all available systems and wasn't able to repro this. Every time vDSO was already filtered with if (!info->dlpi_name || info->dlpi_name[0] == 0) return 0; in FindFirstDSOCallback. Could you provide additional details of your setup? Or perhaps print dlpi_name of offend

Re: [PATCH] Disable unroll loop that has header count less than iteration count.

On Thu, May 22, 2014 at 11:36 PM, Dehao Chen wrote: > If a loop's header count is less than iteration count, the iteration > estimation is apparently incorrect for this loop. Thus disable > unrolling of such loops. > > Testing on going. OK for trunk if test pass? No. Why don't you instead plug t

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

Hello, yes the underlying issue is the same as for PR/46219. Nevertheless the patch doesn't solve this mentioned PR as I used for know a pretty conservative checking of allowed memories. By extending x86_sibcall_memory_p_1 function about allowing register-arguments too for memory, this problem

Re: libsanitizer merge from upstream r208536

Hi, On 05/23/2014 10:50 AM, Yury Gribov wrote: Paolo, I've checked all available systems and wasn't able to repro this. Given your exchanges with Jakub I thought that at this point it was clear that the issue is real. Every time vDSO was already filtered with if (!info->dlpi_name || info->

Re: [PATCH] Fix PR rtl-optimization/61278

On Fri, May 23, 2014 at 9:23 AM, Zhenqiang Chen wrote: > Hi, > > The patch fixes PR rtl-optimization/61278. Root cause for issue is > that df_live does not exist at -O1. > > Bootstrap and no make check regression on X86-64. > > OK for trunk? Why do you need to give up? It seems you can simply av

Re: libsanitizer merge from upstream r208536

I've checked all available systems and wasn't able to repro this. Given your exchanges with Jakub I thought that at this point it was clear that the issue is real. There are three issues here: 1) whether warning should cause termination 2) whether warning should be displayed by default 3) why

Re: libsanitizer merge from upstream r208536

> still should have come up on your machine in the first place. should not have

Re: libsanitizer merge from upstream r208536

Hi, On 05/23/2014 11:21 AM, Yury Gribov wrote: I've checked all available systems and wasn't able to repro this. Given your exchanges with Jakub I thought that at this point it was clear that the issue is real. There are three issues here: 1) whether warning should cause termination 2) wheth

Re: emit __float128 typeinfo

On Wed, 21 May 2014, Jason Merrill wrote: On 04/25/2014 05:04 AM, Marc Glisse wrote: Does this approach seem ok, or do we need to try harder to find a way to get this typeinfo into libsupc++? The latter, I think; these are base types, so they should go in the library. Hmm, ok. Because of th

Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags

On Thu, May 22, 2014 at 8:11 PM, Jan Hubicka wrote: >> >It won't be so easy, because struct function is really built at >> >relatively convoluted >> >places within frontend before cgraph node is assigned to them (I tried >> >that few years >> >back). >> >> Well, just call cgraph create node from s

Re: [PATCH] __attribute__ ((malloc)) doc fix (PR other/56955)

On Thu, May 22, 2014 at 4:15 PM, Paul Eggert wrote: > Richard Biener wrote: >> >> Can you try to clarify the wording (I'm not a native speaker). > > > Sure. I've filed a clarified version on PR 56955 and am attaching it here > for convenience. Thanks, installed. Richard.

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 11:25:02AM +0200, Paolo Carlini wrote: > >>How do I print dlpi_name? > > > >Could you add something like > > Report("'%s'\n", info->dlpi_name); > >after > > if (!info->dlpi_name || info->dlpi_name[0] == 0) > >check in FindFirstDSOCallback? This should give us the name of >

Re: libsanitizer merge from upstream r208536

>> Could you add something like > > It's always linux-vdso.so.1, but wasn't that already known, given the > ldd requested by Jakub?!? Well, for me dlpi_name for vdso was empty string hence I kept asking. I also thought that ldd and dl_iterate_phdr might have used slightly different code paths w

Re: [PATCH] Fix PR rtl-optimization/61278

On 23 May 2014 17:05, Richard Biener wrote: > On Fri, May 23, 2014 at 9:23 AM, Zhenqiang Chen > wrote: >> Hi, >> >> The patch fixes PR rtl-optimization/61278. Root cause for issue is >> that df_live does not exist at -O1. >> >> Bootstrap and no make check regression on X86-64. >> >> OK for trunk?

[patch] libstdc++/60793 Add *-*-dragonfly* to testsuite target selectors

A mechanical patch to run tests on DragonFlyBSD. Tested x86_64--unknown-linux-gnu and x86_64-unknown-dragonfly3.6, committed to trunk. patch.txt.bz2 Description: BZip2 compressed data

[patch] Adjust target selectors for some libstdc++ tests

This marks a test that is xfail for darwin as also xfail for dragonfly. I'm surprised it fails on darwin and dragonfly but not freebsd, but Gerald's testresults don't show it failing. Also fix a couple of tests which were missing target selectors on the { dg-do compile } directive, so the tests r

[PATCH/RFC, ARM] Improve static checking of tune_params

One of the things that worries me about all the static tuning tables we have in the compiler is that it is easy to get the order of elements wrong, especially when adding a lot of new fields to existing descriptions. This patch attempts to improve the static checking in this area by making use of

Re: libsanitizer merge from upstream r208536

Hi, On 05/23/2014 12:26 PM, Yury Gribov wrote: >> Could you add something like > > It's always linux-vdso.so.1, but wasn't that already known, given the > ldd requested by Jakub?!? Well, for me dlpi_name for vdso was empty string hence I kept asking. I also thought that ldd and dl_iterate_phdr

Re: [patch] Adjust target selectors for some libstdc++ tests

Jonathan Wakely writes: > diff --git a/libstdc++-v3/testsuite/30_threads/call_once/60497.cc > b/libstdc++-v3/testsuite/30_threads/call_once/60497.cc > index b058204..a82b88f 100644 > --- a/libstdc++-v3/testsuite/30_threads/call_once/60497.cc > +++ b/libstdc++-v3/testsuite/30_threads/call_once/60

[COMMITTED] Fix some bool vs. tree confusion.

From: tschwinge gcc/c/ * c-parser.c (c_parser_omp_target): Return bool values. gcc/cp/ * parser.c (cp_parser_omp_target): Return bool values. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210851 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/c/ChangeLog | 4 ++

[COMMITTED] Be more explicit.

From: tschwinge gcc/ * gimplify.c (omp_notice_variable) : Explicitly enumerate the expected region types. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210852 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/ChangeLog | 5 + gcc/gimplify.c | 15 +-- 2 fi

[COMMITTED] Remove duplicated variable initialization.

From: tschwinge gcc/c/ * c-typeck.c (c_finish_omp_clauses): Remove duplicated variable initialization. gcc/cp/ * semantics.c (finish_omp_clauses): Remove duplicated variable initialization. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210853 13

[COMMITTED 2/2] GF_OMP_FOR_SIMD: Flag for SIMD variants of OMP_FOR kinds.

From: tschwinge gcc/ * gimple.h (enum gf_mask): Add and use GF_OMP_FOR_SIMD. * omp-low.c: Update accordingly. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210855 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/ChangeLog | 3 +++ gcc/gimple.h | 6 -- gcc/omp-low.c

[COMMITTED 1/2] Just enumerate all GF_OMP_FOR_KIND_* and GF_OMP_TARGET_KIND_*.

From: tschwinge gcc/ * gimple.h (enum gf_mask): Rewrite "<< 0" shift expressions used for GF_OMP_FOR_KIND_MASK, GF_OMP_FOR_KIND_FOR, GF_OMP_FOR_KIND_DISTRIBUTE, GF_OMP_FOR_KIND_SIMD, GF_OMP_FOR_KIND_CILKSIMD, GF_OMP_TARGET_KIND_MASK, GF_OMP_TARGET_K

Re: [COMMITTED] Be more explicit.

On Fri, May 23, 2014 at 01:08:09PM +0200, Thomas Schwinge wrote: > @@ -5683,7 +5683,14 @@ omp_notice_variable (struct gimplify_omp_ctx *ctx, > tree decl, bool in_code) >switch (default_kind) > { > case OMP_CLAUSE_DEFAULT_NONE: > - if ((ctx->region_type & ORT_TASK) != 0) >

Re: wide-int, rtl-2

> This looks OK to me. I obviously didn't look carefully enough, there are a few thinkos in the output_constructor_bitfield hunk: - if (shift < HOST_BITS_PER_WIDE_INT - && shift + this_time > HOST_BITS_PER_WIDE_INT) - { - this_time = shift + this_time -

[COMMITTED] Make it easier to diff expand_omp_for_* functions.

From: tschwinge gcc/ * omp-low.c (expand_omp_for_static_chunk): Rename variable si to gsi, and variables v_* to v*. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210858 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/ChangeLog | 5 +++ gcc/omp-low.c | 118 +

[PATCH][2/n] Always 64bit-HWI cleanups

The following changes the configury to insist on [u]int64_t being available and removes the very old __int64 case. Autoconf doesn't check for it, support came in via a big merge in Dec 2002, r60174, and it was never used on the libcpp side until I fixed that with the last patch of this series, so

Re: [patch] Adjust target selectors for some libstdc++ tests

On 23/05/14 12:49 +0200, Rainer Orth wrote: Any reason to list dragonfly twice? Oops, no - that's due to me reordering commits with rebase so the sed command added it to some files I'd already added it to. Fixed with the attached patch, thanks. commit 12ad71abb1122314f38e98d382c86eacd3cbb022 A

Re: [COMMITTED 1/2] Just enumerate all GF_OMP_FOR_KIND_* and GF_OMP_TARGET_KIND_*.

I think it was supposed to note that it uses two bits in the mask. Did Jakub approve these patches you are committing now? Thanks, Richard. On Fri, May 23, 2014 at 1:32 PM, Thomas Schwinge wrote: > From: tschwinge > > gcc/ > * gimple.h (enum gf_mask): Rewrite "<< 0" shift expre

Re: [PATCH] Fix PR rtl-optimization/61278

On Fri, May 23, 2014 at 12:33 PM, Zhenqiang Chen wrote: > On 23 May 2014 17:05, Richard Biener wrote: >> On Fri, May 23, 2014 at 9:23 AM, Zhenqiang Chen >> wrote: >>> Hi, >>> >>> The patch fixes PR rtl-optimization/61278. Root cause for issue is >>> that df_live does not exist at -O1. >>> >>> Bo

[COMMITTED] Be a bit less explicit.

From: tschwinge gcc/ * gimplify.c (omp_notice_variable) : Rewrite check for ORT_PARALLEL and ORT_COMBINED_PARALLEL. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210860 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/ChangeLog | 3 +++ gcc/gimplify.c | 3 +-- 2 files ch

Re: libsanitizer merge from upstream r208536

>> 2) it doesn't still deal with unaligned power of two accesses properly, >>but neither does llvm (at least not 3.4). Am not talking about >>undefined behavior cases where the compiler isn't told the access >>is misaligned, but e.g. when accessing struct S { int x; } >>__attribute

Re: [COMMITTED 1/2] Just enumerate all GF_OMP_FOR_KIND_* and GF_OMP_TARGET_KIND_*.

Hi! On Fri, 23 May 2014 13:50:40 +0200, Richard Biener wrote: > I think it was supposed to note that it uses two bits in the mask. That is, you'd like me to add a comment saying that? (Which I can certainly do.) > Did Jakub approve these patches you are committing now? For the two in this th

Re: [PATCH 1/9] rs6000: Clean up the "type" attribute

On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool wrote: > Get rid of the one huge line. Group and order things a bit. Further > changes will follow so this doesn't try to make it perfect. > > The rest of this patch series reduces the number of different integer > instruction types by folding

Re: [PATCH 2/9] rs6000: New type attribute value "halfmul"

On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool wrote: > This is for the legacy integer multiply-accumulate instructions. > Quite a mouthful, and "mulhw" is also a terrible name since we already > have a machine instruction called exactly that. Hence "halfmul". > > Also fixes the titan automa

Re: [PATCH 3/9] rs6000: Make all multiply instructions one type

On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool wrote: > This uses the attributes "size" and "dot" to specify the differences: > > imul3 -> mul size=8 > imul2 -> mul size=16 > imul -> mul size=32 > lmul -> mul size=64 > imul_compare -> mul size=32 dot=ye

Re: libsanitizer merge from upstream r208536

On Mon, May 12, 2014 at 03:20:37PM +0400, Konstantin Serebryany wrote: > 5 months' worth of changes may break any platform we are not testing ourselves > (that includes Ubuntu 12.04, 13.10, 14.04, Mac 10.9, Windows 7, Android ARM), > please help us test this patch on your favorite platform. On pow

Re: [PATCH 4/9] rs6000: Make all insert instructions one type

On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool wrote: > This uses the attribute "size" to specify the differences: > > insert_word -> insert size=32 > insert_dword -> insert size=64 > > It could use "dot" as well, but the current code doesn't handle that. > > > 2014-05-22 Se

Re: [PATCH 6/9] rs6000: Make all shift instructions one type

On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool wrote: > This uses the attributes "var_shift" and "dot" to specify the differences: > > var_shift_rotate-> shift var_shift=yes > delayed_compare -> shift var_shift=no dot=yes > var_delayed_compare -> shift var_shi

Re: [PATCH 7/9] rs6000: Make all add instructions one type

On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool wrote: > They are currently just "integer", but the dot version is fast_compare. > This makes them all "add". Later we should introduce attributes to > distinguish e.g. addc and adde (which aren't currently handled as > separate instructions at

Re: [PATCH 8/9] rs6000: Make all logical instructions one type

On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool wrote: > They are currently just "integer", but the dot version is fast_compare. > This makes them all "logical". > > > 2014-05-22 Segher Boessenkool > > gcc/ > * config/rs6000/rs6000.md (type): Add "logical". Delete > "fast_c

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote: > On Mon, May 12, 2014 at 03:20:37PM +0400, Konstantin Serebryany wrote: >> 5 months' worth of changes may break any platform we are not testing >> ourselves >> (that includes Ubuntu 12.04, 13.10, 14.04, Mac 10.9, Windows 7, Android ARM), >> p

Re: [PATCH 5/9] rs6000: Make all divide instructions one type

On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool wrote: > This uses the attribute "size" to specify the differences: > > idiv -> div size=32 > ldiv -> div size=64 > > It could use "dot" as well, but the current code doesn't handle that. > > > 2014-05-22 Segher Boessenkool > >

Re: [PATCH 9/9] rs6000: Make all rlw*nm and rld*c* type shift

On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool wrote: > They are often labeled just "integer" currently. Fix that. > > Also handle shift properly in those scheduling descriptions that > neglected it. > > > 2014-05-22 Segher Boessenkool > > gcc/ > * config/rs6000/440.md (ppc440-int

Re: libsanitizer merge from upstream r208536

Hi, Since merge from upstream r209283 (210743 in GCC), my build fails on ARM, because rpc/xdr.h is not found. Is this expected? Thanks, Christophe. On 23 May 2014 15:45, Konstantin Serebryany wrote: > On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote: >> On Mon, May 12, 2014 at 03:20:37PM

Re: libsanitizer merge from upstream r208536

On 24/05/14 00:06, Christophe Lyon wrote: > Hi, > Since merge from upstream r209283 (210743 in GCC), my build fails on > ARM, because rpc/xdr.h is not found. > Is this expected? I also have the same issue. I had to build glibc with --enable-obsolete-rpc to bootstrap now. Thanks, Kugan

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 6:11 PM, Kugan wrote: > On 24/05/14 00:06, Christophe Lyon wrote: >> Hi, >> Since merge from upstream r209283 (210743 in GCC), my build fails on >> ARM, because rpc/xdr.h is not found. >> Is this expected? > I also have the same issue. I had to build glibc with > --enable-o

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 6:12 PM, Konstantin Serebryany wrote: > On Fri, May 23, 2014 at 6:11 PM, Kugan > wrote: >> On 24/05/14 00:06, Christophe Lyon wrote: >>> Hi, >>> Since merge from upstream r209283 (210743 in GCC), my build fails on >>> ARM, because rpc/xdr.h is not found. >>> Is this expect

Re: libsanitizer merge from upstream r208536

On Fri, 2014-05-23 at 17:45 +0400, Konstantin Serebryany wrote: > On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote: > > On Mon, May 12, 2014 at 03:20:37PM +0400, Konstantin Serebryany wrote: > >> 5 months' worth of changes may break any platform we are not testing > >> ourselves > >> (that in

Re: [PATCH] Implement -fsanitize=float-cast-overflow (take 3)

On Fri, May 23, 2014 at 04:19:00PM +0200, Marek Polacek wrote: > This is the latest patch for -fsanitize=float-cast-overflow. Since last > version it: > - adds tons of tests written by Jakub; > - patches libubsan so it can handle 96-bit floating-point types > (that is, long double and __float80

Re: [PATCH] Implement -fsanitize=float-cast-overflow (take 3)

On Fri, May 23, 2014 at 6:28 PM, Jakub Jelinek wrote: > On Fri, May 23, 2014 at 04:19:00PM +0200, Marek Polacek wrote: >> This is the latest patch for -fsanitize=float-cast-overflow. Since last >> version it: >> - adds tons of tests written by Jakub; >> - patches libubsan so it can handle 96-bit

Re: [PATCH 3/7] IPA-CP escape and clobber analysis

Hi, sorry, I should have added a better description of the overall algorithm, I will try to do that now, I hope I will at least clarify what stage does what. At summary generation time, we process one function after another, looking at their bodies. There are three new things in the generated su

Re: [PATCH] Implement -fsanitize=float-cast-overflow (take 3)

On Fri, May 23, 2014 at 6:35 PM, Konstantin Serebryany wrote: > On Fri, May 23, 2014 at 6:28 PM, Jakub Jelinek wrote: >> On Fri, May 23, 2014 at 04:19:00PM +0200, Marek Polacek wrote: >>> This is the latest patch for -fsanitize=float-cast-overflow. Since last >>> version it: >>> - adds tons of t

Re: libsanitizer merge from upstream r208536

Hi Christophe, is there anything special about your setup? We've seen it build on arm/linux and arm/android correctly. On Fri, May 23, 2014 at 6:06 PM, Christophe Lyon wrote: > Hi, > Since merge from upstream r209283 (210743 in GCC), my build fails on > ARM, because rpc/xdr.h is not found. > Is

Re: [RS6000] Fix PR61098, Poor code setting count register

OK, let's start again from scratch. This patch fixes PR61098, a problem caused by trying to do arithmetic on the count register. The fix is to provide a new pseudo in rs6000_emit_set_long_const so arithmetic will be done in a gpr. Additionally, the patch fixes a number of other bugs and cleanup

Re: [PATCH][ARM] Vectorize bswap[16,32,64] operations

Looks good except for : diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index ef370fe..7e1ec71 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -3280,7 +3280,8 @@ proc check_effective_target_vect_bswap { }

patch to add test for PR61215

The following patch adds missed test for the PR. Committed to the trunk as rev. 210838. 2014-05-23 Vladimir Makarov PR rtl-optimization/61215 * gcc.target/i386/pr61215.c: New. Index: testsuite/gcc.target/i386/pr61215.c

Re: patch to add test for PR61215

On Fri, May 23, 2014 at 11:36:33AM -0400, Vladimir Makarov wrote: > The following patch adds missed test for the PR. > > Committed to the trunk as rev. 210838. > > 2014-05-23 Vladimir Makarov > > PR rtl-optimization/61215 > * gcc.target/i386/pr61215.c: New. > > Index: testsui

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 11:40 AM, Jakub Jelinek wrote: > No other shared library does anything close to that, for each such library > you can interpose any of its public symbols, either you know what you are > doing when interposing it, or it breaks. I think I have finally recalled why we added t

Re: [PATCH 3/9] rs6000: Make all multiply instructions one type

On 05/23/2014 01:09 AM, Segher Boessenkool wrote: @@ -27385,6 +27371,11 @@ insn_must_be_first_in_group (rtx insn) case TYPE_MFJMPR: case TYPE_MTJMPR: return true; +case TYPE_MUL: + if (get_attr_dot (insn) == DOT_YES) +return true; +

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 04:11:48PM +0400, Konstantin Serebryany wrote: > >> 2) it doesn't still deal with unaligned power of two accesses properly, > >>but neither does llvm (at least not 3.4). Am not talking about > >>undefined behavior cases where the compiler isn't told the access > >>

Re: libsanitizer merge from upstream r208536

On Fri, 2014-05-23 at 09:25 -0500, Peter Bergner wrote: > xagsmtp4.20140523142452.1...@vmsdvm6.vnet.ibm.com > X-Xagent-Gateway: vmsdvm6.vnet.ibm.com (XAGSMTP4 at VMSDVM6) > > On Fri, 2014-05-23 at 17:45 +0400, Konstantin Serebryany wrote: > > On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote:

Re: [PATCH] Disable unroll loop that has header count less than iteration count.

> On Thu, May 22, 2014 at 11:36 PM, Dehao Chen wrote: > > If a loop's header count is less than iteration count, the iteration > > estimation is apparently incorrect for this loop. Thus disable > > unrolling of such loops. > > > > Testing on going. OK for trunk if test pass? > > No. Why don't yo

Re: [C++ patch] Reduce vtable alignment

Hi, I would like to ping these two patches. If we conclude it is absolutely unsafe to not align virtual tables to 16byte boundary (that is an x86_64 ABI requirement for array datastructures but I would like to argue that vtables are compiler controlled ones and do not need to follow ABI here), I ca

Re: [PATCH] Disable unroll loop that has header count less than iteration count.

On May 23, 2014 7:26:04 PM CEST, Jan Hubicka wrote: >> On Thu, May 22, 2014 at 11:36 PM, Dehao Chen >wrote: >> > If a loop's header count is less than iteration count, the >iteration >> > estimation is apparently incorrect for this loop. Thus disable >> > unrolling of such loops. >> > >> > Testin

Re: [PATCH] Disable unroll loop that has header count less than iteration count.

> > > > if (expected_loop_iterations_reliable_p (loop)) > > niters = expected_loop_iterations (loop); > > But why not simply never return bogus values from expected-loop-iterations? Hmm, actually we do have: /* If we have a measured profile, use it to estimate the number of iterations.

Re: [PATCH][3/n] Always 64bit-HWI cleanups (drop HOST_WIDEST_INT)

On 05/23/14 07:49, Richard Biener wrote: This patch does the exercise of a "grand" rename and drops HOST_WIDEST_INT which is equal to HOST_WIDE_INT now. But we use [u]int64_t and the C99 inttypes.h PRI[dux]64 printf modifiers (which I provide in hwint.h if they are not available). Certainly mo

Re: [PATCH][2/n] Always 64bit-HWI cleanups

On 05/23/14 05:45, Richard Biener wrote: The following changes the configury to insist on [u]int64_t being available and removes the very old __int64 case. Autoconf doesn't check for it, support came in via a big merge in Dec 2002, r60174, and it was never used on the libcpp side until I fixed

Re: [PATCH, sched] Cleanup and improve multipass_dfa_lookahead_guard

On 05/23/14 01:35, Maxim Kuvyrkov wrote: On May 23, 2014, at 7:23 PM, Andreas Schwab wrote: ../../gcc/config/ia64/ia64.c: In function 'int ia64_first_cycle_multipass_dfa_lookahead_guard(rtx, int)': ../../gcc/config/ia64/ia64.c:7551:1: error: control reaches end of non-void function [-Werror=

Re: [patch i386]: Sibcall tail-call improvement and partial fix PR/60104

On 05/23/14 02:58, Kai Tietz wrote: Hello, yes the underlying issue is the same as for PR/46219. Nevertheless the patch doesn't solve this mentioned PR as I used for know a pretty conservative checking of allowed memories. By extending x86_sibcall_memory_p_1 function about allowing register-arg

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

On 05/22/14 16:07, H.J. Lu wrote: On Thu, May 22, 2014 at 2:33 PM, Kai Tietz wrote: Hello, This patch avoids for sibling-tail-calls the use of pseudo-register. Instead it uses for load of memory-address the accumulator-register. By this we avoid that IRA/LRA need to choose a register. So

[Google/4_8] Support for embedding build info into gcda files

Support for embedding arbitrary build information from the profile-generate compile into the gcda file in a new BUILD_INFO record. Lines from a file passed to the -fprofile-generate compile via a new -fprofile-generate-buildinfo=filename option are embedded as strings in the gcov_info struct and em

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

On 05/22/14 15:33, Kai Tietz wrote: Hello, This patch avoids for sibling-tail-calls the use of pseudo-register. Instead it uses for load of memory-address the accumulator-register. By this we avoid that IRA/LRA need to choose a register. So we reduce register-pressure. The accumulator-register

Re: RFA: cache enabled attribute by insn code

On 05/20/14 15:36, Richard Sandiford wrote: This is OK for the trunk (referring to the follow-up message which fixed EWRONGPATCH. Sorry, while working on the follow-up LRA patch, I realised I hadn't accounted for target changes that happen directly via target_reinit (rather than SWITCHABLE_TARG

Re: [PATCH] Fix ICE in rtl-optimization/PR61220, PR61225

On 05/20/14 20:12, Zhenqiang Chen wrote: In the code, there are 4 combinations of EDGE_COUNT: <1, 1>, <1, 2>, <2, 1> and <2, 2>. <2, 1> is "illegal". <2, 2> is legal, but need split_edge. <1, *> can bypass the second check. EDGE_CRITICAL_P can only distinguish <2, 2> from others. So I think two

Re: [PATCH] proposed fix for bug # 61144

On 05/21/14 21:59, Rich Felker wrote: On Wed, May 21, 2014 at 11:17:53AM +0200, Richard Biener wrote: On Wed, May 21, 2014 at 3:59 AM, Rich Felker wrote: Bug # 61144 is a regression in 4.9.0 that breaks building of musl libc due to aggressive and semantically-incorrect constant folding of weak

Re: [Google/4_8] Support for embedding build info into gcda files

The change makes gcov_info a variable length array, which is not ideal. Better just add one more field (instead of two): struct gcov_info { ... char ** build_info; }; For regular case, it is null, for case where the build info is available, make it point to a string array (with an null end

[PATCH] Remove now unnecessary bailout from split_live_ranges_for_shrink_wrap

Hi, since Jakub has fixed my code and replaced wrong validate_change (uin, DF_REF_LOC (use), newreg, true); with correct validate_change (uin, DF_REF_REAL_LOC (use), newreg, true); in split_live_ranges_for_shrink_wrap, we can remove the punting condition slightly a

Re: [PATCH] Remove now unnecessary bailout from split_live_ranges_for_shrink_wrap

On 05/23/14 12:39, Martin Jambor wrote: Hi, since Jakub has fixed my code and replaced wrong validate_change (uin, DF_REF_LOC (use), newreg, true); with correct validate_change (uin, DF_REF_REAL_LOC (use), newreg, true); in split_live_ranges_for_shrink_wrap, we

Re: libsanitizer merge from upstream r208536

On Fri, 2014-05-23 at 11:47 -0500, Peter Bergner wrote: > The following patch gets bootstrap working again, but there seems to > be a large number of testsuite failures I will look into before > submitting the patch to the LLVM mailing list. FYI, it looks like a huge number of the failures are fro

Re: [PATCH 3/9] rs6000: Make all multiply instructions one type

On Fri, May 23, 2014 at 11:22:10AM -0500, Pat Haugen wrote: > On 05/23/2014 01:09 AM, Segher Boessenkool wrote: > >@@ -27385,6 +27371,11 @@ insn_must_be_first_in_group (rtx insn) > > case TYPE_MFJMPR: > > case TYPE_MTJMPR: > >return true; > >+case TYPE_MUL: > >

Re: libsanitizer merge from upstream r208536

On Fri, May 23, 2014 at 01:54:47PM -0500, Peter Bergner wrote: > On Fri, 2014-05-23 at 11:47 -0500, Peter Bergner wrote: > > The following patch gets bootstrap working again, but there seems to > > be a large number of testsuite failures I will look into before > > submitting the patch to the LLVM

libstdc++ automake version

On 12/05/2014 22:42, Paolo Carlini wrote: Hi, On 05/12/2014 10:14 PM, François Dumont wrote: Regarding Makefile.in I miss last time. I moved to a new system lately, a Ubuntu based one, and still need to find out what version of automake/autoreconf I need to install. For the moment I have upda

[Patch, Fortran, committed] Update *.texi: Fix broken links and use https where possible

Committed as Rev. 210877. Tobias Index: gcc/fortran/ChangeLog === --- gcc/fortran/ChangeLog (Revision 210876) +++ gcc/fortran/ChangeLog (Arbeitskopie) @@ -1,3 +1,8 @@ +2014-05-23 Tobias Burnus + + * gfc-internals.texi: Change URLs

  1   2   >