Re: [i386] scalar ops that preserve the high part of a vector

Hi guys, Could I ask several questions just to clarify the things up? 1) Does the root problem lay in the fact that even for scalar additions we perform the addition on the whole vector and only then drop the higher parts of the vector? I.e. to fix the test from the PR we need to replace plus on v

C++ PATCH for c++/54325 (wrong error initializing abstract base class)

It's perfectly OK to initialize a base class of abstract type; it's only an error to create a full object of such a type. So this patch moves the check from more generic initialization code out into a function that's definitely creating a new object. Tested x86_64-pc-linux-gnu, applying to tr

Re: Backported r185234 from trunk (r194264 from google/gcc-4_7). (issue 6904043)

On 2012/12/07 00:29:39, asharif wrote: On 2012/12/06 22:02:16, Diego Novillo wrote: > On Thu, Dec 6, 2012 at 4:51 PM, wrote: > > > I don't think the rule is to *only* update ChangeLog.google*. The rule > > is to update ChangeLog, but also update ChangeLog.google

Re: Backported r185234 from trunk (r194264 from google/gcc-4_7). (issue 6904043)

On 2012/12/06 22:02:16, Diego Novillo wrote: On Thu, Dec 6, 2012 at 4:51 PM, wrote: > I don't think the rule is to *only* update ChangeLog.google*. The rule > is to update ChangeLog, but also update ChangeLog.google*. Just ChangeLog.google*, actually. When

[patch] ree.c: don't abuse GTY

Hello, ree.c's data structures are not GC-allocated, so its GTY markers and its TODO_ggc_collect are unnecessary. Will commit as obvious after the usual testing on my favourite platforms :-) * ree.c (struct ext_cand): Remove GTY markers. (pass_ree): Remove TODO_ggc_collect. Inde

libgo patch committed: Remove empty directory

I committed a patch to remove the empty directory libgo/go/exp/types/staging from mainline. Ian

Re: [patch,wwwdocs] Update AddressSanitizer part of the 4.8 release notes

