On Thu, Nov 01, 2012 at 10:01:31AM +0400, Dmitry Vyukov wrote:
> > For gimplification context, see above, would be better to just
> > emit gimple directly.
> > For func_calls and func_mops, I believe why you need two variables instead
> > of just one, and why the function can't just return a bool w
On 31 October 2012 20:06, Teresa Johnson wrote:
> On Wed, Oct 31, 2012 at 12:58 PM, Christophe Lyon
> wrote:
>> On 30.10.2012 17:59, Teresa Johnson wrote:
>>>
>>> On Tue, Oct 30, 2012 at 9:26 AM, Steven Bosscher
>>> wrote:
Hello,
Hot/cold partitioning is apparently a hot topi
On Tue, Oct 30, 2012 at 4:04 PM, Sharad Singhai wrote:
> Hi Jakub,
>
> My -fopt-info pass filtering patch
> (http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02704.html) is being
> reviewed and I hope to get this in by Nov. 5 for inclusion in gcc
> 4.8.0.
I just committed -fopt-info pass filtering pa
On Wed, Oct 31, 2012 at 01:13:28AM -0200, Alexandre Oliva wrote:
> From: Alexandre Oliva , Jakub Jelinek
>
> for gcc/ChangeLog
>
> PR debug/54693
> * tree-ssa-loop-ivopts.c (remove_unused_ivs): Emit debug temps
> for dropped IV sets.
Ok, thanks.
Jakub
> It was OK until revision 187042:
>
> 2012-05-02 Richard Guenther
>
> * tree.c (valid_constant_size_p): New function.
> * tree.h (valid_constant_size_p): Declare.
> * cfgexpand.c (expand_one_var): Adjust check for too large
> variables by using valid_consta
On Thu, 2012-11-01 at 02:31 -0400, Joern Rennecke wrote:
> gen_doloop_end_split creates a pattern that sets pc, hence emit_jump_insn
> has to be used instead of emit_insn.
>
> Committed as obvious.
I'd like to add a test case for this.
Attached patch was tested with
make -k check-gcc RUNTESTFLAG
> This patch tries to fix this problem by resetting the source location
> when moving instructions to another BB. This can greatly improve the
> debuggability of optimized code. For the attached unittest. Without
> the patch, the debugger will always jump into line 14 even when the
> branch at line
Quoting Oleg Endo :
I'd like to add a test case for this.
Attached patch was tested with
make -k check-gcc RUNTESTFLAGS="sh.exp=pr55160.c --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
OK to install?
That'll be for the SH maintainers to decide.
However,
On Fri, Oct 26, 2012 at 04:30:41AM -0200, Alexandre Oliva wrote:
> From: Alexandre Oliva
>
> for gcc/ChangeLog
>
> PR debug/54693
> * tree-ssa-threadedge.c (thread_around_empty_block): Copy
> debug temps from predecessor before threading.
As can be seen on test-tgmath2.i, unf
On Thu, 2012-11-01 at 05:18 -0400, Joern Rennecke wrote:
> Quoting Oleg Endo :
>
> > I'd like to add a test case for this.
> >
> > Attached patch was tested with
> > make -k check-gcc RUNTESTFLAGS="sh.exp=pr55160.c --target_board=sh-sim
> > \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/
Quoting Oleg Endo :
I'm using:
/* { dg-skip-if "" { "sh*-*-*" } { "-m5*"} { "" } } */
Sorry, I mentally mixed up the arguments.
Oleg Endo wrote:
> I'd like to add a test case for this.
>
> Attached patch was tested with
> make -k check-gcc RUNTESTFLAGS="sh.exp=pr55160.c --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
>
> OK to install?
OK.
Regards,
kaz
Joern Rennecke writes:
> Quoting Richard Sandiford :
>
>> But what I'm trying to get at is: why can't the backend tell
>> shorten_branches about the amount of alignment/misalignment
>> that the target wants, and where? Via an attribute or a hook,
>> I don't mind which. But it should be declarati
> Sounds great, (I think) this is something I've longed to see
> ever since I saw the iterator machinery (thanks, Richard S!) and
> wanted to do structural replacements just as easily.
Thanks!
> But... I don't really understand it, so here's some feedback on
> the documentation: Regarding the lang
On Thu, Nov 01, 2012 at 12:52:04AM -0700, Sharad Singhai wrote:
> On Tue, Oct 30, 2012 at 4:04 PM, Sharad Singhai wrote:
> > Hi Jakub,
> >
> > My -fopt-info pass filtering patch
> > (http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02704.html) is being
> > reviewed and I hope to get this in by Nov. 5
Hi,
this check I added into inline_call last week has cought among other
interesting bugs an an ipa-cp/ipa-prop issue that Martin will fix only later
this or next week (tracked as PR55078).
I am disabling the sanity check for time being because it also triggers with
-O3 bootstrap on some configura
richi,
I would like you to respond to at least point 1 of this email. In it
there is code from the rtl level that was written twice, once for the
case when the size of the mode is less than the size of a HWI and once
for the case where the size of the mode is less that 2 HWIs.
my patch cha
Hello world,
after the dicsussion on c.l.f, it become clear that passing a DO loop
variable to an INTENT(OUT) or INTENT(INOUT) dummy argument is an error.
The attached patch throws an error for both cases.
I chose to issue the errors as a front-end pass because we cannot check
for formal argumen
Hi Thomas,
there are already lots of places that check for do variables,
gfc_check_do_variable() does the hard work. Couldn't the same result be
achieved in a much simpler way during resolution?
Cheers,
- Tobi
On 2012-11-01 13:58, Thomas Koenig wrote:
Hello world,
after the dicsussion on
On Thu, Nov 1, 2012 at 8:28 AM, Jakub Jelinek wrote:
> How was that change tested? I'm seeing thousands of new UNRESOLVED
> failures, of the form:
> spawn -ignore SIGHUP /usr/src/gcc/obj415/gcc/xgcc -B/usr/src/gcc/obj415/gcc/
> /usr/src/gcc/gcc/testsuite/gcc.target/i386/branch-cost1.c
> -fno-d
Kenneth Zadeck writes:
> I would like you to respond to at least point 1 of this email. In it
> there is code from the rtl level that was written twice, once for the
> case when the size of the mode is less than the size of a HWI and once
> for the case where the size of the mode is less that
On 11/01/2012 09:10 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
I would like you to respond to at least point 1 of this email. In it
there is code from the rtl level that was written twice, once for the
case when the size of the mode is less than the size of a HWI and once
for the ca
anyway richard, it does not answer the question as to what you are going
to do with a typedef foo<2>.
the point of all of this work by me was to leave no traces of the host
in the way the compiler works.
instantiating a specific size of the double-ints is not going to get you
there.
kenny
O
On 10/29/2012 10:07 PM, rbmj wrote:
I get a clean build on my end... no stdarg.h issues. Build
characteristics are given in the previous email.
On 10/29/2012 4:26 PM, rbmj wrote:
The build does eventually die in libstdc++-v3, but that's not due to
these changes (it gives me an internal compile
On Fri, Aug 24, 2012 at 04:13:20PM +0200, Rainer Orth wrote:
> Jack Howarth writes:
>
> >Currently the new testcase for gcc.target/i386/pr53249.c is failing
> > on darwin due to the absence of -mx32 support on that target. The following
> > patch skips this testcase on darwin. Tested on x86_6
Hi Tobias,
Hi Thomas,
there are already lots of places that check for do variables,
gfc_check_do_variable() does the hard work.
gfc_check_do_uses gfc_state_stack, which is built up (and
destroyed) during parsing. This is too early because we
need to have the formal arglists resolved before
I am really sorry about that. I am looking and will fix the breakage
or revert the patch shortly.
Thanks,
Sharad
On Thu, Nov 1, 2012 at 5:28 AM, Jakub Jelinek wrote:
> On Thu, Nov 01, 2012 at 12:52:04AM -0700, Sharad Singhai wrote:
>> On Tue, Oct 30, 2012 at 4:04 PM, Sharad Singhai wrote:
>> >
On 2012-10-31 18:47 , Lawrence Crowl wrote:
2012-10-31 Lawrence Crowl
* ebitmap.h: Remove unused.
* ebitmap.c: Remove unused.
* Makefile.in: Remove ebitmap.h and ebitmap.c.
* sbitmap.h (SBITMAP_SIZE_BYTES): Move to source file.
(SET_BIT_WITH_POPCOUNT):
On 2012-10-31 13:43 , Lawrence Crowl wrote:
Rename the EXECUTE_IF_SET_IN_SBITMAP macro to EXECUTE_IF_SET_IN_BITMAP. Its
implementation is now identical to that in bitmap.h. To prevent redefinition
errors, both definitions are now guarded by #ifndef. An alternate strategy
is to simply include
On 2012-10-31 13:41 , Lawrence Crowl wrote:
This patch normalizes more bitmap function names.
sbitmap.h
TEST_BIT -> bitmap_bit_p
SET_BIT -> bitmap_set_bit
I wonder if it wouldn't it be more consistent if TEST_BIT became
bitmap_test_bit() ? I never particularly liked the lispy *
On Thu, Nov 1, 2012 at 1:52 AM, Eric Botcazou wrote:
>> This patch tries to fix this problem by resetting the source location
>> when moving instructions to another BB. This can greatly improve the
>> debuggability of optimized code. For the attached unittest. Without
>> the patch, the debugger wi
Hi Robert,
On Thu, Nov 1, 2012 at 6:35 AM, rbmj wrote:
> and now my patches will build on top of
> trunk. Bruce, can you give steps on how to reproduce the error you
> reported?
rm -rf gcc-bld gcc-ins
cp -l gcc-svn gcc-bld
pfx=$PWD/gcc-ins
cd gcc-bld
./configure --enable-languages=c,c++ --p
> For optimized code, there are many optimizations that can break
> coverage info. Code motion is one of them. This patch actually tries
> to fix the broken coverage info, as illustrated by the unittest.
No, you seems to be misunderstanding what coverage means. For coverage to be
correct, it is
Richard Sandiford writes:
> As is probably obvious, I don't agree FWIW. It seems like an unnecessary
> complication without any clear use. Especially since the number of
> significant HWIs in a wide_int isn't always going to be the same for
> both operands to a binary operation, and it's not cle
Hello,
this patch adds support for VEC_COND_EXPR to tree-vect-generic.c. It
doesn't try to use vectors of smaller size and jumps straight to
elementwise operations, so there is margin for improvements, but it seemed
better to have something asap that at least compiles.
For the testsuite: the
On Wed, Oct 31, 2012 at 11:27 PM, Jakub Jelinek wrote:
> On Wed, Oct 31, 2012 at 11:00:17PM -0700, Xinliang David Li wrote:
>> > + /* Below are things we do not instrument
>> > + (no possibility of races or not implemented yet). */
>> > + if (/* Compiler-emitted artificial variables. */
>>
> I would like to work on debugging this, but it's hard without test cases...
Maybe the files I attached to my PR55121 could help you in this respect?
Your "sanity checking" patching does complain with these input files.
Christophe.
If the macro ASSEMBLER_DIALECT is defined, characters '{', '}' and '|'
in assembler code (both in asm() and output templates of machine
description) are handled as delimiters of alternative assembler syntax
variants.
This patch enables printing '{', '}' and '|' characters in assembler
code by esc
I found the problem and the following patch fixes it. The issue with
my testing was that I was only looking at 'FAIL' lines but forgot to
tally the 'UNRESOLVED' test cases, the real symptoms of my test
problems. In any case, I am rerunning the whole testsuite just to be
sure.
Assuming tests pass
On Thu, Nov 1, 2012 at 12:40 PM, Sharad Singhai wrote:
> I found the problem and the following patch fixes it. The issue with
> my testing was that I was only looking at 'FAIL' lines but forgot to
> tally the 'UNRESOLVED' test cases, the real symptoms of my test
> problems. In any case, I am rer
Hi, Eric,
I see your point. How about we guard these changes with a flag, say
-gless-jumpy, so that people can always choose between better coverage
and less jumpy gdb behavior (it's also important for some other
clients like AutoFDO). I will have a series of patches to follow soon
that can be gua
On Wed, Oct 31, 2012 at 4:02 PM, Steven Bosscher wrote:
> On Tue, Oct 30, 2012 at 10:43 PM, Teresa Johnson wrote:
>> Sure, I will give this a try after your verification patch tests
>> complete. Does this mean that the patch you posted above to
>> force_nonfallthru_and_redirect is no longer needed
On 11/1/12, Diego Novillo wrote:
> On 2012-10-31 13:41 , Lawrence Crowl wrote:
>> This patch normalizes more bitmap function names.
>>
>>sbitmap.h
>>
>> TEST_BIT -> bitmap_bit_p
>> SET_BIT -> bitmap_set_bit
>
> I wonder if it wouldn't it be more consistent if TEST_BIT became
> bitmap
Quoting Richard Sandiford :
OK with those changes for the rtl bits. Can't approve the generator
stuff though.
Can you build machinery maintainers also review gen* and *.def patches,
of this patch ( http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02897.html ).
or are you strictly limited to *.in
On 11/1/12, Diego Novillo wrote:
> On 2012-10-31 13:43 , Lawrence Crowl wrote:
> > Rename the EXECUTE_IF_SET_IN_SBITMAP macro to
> > EXECUTE_IF_SET_IN_BITMAP. Its implementation is now identical to
> > that in bitmap.h. To prevent redefinition errors, both definitions
> > are now guarded by #ifn
On Thu, Nov 1, 2012 at 9:44 AM, Diego Novillo wrote:
> On Thu, Nov 1, 2012 at 12:40 PM, Sharad Singhai wrote:
>> I found the problem and the following patch fixes it. The issue with
>> my testing was that I was only looking at 'FAIL' lines but forgot to
>> tally the 'UNRESOLVED' test cases, the r
Hi Jakub,
I would like to get the fission implementation in before stage 1. It
has been under review for some time, and is awaiting another round of
review now.
More info here:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02684.html
Sterling
On 11/1/12, Diego Novillo wrote:
> On 2012-10-31 18:47 , Lawrence Crowl wrote:
>> 2012-10-31 Lawrence Crowl
>>
>> * ebitmap.h: Remove unused.
>> * ebitmap.c: Remove unused.
>> * Makefile.in: Remove ebitmap.h and ebitmap.c.
>> * sbitmap.h (SBITMAP_SIZE_BYTES): Move to source
On Thu, Nov 1, 2012 at 10:06 AM, Dmitry Vyukov wrote:
> On Thu, Nov 1, 2012 at 7:47 PM, Xinliang David Li
> wrote:
>>
>> On Wed, Oct 31, 2012 at 11:27 PM, Jakub Jelinek wrote:
>> > On Wed, Oct 31, 2012 at 11:00:17PM -0700, Xinliang David Li wrote:
>> >> > + /* Below are things we do not instrum
On Thu, Nov 1, 2012 at 11:16 AM, Dmitry Vyukov wrote:
> On Thu, Nov 1, 2012 at 10:14 PM, Dmitry Vyukov wrote:
>>>
>>> >> > On Wed, Oct 31, 2012 at 11:00:17PM -0700, Xinliang David Li wrote:
>>> >> >> > + /* Below are things we do not instrument
>>> >> >> > + (no possibility of races or not i
On Thu, Nov 1, 2012 at 2:11 PM, Xinliang David Li wrote:
> The TREE_ADDRESSABLE check seems redundant -- if the var_decl (instead
> of ssa name) appears in the assignment, why would it not be
> 'addressable'? And being addressable does not mean it is address taken
> either.
Yes, it does mean tha
On Thu, Nov 01, 2012 at 11:11:13AM -0700, Xinliang David Li wrote:
> But it skips those globals without static storage and marked as not
> addressable.
>
> It seems to me you want to skip all stack local variables that are not
> address escaped. Without address escape analysis, the address taken
I applied the change below, adjusting to Richi's name change and
some (announced?) change on the SUSE web infrastructure side (which
does a permanent redirect).
On a related note, Tobias,
http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/
now gives an "Internal Server Error".
Gerald
Applied.
Gerald
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.128
diff -u -3 -p -r1.128 changes.html
--- changes.html8 Oct 2012 08:54:49 - 1.128
+++ changes.h
For the following case:
int foo()
{
int a[100];
// use 'a' as a[i]
...
}
Assuming there is no assignment of the form p = &a[i] in the source,
variable 'a' still will be allocated in stack and its address is is
needed. Is the addressable bit set for 'a'? If yes, then it is not
the sa
Something tells me, nobody(?) is really doing the kind of regular
testing that we once envisioned, but while we have the page, let's
at least make sure the link works.
Anyone has been using a newer version and wants to update the
description?
Gerald
Index: testing-blitz.html
Quoting Richard Sandiford :
> But I think extending the FSM from just being an on-the-fly
transformatino during final (as for ARM) to something that happens
earlier is a pretty major step in terms of the interface between the
backend and the rest of GCC. There are then undocumented restriction
On Thu, Nov 01, 2012 at 11:32:01AM -0700, Xinliang David Li wrote:
> For the following case:
>
> int foo()
> {
>int a[100];
>
> // use 'a' as a[i]
> ...
> }
>
> Assuming there is no assignment of the form p = &a[i] in the source,
> variable 'a' still will be allocated in stack and it
That is exactly related to tsan -- it should skip local variable that
is not address taken (though still addressable, which by addressable,
it means the variable has a memory home).
The problem is that if 'addressable' bit is not equivalent to 'address
taken', it will be too conservative to use it
The following patch fixes the second test of PR55150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55150
The patch was successfully bootstrapped on x86/x86-64.
Committed as rev. 193065.
2012-11-01 Vladimir Makarov
PR middle-end/55150
* lra-constraints.c (lra_constraints): Check
On Thu, Nov 01, 2012 at 11:57:21AM -0700, Xinliang David Li wrote:
> That is exactly related to tsan -- it should skip local variable that
> is not address taken (though still addressable, which by addressable,
> it means the variable has a memory home).
>
> The problem is that if 'addressable' bi
Applied.
Gerald
2012-10-31 Gerald Pfeifer
* papers/nosb.html: Remove reference to sources.redhat.com.
Index: papers/nosb.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/java/papers/nosb.html,v
retrieving revision 1.4
diff -u
On Thu, Nov 1, 2012 at 12:16 PM, Jakub Jelinek wrote:
> On Thu, Nov 01, 2012 at 11:57:21AM -0700, Xinliang David Li wrote:
>> That is exactly related to tsan -- it should skip local variable that
>> is not address taken (though still addressable, which by addressable,
>> it means the variable has
From: dnovillo
This patch merely imports the initial state of asan as it was in the
Google branch.
It provides basic infrastructure for asan to instrument memory
accesses on the heap, at -O3. Note that it supports neither stack nor
global variable protection.
The rest of the patches of the set
From: jakub
This patch defines a new asan_shadow_offset target macro, instead of
having a mere macro in the asan.c file. It becomes thus cleaner to
define the target macro for targets that supports asan, namely x86 for
now. The ASAN_SHADOW_SHIFT (which, along with the asan_shadow_offset
constan
From: wmi
It appeared that we were forgetting to protect global variables that
are already 32 bytes aligned. Fixed thus.
* varasm.c (assemble_variable): Set asan_protected even
for decls that are already ASAN_RED_ZONE_SIZE or more
bytes aligned.
git-svn-id: svn+ssh://gc
From: dnovillo
Following a discussion we had on this list, this patch renames the
file tree-asan.* into asan.*.
* asan.c: Rename from tree-asan.c.
Update all users.
* asan.h: Rename from tree-asan.h
Update all users.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/bran
From: dodji
This patch splits a new create_cond_insert_point_before_iter function
out of build_check_stmt, to be used by a later patch.
Tested by running cc1 -fasan on the test program below with and
without the patch and by inspecting the gimple output to see that
there is no change.
void
foo
From: jakub
This patch defines a new asan pass gate that is activated at -O0, in addition
to the -O3 level at which it was initially activated. The patch also
does some comment cleanups here and there.
* asan.c (build_check_stmt): Rename join_bb variable to else_bb.
(gate_asan_O
From: jakub
After the previous patches uncovered the fact a NOTE_INSN_BASIC_BLOCK
could show up in the middle of a basic block and thus violating an
important invariant. THe cfgexpand.c hunk fixes that.
Then it appeared that we could get tree sharing violation if
build_check_stmt doesn't unshar
From: Dodji Seketeli
Hello,
The set of patches following this message represents the work that
happened on the asan branch to build up the Address Sanitizer work
started in the Google branch.
Address Sanitizer (aka asan) is a memory error detector. It finds
use-after-free and {heap,stack,globa
From: dodji
This patch makes build_check_stmt accept its memory access parameter
to be an SSA name. This is useful for a subsequent patch that will
re-use.
Tested by running cc1 -fasan on the program below with and without the
patch and inspecting the gimple output to see that there is no chang
From: jakub
This patch cleanups the instrumentation code generation by emitting
GIMPLE directly, as opposed to emitting GENERIC tree and then
gimplifying them. It also does some cleanups here and there
* Makefile.in (GTFILES): Add $(srcdir)/asan.c.
* asan.c (shadow_ptr_types): N
From: jakub
This patch implements the protection of stack variables.
To understand how this works, lets look at this example on x86_64
where the stack grows downward:
int
foo ()
{
char a[23] = {0};
int b[2] = {0};
a[5] = 1;
b[1] = 2;
return a[5] + b[1];
}
For this function
From: jakub
This patch implements the protection of global variables.
The basic idea is to insert a red zone between two global variables
and install a constructor function that calls the asan runtime to do
the populating of the relevant shadow memory regions at load time.
So the patch lays out
From: dodji
This patch instruments many memory access patterns through builtins.
Basically, for a call like:
__builtin_memset (from, 0, n_bytes);
the patch would only instrument the accesses at the beginning and at
the end of the memory region [from, from + n_bytes]. This is the
strategy
The name loc_t is too enticing for developers to avoid, but it
unfortunately conflicts with a visible symbol in an AIX header file,
which repeatedly causes conflicts. This patch poisons the symbols in
GCC system.h to prevent developers from using it.
Bootstrapped on powerpc-ibm-aix7.1.0.0
Okay?
Hi,
Here is the patch to change libasan to libsanitizer and reorganize the
directory. I divided the patch into three parts for review.
patch.part1.txt: Contains the changes in the outermost level.
patch.part2.txt.bz2: Remove libasan
patch.part3.txt.bz2: Add libsanitizer
Is it ok for asan branch?
Will it be easier if you just rolled back your previous libasan
library changes, and resubmit it with the restructured directory?
David
On Thu, Nov 1, 2012 at 1:17 PM, Wei Mi wrote:
> patch.part2.txt.bz2 and patch.part3.txt.bz2 are still too big.
>
> Divide patch.part2.txt.bz2 into two parts:
>
> From: Steven Bosscher
> Date: Sun, 28 Oct 2012 19:33:29 +0100
> On Mon, Oct 22, 2012 at 11:09 PM, Jakub Jelinek wrote:
> > On Mon, Oct 22, 2012 at 10:51:43PM +0200, Steven Bosscher wrote:
> > Wouldn't it be way cheaper to just export dfs_find_deadend from cfganal.c
> > and call it in calc_dfs_t
Yes. That will be easier and clearer. The patch is too big.
Thanks,
Wei.
On Thu, Nov 1, 2012 at 1:19 PM, Xinliang David Li wrote:
> Will it be easier if you just rolled back your previous libasan
> library changes, and resubmit it with the restructured directory?
>
> David
>
> On Thu, Nov 1, 201
On Thu, Nov 01, 2012 at 01:19:42PM -0700, Xinliang David Li wrote:
> Will it be easier if you just rolled back your previous libasan
> library changes, and resubmit it with the restructured directory?
I think better would be if you didn't apply it as a patch with lots of svn
add/svn rm commands, b
that sounds good to me.
David
On Thu, Nov 1, 2012 at 1:31 PM, Jakub Jelinek wrote:
> On Thu, Nov 01, 2012 at 01:19:42PM -0700, Xinliang David Li wrote:
>> Will it be easier if you just rolled back your previous libasan
>> library changes, and resubmit it with the restructured directory?
>
> I th
On Thu, Nov 01, 2012 at 11:35:42PM +0400, Dmitry Vyukov wrote:
> Wow! It's cool!
> Is it costly to compute?
No, it is just a couple of instructions and bitmap_bit_p test.
Jakub
On Thu, Nov 01, 2012 at 12:34:54PM -0700, Xinliang David Li wrote:
> On Thu, Nov 1, 2012 at 12:16 PM, Jakub Jelinek wrote:
> > On Thu, Nov 01, 2012 at 11:57:21AM -0700, Xinliang David Li wrote:
> >> That is exactly related to tsan -- it should skip local variable that
> >> is not address taken (th
On Thu, Nov 1, 2012 at 1:47 PM, Jakub Jelinek wrote:
> On Thu, Nov 01, 2012 at 12:34:54PM -0700, Xinliang David Li wrote:
>> On Thu, Nov 1, 2012 at 12:16 PM, Jakub Jelinek wrote:
>> > On Thu, Nov 01, 2012 at 11:57:21AM -0700, Xinliang David Li wrote:
>> >> That is exactly related to tsan -- it sh
On Thu, Nov 01, 2012 at 09:26:25PM +0100, Hans-Peter Nilsson wrote:
> > Attached patch was bootstrapped&tested on
>
> gcc/
> PR tree-optimization/55018
> * basic-block.h (dfs_find_deadend): New prototype.
> * cfganal.c (dfs_find_deadend): No longer static. Use bitmap
> ins
Attached patch applied.
2012-11-01 François Dumont
* include/bits/hashtable_policy.h (__details::_Before_begin<>):
New, combine a base node instance and an allocator.
* include/bits/hashtable.h (_Hashtable<>::_M_node_allocator): Remove.
(_Hashtable<>::_M_before_begin): Rename
On Thu, Nov 01, 2012 at 01:57:40PM -0700, Xinliang David Li wrote:
> I looked at it pretty late in the pipeline -- during cfgexpand and I
> had specified -O2 in the command line.
That was too late, ivopts pass (after pre where tsan pass was put around)
marks it TREE_ADDRESSABLE again, because it c
Hello,
this patch makes gimple checking of vector comparisons more strict by
ensuring that it doesn't return a boolean. It also fixes a bug that this
check detected in fold-const.c: for (void)(x<0), the C front-end was
calling fold_unary_loc on the conversion to void, which was then converted
Right -- I found the same thing, it is the ivopt that resets it -- the
IV opt pass should have a TODO_update_address_taken.
thanks,
David
On Thu, Nov 1, 2012 at 2:07 PM, Jakub Jelinek wrote:
> On Thu, Nov 01, 2012 at 01:57:40PM -0700, Xinliang David Li wrote:
>> I looked at it pretty late in th
On Thu, Nov 1, 2012 at 2:17 PM, Wei Mi wrote:
> Thanks for the suggestion!
>
> The planned svn commands will be:
>
> svn mv libasan libsanitizer
> svn add libsanitizer/asan
> svn add libsanitizer/tsan
Probably keep the tsan creation out of this patch.
David
> cd libsanitizer
> for i in `ls asan
On Thu, Nov 01, 2012 at 02:19:43PM -0700, Xinliang David Li wrote:
> Right -- I found the same thing, it is the ivopt that resets it -- the
> IV opt pass should have a TODO_update_address_taken.
That wouldn't change anything. The IVopts pass adds some_ptr = &a[0];
to the IL, so a is then address
On Thu, Nov 1, 2012 at 10:19 AM, Teresa Johnson wrote:
> On Wed, Oct 31, 2012 at 4:02 PM, Steven Bosscher
> wrote:
>> On Tue, Oct 30, 2012 at 10:43 PM, Teresa Johnson wrote:
>>> Sure, I will give this a try after your verification patch tests
>>> complete. Does this mean that the patch you poste
> On Thu, Nov 01, 2012 at 09:26:25PM +0100, Hans-Peter Nilsson wrote:
> > > Attached patch was bootstrapped&tested on
> >
> > gcc/
> > PR tree-optimization/55018
> > * basic-block.h (dfs_find_deadend): New prototype.
> > * cfganal.c (dfs_find_deadend): No longer static. Use bitmap
> >
On Tue, Oct 30, 2012 at 10:48 AM, Steven Bosscher wrote:
> On Tue, Oct 30, 2012 at 6:20 AM, Teresa Johnson wrote:
>> Index: bb-reorder.c
>> ===
>> --- bb-reorder.c(revision 192692)
>> +++ bb-reorder.c(working copy)
>>
On Thu, Nov 1, 2012 at 6:47 AM, Jack Howarth wrote:
> On Fri, Aug 24, 2012 at 04:13:20PM +0200, Rainer Orth wrote:
>> Jack Howarth writes:
>>
>> >Currently the new testcase for gcc.target/i386/pr53249.c is failing
>> > on darwin due to the absence of -mx32 support on that target. The followin
It is not always true though -- only when the array address is picked
by the pass to be the induction variable.
David
On Thu, Nov 1, 2012 at 2:24 PM, Jakub Jelinek wrote:
> On Thu, Nov 01, 2012 at 02:19:43PM -0700, Xinliang David Li wrote:
>> Right -- I found the same thing, it is the ivopt that
On Thu, Nov 1, 2012 at 10:26 PM, Teresa Johnson wrote:
> I'll do some testing of the fix below, but do you have any comments on
> the correctness or the potential issue I raised (see my note just
> below the patch)?
Sorry, I don't know the pro- and epilogue threading code well enough
to be of any
This has been unreachable for a while, so I am removing it from
the GCC mirrors list for now.
Gerald
Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.218
diff -u -3 -p -r1.218 mirrors.htm
1 - 100 of 142 matches
Mail list logo
