On Mon, Oct 15, 2012 at 11:25 PM, Wei Mi w...@google.com wrote:
Hi,
I create a patch to migrate llvm runtime to asan branch. The
configure.ac is a preliminary version and almost doesn't contain any
portability check. I build it and test my own small case only and it
works. Just send it out
This is a good start. Can you send a patch out without including
libasan so at least the toplevel parts can be reviewed easier?
Also the changelog entry for gcc.c go under the gcc/ChangeLog rather
than the toplevel one.
Thanks,
Andrew Pinski
Sure, I attach it. Thanks for pointing out the
Jakub,
I've noticed that the move_by_pieces loops keep iterating after there's no more
data to process.
I've added this assert to trigger an example in a gcc build:
...
Index: src/gcc/expr.c
===
--- src/gcc/expr.c (revision 191792)
Vladimir Makarov vmaka...@redhat.com writes:
On 12-10-15 4:25 PM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
Vladimir Makarov vmaka...@redhat.com writes:
After committing a patch yesterday to implement proposals from a
review, I found that GCC crashes on
On Mon, Oct 15, 2012 at 11:39 PM, Wei Mi w...@google.com wrote:
This is a good start. Can you send a patch out without including
libasan so at least the toplevel parts can be reviewed easier?
Also the changelog entry for gcc.c go under the gcc/ChangeLog rather
than the toplevel one.
The change to remove mode check looks good to me.
Not directly related to this bug but somehow related: the REE has
obvious conservativeness regarding partial redundancy (i.e., not all
reaching def has the bits properly extended). However, there are bugs
preventing elimination even with full
Hello,
On 31.07.2012 15:08, Andrey Belevantsev wrote:
Hello,
This PR is about wrong speculation of an insn that doesn't support storing
NaT bits done by the selective scheduler (more details in the PR audit
trail). The reason for this is the wrong one-liner patch committed last
year, the fix
Hi Steven, Jeff,
I found a flaw in original patch, which results in inaccurate register
pressure.
Here comes the updated patches, improving code size a little bit on
Thumb2/powerpc comparing to original patches.
Please review.
Thanks
2012-10-16 Bin Cheng bin.ch...@arm.com
* gcse.c:
Hello,
On 09.08.2012 17:19, Alexander Monakov wrote:
On Thu, 9 Aug 2012, Andrey Belevantsev wrote:
Hello,
The problem in question is uncovered by the recent speculation patch, it is in
the handling of expressions blocked by bookkeeping. Those are expressions
that become unavailable due to
Ping, again
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
--
Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
Palace Road, London SW1W 9TQ | Registered in England Number: 3977902
Hi,
I have just merged upstream gcc-4_7-branch on the aarch64-4.7-branch up to
r192444.
Thanks
Sofiane
On Tue, Oct 16, 2012 at 10:50 AM, Simon Baldwin wrote:
Ping, again
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
Probably you mean the revised patch here:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
The patch look OK to me but I can't approve it.
Technically you're
Hi,
I have just merged upstream trunk on the aarch64-branch up to r192445.
Thanks
Sofiane
Hi,
2012-09-26 Jorn Rennecke joern.renne...@arc.com
* loop-doloop.c (doloop_modify): Pass doloop_end pattern to
gen_doloop_begin.
* loop-doloop.c (doloop_optimize): Pass flag to indicate if loop is
entered at top to gen_doloop_end.
*
On 12/9/27 6:25 AM, Janis Johnson wrote:
On 09/26/2012 01:58 AM, Chung-Lin Tang wrote:
+/* { dg-do compile } */
+/* { dg-options -mthumb -O1 -march=armv5te -fno-omit-frame-pointer
-fno-forward-propagate } */
+/* { dg-require-effective-target arm_thumb1_ok } */
This test will fail to
Hello,
In RTL land it's not trivial to find a CALL rtx inside a CALL_INSN,
and code to find the CALL is duplicated in a few places. The attached
patch cleans this up.
Bootstrappedtested on powerpc64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
P.S. question: when is XEXP(call,0) _not_ a MEM?
As I'm not sure how to best do that I suggest we do a more proper RTL
DSE hack by adding a 'libcall-call-escape'-set which we can add to
instead of calling mark_addressable this late. We need to add all
partitions of a decl here, of course, and we need to query it from
can_escape.
That
In RTL land it's not trivial to find a CALL rtx inside a CALL_INSN,
and code to find the CALL is duplicated in a few places. The attached
patch cleans this up.
Bootstrappedtested on powerpc64-unknown-linux-gnu. OK for trunk?
Sure, thanks.
P.S. question: when is XEXP(call,0) _not_ a MEM?
I've scanned the documentation and there is no indication of any
preprocessor predefines or anything like that.
And keep in mind that __VIS__ is our very own invention.
Sun's compilers never predefined this.
Their makefiles do for various targets in the MediaLib sources, but that's
a
On Mon, Oct 15, 2012 at 3:26 PM, Steven Bosscher wrote:
On Mon, Oct 15, 2012 at 3:21 PM, Paolo Bonzini wrote:
Il 15/10/2012 14:53, Steven Bosscher ha scritto:
I think I've shown above that we're all looking at the wrong pass...
I think you have... so we want a patch like this?
I don't think
Hi Dominique,
Dominique Dhumieres wrote:
the test gfortran.dg/class_optional_1.f90 does not compile
...
but the code seems weird.
I concur – and believe that it is already covered by the other test
cases. Thus, I removed it.
The code gfortran.dg/class_optional_2.f90 compiles, but
the
On Tue, Oct 16, 2012 at 12:15 PM, Steven Bosscher wrote:
On Mon, Oct 15, 2012 at 3:26 PM, Steven Bosscher wrote:
On Mon, Oct 15, 2012 at 3:21 PM, Paolo Bonzini wrote:
Il 15/10/2012 14:53, Steven Bosscher ha scritto:
I think I've shown above that we're all looking at the wrong pass...
I think
Hi Tobias,
+ for (ref = e-ref; ref; ref = ref-next)
+{
+ if (ref-type == REF_COMPONENT
+ref-u.c.component-ts.type == BT_CLASS)
+ class_ref = ref;
+
+ if (ref-next == NULL)
+ break;
+}
... I guess the last if statement is not needed, since this
Diego Novillo dnovi...@google.com writes:
On Mon, Oct 15, 2012 at 11:55 AM, Ian Lance Taylor i...@google.com wrote:
In my opinion, supporting the full range of GCC testsuite annotations
means imposing a lot of mechanism that the Go testsuite does not
require. It would complicate the Go
On Mon, Oct 15, 2012 at 3:51 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 15 Oct 2012, Richard Biener wrote:
else if ((code == BIT_NOT_EXPR
TYPE_PRECISION (TREE_TYPE (cond)) == 1)
|| (code == BIT_XOR_EXPR
- integer_onep
On 2012-10-16 07:05 , Rainer Orth wrote:
Diego Novillo dnovi...@google.com writes:
On Mon, Oct 15, 2012 at 11:55 AM, Ian Lance Taylor i...@google.com wrote:
In my opinion, supporting the full range of GCC testsuite annotations
means imposing a lot of mechanism that the Go testsuite does not
Il 16/10/2012 12:35, Steven Bosscher ha scritto:
On Tue, Oct 16, 2012 at 12:15 PM, Steven Bosscher wrote:
On Mon, Oct 15, 2012 at 3:26 PM, Steven Bosscher wrote:
On Mon, Oct 15, 2012 at 3:21 PM, Paolo Bonzini wrote:
Il 15/10/2012 14:53, Steven Bosscher ha scritto:
I think I've shown above
Hi Tobias,
I did not yet appied you latest patch to gfortran, but I ran the new tests
with gfortran patched with the previous patch and both pass (manual
testing without option, but -fcoarray=single). Note that for
class_optional_1.f90, valgrind --leak-check=full gives
==45665== 4 bytes in 1
On Tue, Oct 16, 2012 at 11:39 AM, Eric Botcazou ebotca...@adacore.com wrote:
As I'm not sure how to best do that I suggest we do a more proper RTL
DSE hack by adding a 'libcall-call-escape'-set which we can add to
instead of calling mark_addressable this late. We need to add all
partitions of
Quoting Zdenek Dvorak rakd...@iuuk.mff.cuni.cz:
+ entered_at_top = loop_preheader_edge (loop)-dest == desc-in_edge-dest;
is equivalent to
+ entered_at_top = loop-header == desc-in_edge-dest;
But, I don't think it will do what you want. Loops are canonicalized so that
their latch blocks
On Tue, Oct 16, 2012 at 4:05 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
But importing different upstream testsuites with different annotation
systems allows them to make GCC maintainer's lives miserable? If this
trend continues, maintainers need to cope with several different
Richard Earnshaw wrote:
On 20/09/12 16:49, Ulrich Weigand wrote:
Richard Earnshaw wrote:
Hmm, this is going to cause bottlenecks on Cortex-A15: writing a Neon
single-precision register and then reading it back as a double-precision
value will cause scheduling problems.
[snip]
A
Tejas Belagod wrote:
Ulrich Weigand wrote:
The following patch implements this idea; it passes a basic regression
test on arm-linux-gnueabi. (Obviously this would need a lot more
testing on various platforms before getting into mainline ...)
Can you have a look whether this fixes the
Hi,
The loop appears to be entered at the top, yet both my original and your test
fail.
Looking what happens with your test in more detail, I find that
loop-latch == desc-in_edge-dest
is true, but forwarder_block_p (loop-latch) fails:
562 if (dest-loop_father-header ==
Ulrich Weigand wrote:
Tejas Belagod wrote:
Ulrich Weigand wrote:
The following patch implements this idea; it passes a basic regression
test on arm-linux-gnueabi. (Obviously this would need a lot more
testing on various platforms before getting into mainline ...)
Can you have a look whether
Quoting Zdenek Dvorak rakd...@iuuk.mff.cuni.cz:
no -- you should also test that latch contains no active insns.
I.e., factorize
out whatever forwarder_block_p does except for the test
(dest-loop_father-header == dest) test,
Like this?
* basic-block.h (forwarder_block_p_1):
Quoting Zdenek Dvorak rakd...@iuuk.mff.cuni.cz:
no -- you should also test that latch contains no active insns.
I.e., factorize
out whatever forwarder_block_p does except for the test
(dest-loop_father-header == dest) test,
Like this?
* basic-block.h (forwarder_block_p_1):
On Tue, Oct 16, 2012 at 4:30 PM, Joern Rennecke
joern.renne...@embecosm.com wrote:
Quoting Zdenek Dvorak rakd...@iuuk.mff.cuni.cz:
no -- you should also test that latch contains no active insns. I.e.,
factorize
out whatever forwarder_block_p does except for the test
On Sun, 14 Oct 2012, Manuel L?pez-Ib??ez wrote:
2012-10-14 Manuel L?pez-Ib??ez m...@gcc.gnu.org
PR c/53063
PR c/40989
gcc/
* optc-gen.awk: Handle new form of LangEnabledBy.
* opts.c (set_Wstrict_aliasing): Declare here. Make static.
* common.opt
This patch shows work-in-progress (read: implementation uglyness
hopefully to vanish ...) regarding to moving LTO type merging
work from WPA to compile stage.
The patch re-organizes lto_output_tree (the write_tree streamer
hook for LTO) in a way so that we output all tree fields
in easy to
On Mon, 15 Oct 2012, Manuel L?pez-Ib??ez wrote:
2012-10-15 Manuel L?pez-Ib??ez m...@gcc.gnu.org
PR c/53063
PR c/40989
* doc/options.texi (EnabledBy): Document new form.
* optc-gen.awk: Handle new form of EnabledBy.
* common.opt (Wunused-but-set-parameter):
On Mon, 15 Oct 2012, Michael Meissner wrote:
I think changing the names is safer - it's immediately obvious as a build
failure if you missed anything. If you have MASK_* names for bits in more
than one flags variable, there's a risk of accidentally testing a bit in
the wrong variable,
On Tue, 16 Oct 2012, Richard Biener wrote:
This patch shows work-in-progress (read: implementation uglyness
hopefully to vanish ...) regarding to moving LTO type merging
work from WPA to compile stage.
The patch re-organizes lto_output_tree (the write_tree streamer
hook for LTO) in a way
I've just committed this patch to aarch64-trunk to resolve an ICE in
aarch64_split_doubleword_move when attempting to split v-v moves.
/Marcus
2012-10-16 Marcus Shawcroft marcus.shawcr...@arm.com
* config/aarch64/aarch64-protos.h (aarch64_split_doubleword_move):
Rename to
On 10/16/2012 02:44 AM, Richard Sandiford wrote:
Vladimir Makarov vmaka...@redhat.com writes:
On 12-10-15 4:25 PM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
Vladimir Makarov vmaka...@redhat.com writes:
After committing a patch yesterday to implement
Hi,
this patch udpates go-frontend to deifine unreachable bultin I need for loop
and LTO optimizations. I also noticed that GO ignores existence of all flags
except for CONST and thus I synchronized the flags with C FE variants.
(I plan to use set_call_expr_flags in other FEs too)
Regtested
Hi,
this patch udpates Java frontend to declare __bulitin_unreachable and also
fixes flags of synchronize bulitins to match ones from C FE.
Regtested x86_64-linux, OK?
Honza
* builtins.c (define_builtin): Accept ECF flags and
use set_call_expr_flags.
On Mon, Oct 15, 2012 at 10:38:02AM +0200, Richard Biener wrote:
On Fri, Oct 12, 2012 at 8:16 PM, Jakub Jelinek ja...@redhat.com wrote:
Apparently vectorizable_load is another spot that could create vector
CONSTRUCTORs that wouldn't pass the new CONSTRUCTOR verification.
Fixed thusly,
Hi!
Now that SIZEOF_EXPR isn't folded immediately, e.g. REAL_TYPE can
be an argument of it, and tsubst_copy* doesn't handle that, but tsubst does.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2012-10-15 Jakub Jelinek ja...@redhat.com
PR c++/54844
Hi,
this patch add __buliltin_unreachable to Fortran FE and also cleans up the code
a bit
Bootstrapped/regtested x86_64-linux, OK?
Honza
* f95-lang.c (gfc_define_builtin): Use set_call_expr_flags.
(ATTR_NOTHROW_LEAF_MALLOC_LIST,
ATTR_CONST_NORETURN_NOTHROW_LEAF_LIST):
On Mon, Oct 15, 2012 at 10:48:13PM -0700, Xinliang David Li wrote:
Another error checking feature is to poison stack vars on entry and
exit of the lexical scope to catch uninit variable reference and out
of scope references:
S* sp;
{
S s;
sp = s;
}
.. *sp ...
This is
On Mon, Oct 15, 2012 at 11:39:52PM -0700, Wei Mi wrote:
--- gcc/gcc.c (revision 192487)
+++ gcc/gcc.c (working copy)
@@ -679,6 +679,7 @@ proper position among the other output f
%{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
%(mflib) STACK_SPLIT_SPEC \
On Tue, Oct 16, 2012 at 08:40:21AM +0200, Tom de Vries wrote:
2012-10-16 Tom de Vries t...@codesourcery.com
* expr.c (move_by_pieces, move_by_pieces_ninsns, can_store_by_pieces)
(store_by_pieces_1): Don't enter loop when no more data is left.
Okay.
Jakub
Hi!
Here is an updated patch, which emits also the shadow clearing sequence
at the end of function in the right spot.
2012-10-16 Jakub Jelinek ja...@redhat.com
* Makefile.in (asan.o): Depend on $(EXPR_H) $(OPTABS_H).
(cfgexpand.o): Depend on asan.h.
* asan.c: Include
Hi!
This is a WIP patch for globals protection.
I'm not filling names yet and has_dynamic_init is always
false (wonder how to figure it has_dynamic_init out, especially
with LTO, TYPE_ADDRESSABLE (TREE_TYPE (decl)) probably isn't it,
and for more I'm afraid we need a langhook).
---
Hi,
while looking into cases where loop-iv.c still deduce useful bounds that are not
recorded by tree level I noticed that we do not duplicate the bounds when
copying
the loop.
Fixed thus.
Bootstrapped/regtested x86_64-linux, OK?
Honza
* cfgloopmanip.c (copy_loop_info): New function.
Hi,
s/imlpies/implied/
Sent with AquaMail for Android
http://www.aqua-mail.com
On 15/10/12 11:03, Marcus Shawcroft wrote:
On 11/09/12 15:02, Chris Schlumberger-Socha wrote:
This patch adds predefines for AArch64 code models. These code models are
added as an effective target for the AArch64 platform.
I've committed this patch to aarch64-trunk.
/Marcus
.. and back
On 16/10/12 16:10, Marcus Shawcroft wrote:
I've just committed this patch to aarch64-trunk to resolve an ICE in
aarch64_split_doubleword_move when attempting to split v-v moves.
/Marcus
2012-10-16 Marcus Shawcroftmarcus.shawcr...@arm.com
* config/aarch64/aarch64-protos.h
On Mon, Oct 15, 2012 at 11:12 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Oct 15, 2012 at 10:48:13PM -0700, Xinliang David Li wrote:
Another error checking feature is to poison stack vars on entry and
exit of the lexical scope to catch uninit variable reference and out
of scope
On Tue, Oct 16, 2012 at 09:06:22AM -0700, Xinliang David Li wrote:
I don't get it. Clobber marks the end of lifetime of a variable so it
is safe to emit code to really clobber its value -- otherwise how
would clobber based slot sharing work?
If you at CLOBBER protect the var in the shadow mem
From: Eric Botcazou ebotca...@adacore.com
Date: Tue, 16 Oct 2012 12:10:51 +0200
I've scanned the documentation and there is no indication of any
preprocessor predefines or anything like that.
And keep in mind that __VIS__ is our very own invention.
Sun's compilers never predefined this.
Hi,
I seem to have uncovered what seems to be a bug with handling SUBREG (MEM) with
the MEM having side-effects while testing aarch64-4.7. This bug seems to be
latent on trunk.
Here is a test case reduced from gcc.c-torture/execute/scal-to-vec1.c.
#define vector(elcount, type) \
Subject: [PATCH][AArch64] Restrict usage of SBFIZ to valid range only
This fixes an issue where we were generating an SBFIZ with
operand 3 outside of the valid range (as determined by the
size of the destination register and the amount of shift).
My patch checks that the range is valid
On Tue, Oct 16, 2012 at 8:14 AM, Jan Hubicka hubi...@ucw.cz wrote:
this patch udpates go-frontend to deifine unreachable bultin I need for loop
and LTO optimizations. I also noticed that GO ignores existence of all flags
except for CONST and thus I synchronized the flags with C FE variants.
On 16/10/12 17:34, Ian Bolton wrote:
Subject: [PATCH][AArch64] Restrict usage of SBFIZ to valid range only
This fixes an issue where we were generating an SBFIZ with
operand 3 outside of the valid range (as determined by the
size of the destination register and the amount of shift).
My patch
Jan == Jan Hubicka hubi...@ucw.cz writes:
Jan this patch udpates Java frontend to declare __bulitin_unreachable
Jan and also fixes flags of synchronize bulitins to match ones from C
Jan FE.
Jan Regtested x86_64-linux, OK?
The java bits are ok.
Jan + /* Looping const or pure is imlpies by
On Tue, Oct 16, 2012 at 8:14 AM, Jan Hubicka hubi...@ucw.cz wrote:
this patch udpates go-frontend to deifine unreachable bultin I need for loop
and LTO optimizations. I also noticed that GO ignores existence of all
flags
except for CONST and thus I synchronized the flags with C FE
The way to do this is not to use the shadow memory, but to clobber
directly the variable itself with specified byte pattern -- though
error diagnostics won't be as nice.
To use shadow memory, the scope start marker is also needed.
David
On Tue, Oct 16, 2012 at 9:12 AM, Jakub Jelinek
Jan == Jan Hubicka hubi...@ucw.cz writes:
Jan this patch udpates Java frontend to declare __bulitin_unreachable
Jan and also fixes flags of synchronize bulitins to match ones from C
Jan FE.
Jan Regtested x86_64-linux, OK?
The java bits are ok.
Jan + /* Looping const or pure is
On 10/16/2012 01:44 AM, Bin Cheng wrote:
Hi Steven, Jeff,
I found a flaw in original patch, which results in inaccurate register
pressure.
Here comes the updated patches, improving code size a little bit on
Thumb2/powerpc comparing to original patches.
Please review.
Thanks
2012-10-16 Bin
On Tue, Oct 16, 2012 at 9:44 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hmm, I was not aware of these bits (and yes, I agree it is non-sence this
being
duplicated everywhere). I will add UNREACHABLE there. What about rest of the
change (i.e. adding the proper bits)?
I suppose it's basically
On Tue, Oct 16, 2012 at 9:44 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hmm, I was not aware of these bits (and yes, I agree it is non-sence this
being
duplicated everywhere). I will add UNREACHABLE there. What about rest of
the
change (i.e. adding the proper bits)?
I suppose it's
On Mon, Oct 15, 2012 at 5:28 AM, Aldy Hernandez al...@redhat.com wrote:
Here we have a store data race because noce_can_store_speculate_p()
incorrectly returns true. The problem is that memory_modified_in_insn_p()
returns true if an instruction *MAY* modify a memory location, but the store
On Tue, Oct 16, 2012 at 10:19:54AM -0700, Ian Lance Taylor wrote:
On Mon, Oct 15, 2012 at 5:28 AM, Aldy Hernandez al...@redhat.com wrote:
I don't see a reason to add this new function. I would just inline it
into noce_can_store_speculate_p, replacing the call to
memory_modified_in_p. And I'm
Tobias,
The previous class_optional_2.f90 runs after your commit, but it takes
~168s (so it may have run with the previous patch also, but I was not
patient enough to see it). The culprits are given by the following
profile:
+ 100.0%, start, a.out
| + 100.0%, main, a.out
| | + 100.0%, MAIN__,
Hi,
here is third revised version of the complette unroling changes. While working
on the RTL variant I noticed PR54937 and the fact that I was overly aggressive
on forcing single exit of the last iteration to be taken, because loop may
terminate
otherwise (by EH or by exitting the program).
On 10/16/2012 08:17 AM, Jan Hubicka wrote:
* builtins.c (define_builtin): Accept ECF flags and
use set_call_expr_flags.
(initialize_builtins): Update; add BULIT_IN_UNREACHALE.
* calls.c (set_call_expr_flags): New.
* tree.h (set_call_expr_flags): Declare.
OK,
Dominique,
Dominique Dhumieres wrote:
The previous class_optional_2.f90 runs after your commit, but it takes
~168s (so it may have run with the previous patch also, but I was not
patient enough to see it).
Here, it takes (current version) 2s to compile and 0.150s to run the
program. If I
On Tue, Oct 16, 2012 at 03:02:47PM +, Joseph S. Myers wrote:
That is:
1. Patch adding TARGET_FOO aliases for OPTION_FOO (small change to the awk
scripts and associated documentation, I expect).
2. Large, mechanical, automatically generated patch to change existing
OPTION_FOO users
This patch adds the clang thread safety warning flags as recognized
warning flags that do nothing, for command-line compatibility with
clang. Enclosed patch is for branches/google/gcc-4_6, I have
identical patches for google/gcc-4_7 and google/main.
Tested on linux x86.
--
DeLesley Hutchins |
Quoting Richard Sandiford rdsandif...@googlemail.com:
Joern Rennecke joern.renne...@embecosm.com writes:
2012-10-04 Joern Rennecke joern.renne...@embecosm.com
* final.c (get_attr_length_1): Use direct recursion rather than
calling get_attr_length.
On Tue, Oct 16, 2012 at 3:19 PM, Delesley Hutchins deles...@google.com wrote:
This patch adds the clang thread safety warning flags as recognized
warning flags that do nothing, for command-line compatibility with
clang. Enclosed patch is for branches/google/gcc-4_6, I have
identical patches
Yes, but that won't happen for a while yet.
On Tue, Oct 16, 2012 at 12:43 PM, Diego Novillo dnovi...@google.com wrote:
On Tue, Oct 16, 2012 at 3:19 PM, Delesley Hutchins deles...@google.com
wrote:
This patch adds the clang thread safety warning flags as recognized
warning flags that do
Attached patch applied.
2012-10-16 François Dumont fdum...@gcc.gnu.org
* include/debug/formatter.h (_Debug_msg_id): Add
__msg_bucket_index_oob.
* include/debug/macros.h (__glibcxx_check_bucket_index): New.
* include/debug/unordered_set (unordered_set::begin(size_type)):
Committed.
google/gcc-4_6: r192510.
google/gcc-4_7: r192511.
google/main: r192513.
On Tue, Oct 16, 2012 at 12:44 PM, Delesley Hutchins deles...@google.com wrote:
Yes, but that won't happen for a while yet.
On Tue, Oct 16, 2012 at 12:43 PM, Diego Novillo dnovi...@google.com wrote:
On Tue, Oct
On Tue, Oct 16, 2012 at 04:58:48PM +0200, Jakub Jelinek wrote:
@@ -2022,6 +2036,12 @@ assemble_variable (tree decl, int top_le
if (DECL_ALIGN (decl) BITS_PER_UNIT)
ASM_OUTPUT_ALIGN (asm_out_file, floor_log2 (DECL_ALIGN_UNIT (decl)));
assemble_variable_contents (decl, name,
ping!
2012/10/11 Janus Weil ja...@gcc.gnu.org:
Hi all,
here is an OOP patch for the above PR, which has two disconnected parts:
1) It fixes a problem with ASSOCIATED, when it is fed a CLASS-valued
function as argument (i.e. the ICE in the bug title). This is the
trans-intrinsic part of
Janus,
Your patch works as advertised without disturbing my pet bugs.
Just a nit pick: the double parentheses in
+ if ((CLASS_DATA (select_type_stack-selector)-attr.dimension
|| CLASS_DATA (select_type_stack-selector)-attr.codimension))
do not seem necessary.
Note for Paul: I
Looks good except for the following:
1) I am not sure if the stack slot sharing is handled correctly. If I
read the code correctly, the redzone var will be only created for the
representative variable in a partition -- will this lead to false
negatives? As I asked before, should stack slot
Vladimir Makarov vmaka...@redhat.com writes:
On 10/16/2012 02:44 AM, Richard Sandiford wrote:
Vladimir Makarov vmaka...@redhat.com writes:
On 12-10-15 4:25 PM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
Vladimir Makarov vmaka...@redhat.com writes:
Yes, that is true. But when you say if this trend continues you are
making a slippery slope argument that I don't think applies. To date,
the trend consists of a single example. We are discussing adding a
second example, and we may decide against it. There are no current
prospects of a
On Tue, Oct 16, 2012 at 7:58 AM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
This is a WIP patch for globals protection.
I'm not filling names yet and has_dynamic_init is always
false (wonder how to figure it has_dynamic_init out, especially
with LTO, TYPE_ADDRESSABLE (TREE_TYPE (decl))
On Tue, Oct 16, 2012 at 01:56:46PM -0700, Xinliang David Li wrote:
Looks good except for the following:
1) I am not sure if the stack slot sharing is handled correctly. If I
read the code correctly, the redzone var will be only created for the
representative variable in a partition -- will
On Tue, Oct 16, 2012 at 02:41:42PM -0700, Xinliang David Li wrote:
+bool
+asan_protect_global (tree decl)
+{
+ rtx rtl, symbol;
+ section *sect;
+
+ if (TREE_CODE (decl) != VAR_DECL
+ || DECL_THREAD_LOCAL_P (decl)
+ || DECL_EXTERNAL (decl)
+ ||
The powerpc port is running out of switches that set bits in target_flags, and
I am in the process of changing all of the switches to use a secondary flag
word that is HOST_WIDE_INT (at least 64-bits on powerpc). One of the changes
is that the options machinery changes all of the TARGET_xxx names
On Tue, 9 Oct 2012, Oleg Endo wrote:
This documents the new thread pointer built-ins in the SH www changes
for 4.8.
Thanks, Oleg.
I've got one change and one question:
+liAdded support for the built-in functions
+code__builtin_thread_pointer/code and
+
On Tue, Oct 16, 2012 at 2:33 PM, Eric Botcazou ebotca...@adacore.com wrote:
Yes, that is true. But when you say if this trend continues you are
making a slippery slope argument that I don't think applies. To date,
the trend consists of a single example. We are discussing adding a
second
On Tue, Oct 16, 2012 at 3:03 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Oct 16, 2012 at 02:41:42PM -0700, Xinliang David Li wrote:
+bool
+asan_protect_global (tree decl)
+{
+ rtx rtl, symbol;
+ section *sect;
+
+ if (TREE_CODE (decl) != VAR_DECL
+ ||
The problem is that the macro unwinder code is changing the original
diagnostic type and not restoring it, so the code detecting that we
ICE fails to abort, which triggers another ICE, and so on. But there
is no point in modifying the original diagnostic, we can simply create
a temporary copy and
1 - 100 of 119 matches
Mail list logo