On Thu, 6 Dec 2012, Tobias Burnus wrote: I think the following should match the current status. (I believe that libasan is also built on Sparc Linux but without instrumentation in the compiler itself.) OK? Looks obvious to me. :-) If you add SPARC at a later point, note the spelling (casing

[patch,wwwdocs] Update AddressSanitizer part of the 4.8 release notes

I think the following should match the current status. (I believe that libasan is also built on Sparc Linux but without instrumentation in the compiler itself.) OK? Tobias Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/

More vector constexpr fixes

Hello, this comes on top of Jakub's patch from earlier today. The ce->index checks only turn an ICE into an error: constexpr vector subscripts are not handled yet, they are a bit more complicated. 2012-12-07 Marc Glisse PR c++/53094 cp/ * tree.c (cp_tree_equal): Handle VEC

C++ PATCH for c++/55249 (missing symbol with array and multiple copy constructors)

When we're modeling what the initialization of one array element will look like, it would help to use the type of the array element. Tested x86_64-pc-linux-gnu, applying to 4.6, 4.7 and trunk. commit 0d89242428ea0917960bc6b1704605d9bc67bbb0 Author: Jason Merrill Date: Thu Dec 6 15:48:56 2012

C++ PATCH for c++/55058 (lost cv-quals with typedef in template)

When we look through a typedef, we need to keep any cv-quals that were added to it. Tested x86_64-pc-linux-gnu, applying to 4.7 and trunk. commit fb7279cb5a26b73256da2faa1f8078670531ef17 Author: Jason Merrill Date: Thu Dec 6 16:04:22 2012 -0500 PR c++/55058 * pt.c (tsubst): Keep th

Re: Backported r185234 from trunk (r194264 from google/gcc-4_7). (issue 6904043)

On Thu, Dec 6, 2012 at 4:51 PM, wrote: > I don't think the rule is to *only* update ChangeLog.google*. The rule > is to update ChangeLog, but also update ChangeLog.google*. Just ChangeLog.google*, actually. When cherry picking revisions from other branches, it's better not to update ChangeLog.

[PATCH, i386]: Fix PR55597, ICE in plus_constant, at explow.c:88

Hello! On x32, SImode and DImode symbols are accepted as valid. When SImode symbol is legitimized through legitimize_tls_address, we use Pmode operations and temporaries (in case of -maddress-mode=long, Pmode equals to DImode). In case of Pmode == DImode, we forgot to extend the mode of a sybmol f

Re: [PATCH, rs6000] Enable ASAN build on powerpc*-linux

On Thu, 2012-12-06 at 15:29 -0500, David Edelsohn wrote: > On Thu, Dec 6, 2012 at 2:40 PM, Peter Bergner wrote: > > * config/rs6000/sysv4.h (TARGET_ASAN_SHADOW_OFFSET): Define. > > * config/rs6000/rs6000.c (rs6000_asan_shadow_offset): New function. > > * config/rs6000/rs600

Re: Backported r185234 from trunk (r194264 from google/gcc-4_7). (issue 6904043)

On 2012/12/06 21:19:17, shenhan wrote: On 2012/12/06 20:18:02, asharif wrote: > Please review this backport needed to enable PGO for Chrome. I think we shall only change ChangeLog.google-xxx when adding changes to google branch. Quote from Diego - 'Please remember to use ChangeLog.google-

Re: [PATCH, rs6000] Update default loop peel limits

> The following patch restores the old default limits for loop peeling > that were recently changed to 100 and caused a 20% degradation in > 454.calculix. > > Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for trunk? > > -Pat > > > 2012-12-06 Pat Haugen > * config/rs

Re: [patch] PR55158 - segfault in sched-rgn.c

On 7/12/2012, at 1:31 AM, Steven Bosscher wrote: > Hello, > > The problem in this PR is that new basic blocks can be created if the > scheduler moves speculative insns and adds recovery code, but the > bb_state* arrays are allocated only at the start of scheduling a > region and are not set up to

Re: [lra] a patch to fix ppc bootstrap failure

On 12/05/2012 10:31 PM, Vladimir Makarov wrote: On 12-12-05 5:51 PM, Michael Meissner wrote: This is the file that causes the boostrap to fail if --enable-decimal-float is used as a configuration option on the LRA branch. You need to compile this in 32-bit mode with either -mcpu=power7, -mcpu=

Re: [PATCH] Don't drop DECL_INITIAL if -g for DWARF2+ (PR fortran/55395)

On Thu, Dec 06, 2012 at 09:12:48PM +0100, Jan Hubicka wrote: > > 2012-12-06 Jakub Jelinek > > > > PR fortran/55395 > > * varpool.c (varpool_remove_node): Don't drop DECL_INITIAL > > if -g and emitting DWARF2+. > > OK. How we want to handle this with LTO streaming? Don't know. Fr

Re: [PATCH, rs6000] Enable ASAN build on powerpc*-linux

On Thu, Dec 6, 2012 at 2:40 PM, Peter Bergner wrote: > Ok, how about the following which bootstrapped and regtested fine? > > Peter > > > libsanitizer/ > * configure.tgt: Enable build on powerpc*-linux. > > gcc/ > * config/rs6000/sysv4.h (TARGET_ASAN_SHADOW_OFFSET): Define. >

C++ PATCH for c++/54744 (typename typedef used in mem-initializer)

In the testcase, the derived class contains typedef typename derived::base_type::base_type base_type; and then the constructor uses 'base_type' in a mem-initializer. The lookup finds this typedef, and we then try to resolve it in order to determine whether it matches the current class. Whe

Re: [PATCH, rs6000] Update default loop peel limits

On Thu, Dec 6, 2012 at 3:15 PM, Pat Haugen wrote: > The following patch restores the old default limits for loop peeling that > were recently changed to 100 and caused a 20% degradation in 454.calculix. > > Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for trunk? > > -Pat > > >

[PATCH, rs6000] Update default loop peel limits

The following patch restores the old default limits for loop peeling that were recently changed to 100 and caused a 20% degradation in 454.calculix. Bootstrap/regtest on powerpc64-linux with no new regressions. Ok for trunk? -Pat 2012-12-06 Pat Haugen * config/rs6000/rs6000.c (rs60

Re: [PATCH] Don't drop DECL_INITIAL if -g for DWARF2+ (PR fortran/55395)

> Hi! > > This patch fixes both a correctness problem (bootstrap failure in > libgfortran for a couple of targets) and debug info quality issue. > The correctness issue is about the fact that clearing DECL_INITIAL > (well, setting it to error_mark_node is the same) in varpool_remove_node > is chan

[PATCH] Don't drop DECL_INITIAL if -g for DWARF2+ (PR fortran/55395)

Hi! This patch fixes both a correctness problem (bootstrap failure in libgfortran for a couple of targets) and debug info quality issue. The correctness issue is about the fact that clearing DECL_INITIAL (well, setting it to error_mark_node is the same) in varpool_remove_node is changing the decl'

Re: [PATCH, PR 55078] Let indirect inlining look at ipa-cp lattices

> Hi, > > the patch below re-stores a check in the inlining machinery that makes > sure growth estimates match the reality after inlining. However, in > order to do that, I had to teach indirect inlining to look at IPA-CP > data because that's what the inlining estimates do. Even though this > m

C++ PATCH for c++/54913 (error with static reference member and templates)

We build up a SCOPE_REF to remember that we saw a qualified-id in a template. We also want to convert_from_reference so that a use of a reference member decays to a non-reference. But we were doing them in the wrong order, so that the second operand of the SCOPE_REF was an INDIRECT_REF, which

Re: [PATCH, rs6000] Enable ASAN build on powerpc*-linux

On Thu, 2012-12-06 at 10:50 -0500, David Edelsohn wrote: > On Thu, Dec 6, 2012 at 9:46 AM, Peter Bergner wrote: > > >> That macro determines if GCC thinks -fsanitze=address is supported, > >> which it is not on AIX. The macro probably should be defined in sysv4.h, > >> not rs6000.c, and the func

[PATCH] Improve debug info for various cases where we drop location info on the floor (PR debug/55608)

Hi! This patch adds DW_AT_const_value or DW_AT_location for unused static vars (thus, not really modified and their DECL_INITIAL can be used for location/constant value info), and optimizes various cases using DW_OP_GNU_implicit_pointer (e.g. DW_OP_addr DW_OP_stack_value where symbol is either an

[PATCH] validate_failures.py: Fix performance regression

2012-12-06 Bernhard Reutner-Fischer * testsuite-management/validate_failures.py (IsInterestingResult): Fix performance regression --- Rephrasing the return statement was not a good idea, it regressed tremendously ;) ==> LOG-before <== real0m22.696s user0m19.953s sys

RE: [RFC] New feature to reuse one multilib among different targets

On Tue, 13 Nov 2012, Terry Guo wrote: > +@findex MULTILIB_REUSE > +@item MULTILIB_REUSE > +Sometimes it is desirable to reuse one existing multilib among different > +targets. Such kind of reuse can minimize the number of multilib variants. I don't think "among different targets" is the right wo

Property for vector lowering

Hello, this patch (for 4.9) introduces a property so we can check if vector operations have been lowered yet. It mimics the complex lowering property, and this required moving the -O0 vector lowering pass (otherwise it breaks many testcases with "covariant" in their name). The tree-ssa-forwp

Re: RFA: PATCH to build_array_type_1 for c++/55032 (array template argument)

On Thu, Dec 06, 2012 at 11:07:06AM -0500, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu. OK for 4.7 and 4.8? > > commit 429af9226fcba2450a8fbfcfba85801a38d0d129 > Author: Jason Merrill > Date: Thu Dec 6 10:21:25 2012 -0500 > > PR c++/55032 > * tree.c (build_array_type_1): Re-

RE: [Patch AArch64] Implement Vector Permute Support

> OK > > /Marcus Thanks Marcus, I've committed this and the follow-up patch to trunk and back-ported them to AArch64-4.7-branch. The back-port required back-porting the attached patch, which fixes up the expected behaviour of gcc/testsuite/gcc.dg/vect/slp-perm-8.c. After committing this as a p

Re: RFA: PATCH to build_array_type_1 for c++/55032 (array template argument)

.. looks like the patch fixes c++/55245 too. Thanks! Paolo.

RFA: PATCH to build_array_type_1 for c++/55032 (array template argument)

In this PR, strip_typedefs rebuilds an array type without any typedefs and then gets confused when the rebuilt type has a different TYPE_ALIGN than the typedef-using type. This happens because the rebuilt type was found in the type_hash_canon hash table, and was originally built before the ele

Re: [PATCH, rs6000] Enable ASAN build on powerpc*-linux

On Thu, Dec 6, 2012 at 9:53 AM, Jakub Jelinek wrote: > On i?86/x86_64 it is provided for all targets, but only some of the targets > build libsanitizer then. Either users get errors at compile time (missing > compiler support), or at link time (missing library support). > I think the compiler si

Re: [PATCH, rs6000] Enable ASAN build on powerpc*-linux

On Thu, Dec 6, 2012 at 9:46 AM, Peter Bergner wrote: >> That macro determines if GCC thinks -fsanitze=address is supported, >> which it is not on AIX. The macro probably should be defined in sysv4.h, >> not rs6000.c, and the function should not be defined appropriately. > > Ok, I can move the ma

Re: [PING^2] PR 54805: __gthread_tsd* in vxlib-tls.c

On 26-Nov-12 13:27, rbmj wrote: On 11/13/2012 10:22 PM, rbmj wrote: On 11/5/2012 12:57 PM, rbmj wrote: This removes warnings about implicit declarations and fixes one of the function calls in vxlib-tls.c for vxworks targets. I got the old prototypes from http://gcc.gnu.org/ml/gcc-patches/2005-

[AArch64] Add support for TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES hook.

Hi, This patch wires up TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES on AArch64 to allow for 64-bit or 128-bit vectorization if the preferred vector mode is not acceptable. The patch has been regression tested on aarch64-none-elf with no regressions. Thanks, James Greenhalgh --- gcc/ 2012-12-0

Re: [C++ PATCH] Fix build_noexcept_spec ICE (PR c++/54207)

OK. Jason

PING: [PATCH] PR sanitizer/55533: Can't bootstrap libsanitizer

On Thu, Nov 29, 2012 at 10:30 AM, H.J. Lu wrote: > Hi, > > Since libsanitizer is used for bootstrap and compiled with raw_cxx, > we need to use explicit -I for libstdc++-v3 header files in > libsanitizer. Otherwise, we will get > > libtool: compile: unrecognized option `-D_GNU_SOURCE' > libtool:

Re: [PATCH, PR 55590] Avoid more pessimistic alignments in SRA

On Thu, 6 Dec 2012, Martin Jambor wrote: > Hi, > > On Thu, Dec 06, 2012 at 10:35:04AM +0100, Richard Guenther wrote: > > Don't you want to use get_object_alignment_1 to record whether > > 'base' is for example at offset 3 of a 16-byte aligned object > > so that if 'offset' then makes the result a

Re: [PATCH, rs6000] Enable ASAN build on powerpc*-linux

On Thu, Dec 06, 2012 at 08:46:20AM -0600, Peter Bergner wrote: > On Thu, 2012-12-06 at 09:39 -0500, David Edelsohn wrote: > > On Wed, Dec 5, 2012 at 5:34 PM, Peter Bergner wrote: > > > * config/rs6000/rs6000.c (TARGET_ASAN_SHADOW_OFFSET): Define. > > > (rs6000_asan_shadow_offset):

Re: [PATCH, PR 55590] Avoid more pessimistic alignments in SRA

Hi, On Thu, Dec 06, 2012 at 10:35:04AM +0100, Richard Guenther wrote: > Don't you want to use get_object_alignment_1 to record whether > 'base' is for example at offset 3 of a 16-byte aligned object > so that if 'offset' then makes the result aligned you use > that alignment instead of the conserv

Re: [PATCH] Fix PR55599/sanitizer by disabling static libasan on darwin

Done, r194257. On Thu, Dec 6, 2012 at 12:04 PM, Konstantin Serebryany wrote: > On Thu, Dec 6, 2012 at 10:38 AM, Alexander Potapenko > wrote: >> In fact nothing prevents GCC from having a linkable static ASan runtime. > > Except (as Alex mentions) we are not going to support it. > I'll apply thi

Re: [PATCH, rs6000] Enable ASAN build on powerpc*-linux

On Thu, 2012-12-06 at 09:39 -0500, David Edelsohn wrote: > On Wed, Dec 5, 2012 at 5:34 PM, Peter Bergner wrote: > > * config/rs6000/rs6000.c (TARGET_ASAN_SHADOW_OFFSET): Define. > > (rs6000_asan_shadow_offset): New function. > > * config/rs6000/rs6000.h (FRAME_GROWS_DOWNWAR

Re: libsanitizer mege from upstream r169392

done, 194255. Thanks! --kcc On Thu, Dec 6, 2012 at 6:24 PM, Jakub Jelinek wrote: > On Thu, Dec 06, 2012 at 06:17:51PM +0400, Konstantin Serebryany wrote: >> Any objections? > > This is fine. > > Jakub

Re: [PATCH, rs6000] Enable ASAN build on powerpc*-linux

On Wed, Dec 5, 2012 at 5:34 PM, Peter Bergner wrote: > Below are the port changes to enable building ASAN on powerpc*-linux. > The libsanitizer changes required for powerpc*-linux have already been > committed. This passes bootstrap and regtesting with no regressions > and we also pass the two AS

C++ PATCH for c++/54947 (wrong error with lambda in init-list)

When we're parsing tentatively, we shouldn't do something, like requiring a constant-expression, that will produce an error. This patch delays checking whether the expression is constant until we know that we're actually looking at a designator. Tested x86_64-pc-linux-gnu, applying to trunk.

C++ PATCH for c++/55015 (undefined lambda conv op)

My earlier patch to change the linkage of the lambda conversion operator was wrong; the problem was that we were failing to mark members of a local class in a template as comdat. So I've fixed that and reverted the earlier change. Tested x86_64-pc-linux-gnu, applying to trunk and 4.7. commit

[PATCH][1/2] Make loop distribution handle loop nests

This is the first patch in an (unfinished) series to make loop distribution handle loop nests. This patch makes the loop copying infrastructure used by loop distribution and loop vectorization (slpeel_tree_duplicate_loop_to_edge_cfg and friends) handle loop nests. While being there I cut out all

Re: [C++ PATCH] Fix build_noexcept_spec ICE (PR c++/54207)

On Thu, Dec 06, 2012 at 09:07:43AM -0500, Jason Merrill wrote: > These are the only two possibilities for a boolean INTEGER_CST, so > let's assert that it's false if it isn't true. > > You can then leave the 'else' on the "if (expr == error_mark_node)". > > And here you don't need to check the va

C++ PATCH for c++/54653 (ICE with missing template-header)

In this PR, we have a partial specialization of a member of a partial specialization, and we were confused into thinking that we only needed one template-header. The parser.c hunk makes us generate the appropriate error. The pt.c hunks fix the compiler to deal with it properly if it had been

Re: libsanitizer mege from upstream r169392

On Thu, Dec 06, 2012 at 06:17:51PM +0400, Konstantin Serebryany wrote: > Any objections? This is fine. Jakub

Re: libsanitizer mege from upstream r169392

Any objections? On Wed, Dec 5, 2012 at 10:15 PM, Konstantin Serebryany wrote: > Hi, > > The attached patch is the libsanitizer merge from upstream r169392. > Among other things It fixes the darwin build. > > Automatically generated by libsanitizer/merge.sh > Tested with > rm -rf */{*/,}libsanitiz

C++ PATCH for c++/55564 (ICE with decltype of non-type template parameter)

In this PR the problem was that during deduction for the T(&)[N] function parameter we were trying to deduce the array bounds N first, but the type of N depends on T, so we need to deduce T first. This also makes sense from a left-to-right perspective. This broke with my instantiation-depende

Re: [C++ PATCH] Handle VECTOR_CSTs in adjust_temp_type (PR c++/55573)

On 12/06/2012 02:16 AM, Jakub Jelinek wrote: With Marc's recent changes to fold vector CONSTRUCTORs into VECTOR_CSTs if possible, we now ICE in adjust_temp_type, because the type of VECTOR_CST is not SCALAR_TYPE_P. Either we can handle VECTOR_CSTs directly (in that case ignore_overflows is also

Re: [C++ PATCH] Fix build_noexcept_spec ICE (PR c++/54207)

On 12/06/2012 02:24 AM, Jakub Jelinek wrote: + if (TREE_CODE (expr) == INTEGER_CST) +{ + if (operand_equal_p (expr, boolean_true_node, 0)) + return noexcept_true_spec; + else if (operand_equal_p (expr, boolean_false_node, 0)) + return noexcept_false_spec; +} These

Re: [i386] scalar ops that preserve the high part of a vector

>> Yes, the approach taken in this patch looks really good to me. There >> should be no code differences with your patch, but let's ask HJ for >> his opinion on intrinsics header changes. > > Hi Kirill, > > Can you take a look? Thanks. Hi guys, I like changes in intrinsics header. Thanks, K

[patch] cfglayout fixes

Hello, This patch has 3 parts: 1. Benign comment fixes. 2. Using DF_REF_REG_MEM_P idiom. Also benign. 3. Real bug fixes for cfglayout mode. For (3) the fixes are: - Pointers to the unlinked parts of the insns chain are not cleared, which results in complete RTL bodies being left not garbage-co

[PATCH, PR 55078] Let indirect inlining look at ipa-cp lattices

Hi, the patch below re-stores a check in the inlining machinery that makes sure growth estimates match the reality after inlining. However, in order to do that, I had to teach indirect inlining to look at IPA-CP data because that's what the inlining estimates do. Even though this makes indirect

[patch] PR55158 - segfault in sched-rgn.c

Hello, The problem in this PR is that new basic blocks can be created if the scheduler moves speculative insns and adds recovery code, but the bb_state* arrays are allocated only at the start of scheduling a region and are not set up to deal with changing last_basic_block. Fixed by resizing the a

Re: [PATCH] Add --with-build-config=bootstrap-asan support

On 2012.11.29 at 11:26 -0800, H.J. Lu wrote: > On Thu, Nov 29, 2012 at 11:06 AM, Jakub Jelinek wrote: > > On Thu, Nov 29, 2012 at 07:24:38PM +0100, Paolo Carlini wrote: > >> On 11/29/2012 06:36 PM, Tobias Burnus wrote: > >> >H.J. Lu wrote: > >> >>This patch adds --with-build-config=bootstrap-asan

Re: [PATCH] Remove dead code from fold_stmt_1

On Tue, 27 Nov 2012, Jakub Jelinek wrote: > On Tue, Nov 27, 2012 at 01:00:05PM +0100, Richard Biener wrote: > > > > This removes dead code as suggested by Jakub. > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > Looks as partial removal only. IMHO > gimple_stmt_iterator gsinex

Re: [PATCH, PR 55590] Avoid more pessimistic alignments in SRA

On Tue, 4 Dec 2012, Martin Jambor wrote: > Hi, > > when working at the IPA-SRA misalignment problems I have noticed that > the traditional intraprocedural SRA can also produce this when the > MEM_REF it is after is hidden below a handled component. Fortunately, > now that get_object_alignment lo

Re: Reduce complette unrolling & peeling limits

On Tue, 4 Dec 2012, Jan Hubicka wrote: > > > here is updated patch. It should get the bounds safe enough to not have > > > effect on codegen of complette unrolling. > > > > > > There is IMO no way to cut the walk of loop body w/o affecting codegen in > > > unrolling for size mode. The condition

Re: Patch ping

On Mon, 26 Nov 2012, Jakub Jelinek wrote: > - PR55137 fold reassociation fix > > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00636.html >

Re: [mudflap] fix infinite recursion in verbose trace

On Thu, Dec 6, 2012 at 5:02 AM, Alexandre Oliva wrote: > mudflap's free overrider, when verbose traces enabled, calls output > functions that, at least on the version of glibc I'm using, calls free > recursively. Since it happens to be free(NULL), it's quite easy to fix > this problem with the fo

Re: [PR libmudflap/53952] don't check access to non-mem decls

On Thu, Dec 6, 2012 at 4:59 AM, Alexandre Oliva wrote: > SRA (and perhaps other passes?) introduce “addressable” MEM_REFs to > variables that were not addressable at the time mudflap1 ran registering > valid memory ranges; when mudflap2 ran to emit the checks, it found such > MEM_REFs, marking the

Re: Minimize downward code motion during reassociation

On Tue, Nov 6, 2012 at 1:54 AM, Easwaran Raman wrote: > I am unable to figure out the right way to handle the debug > statements. What I tried was to find debug statements that use the SSA > name defined by the statement I moved (using SSA_NAME_IMM_USE_NODE) > and then moved them as well at the ri

Re: [asan] Handle bitfields in asan

On Wed, 5 Dec 2012, Jakub Jelinek wrote: > On Wed, Dec 05, 2012 at 05:10:56PM +0100, Richard Biener wrote: > > > This patch tries to handle bitfield accesses as if it were writes/reads > > > from the corresponding DECL_BIT_FIELD_REPRESENTATIVE. > > > Richard, does it make sense this way (the code

[PATCH] Bugfix: Additional parameter for canonicalize comparison

Hi, the attached patch fixes a problem I encountered with Richards patch adding an extvz expander to the s390 backend. According to its definition the CANONICALIZE_COMPARISON macro is allowed to modify the two operands as well as the comparison code in order to make a comparison valid or more eff

Re: [PATCH] Fix PR55599/sanitizer by disabling static libasan on darwin

On Thu, Dec 6, 2012 at 10:38 AM, Alexander Potapenko wrote: > In fact nothing prevents GCC from having a linkable static ASan runtime. Except (as Alex mentions) we are not going to support it. I'll apply this patch later (~today). --kcc > The reason for the static library being unusable is not