On 05/26/2014 01:19 PM, Konstantin Serebryany wrote:
This is implemented in llvm, just need a flag flip. It also needs a
performance improvement in the run-time.
This is in my TODO, just didn't have time.
FYI I have a patch that adds -asan-instrumentation-with-call-threshold
for GCC (will
implementations more similar would require bigger
rewrite of Asan which I would prefer to avoid.
The patch consists of two parts:
* asan_negative_params_1.diff - support for negative parameters
* asan_calls_1.diff - the proper
Bootstrapped/regtested on x64.
-Y
2014-04-26 Yury Gribov y.gri
Making implementations more similar
would require bigger rewrite of Asan
of GCC Asan
* asan_negative_params_1.diff - support for negative parameters
I don't like this. Why do you need it?
That's only for compatibility with LLVM. I know that's not usually
considered an argument in gcc-patches but things like this would surely
make developer's life harder.
*
- using instrumentation via calls adds extra 1.5x-2.x slowdown
On x64.
- it would be nice to have the name prefix configurable from command
line (${PREFIX}_load1 instead of __asan_load1) because kasan uses
different names already.
Yeah, I noticed corresponding option in LLVM. AFAIK
On 05/27/2014 09:43 AM, Konstantin Serebryany wrote:
- using instrumentation via calls adds extra 1.5x-2.x slowdown
On x64.
Interesting. can you share your ARM numbers?
That wasn't an objection - I just made sure to specify the platform (x64
ABI is somewhat special).
The fact that some region appears in m
doesn't mean the inline asm actually accesses it, it could not touch it at
all, or only some part of it.
Do we have precise semantics of m written somewhere?
My understanding was that even though asm may not touch buffer at all
(like e.g. in our tests),
There was some discussion on what to do, but has there been a decision on
how to fix this yet? Or is it fixed upstream and we just need to merge
that fix too?
Yuri needs to send the patch to llvm-commits.
I think I already did that: D3911
-Y
Looks like now function does not return anything for ARM case? I'd say
we should replace this pc = ... with return like all other cases, the
code is just asking for trouble.
--- libsanitizer/sanitizer_common/sanitizer_stacktrace.cc (revision
209878)
+++
On 06/02/2014 11:56 AM, Jakub Jelinek wrote:
Looks like now function does not return anything for ARM case? I'd
say we should replace this pc = ... with return like all other
cases, the code is just asking for trouble.
But it should be
return (pc ~(uptr)1) - 1;
right?
Yes, I had
Why the -1 ? No ARM or Thumb instruction is 1 byte long. Instructions
are 4 bytes long if in ARM state and could be 2 or 4 bytes if Thumb
state.
The -1 just points to the middle of previous instruction,
so that supposedly it can be looked up in debug info etc.
Right, that works quite well
I took that patch and applied it to the gcc sources,
but I still see the error on ppc:
...
[bergner@makalu-lp1 asan]$
runtimes on large functions with huge (over 10K)
number of memory accesses (http://llvm.org/bugs/show_bug.cgi?id=12653)
* a step to full Kasan support in GCC
* reduce code size overhead
Bootstrapped/regtested on x64.
-Y
2014-06-03 Yury Gribov y.gri...@samsung.com
New asan-instrumentation-with-call
Any reason why the BUILT_IN_* names so differ from the actual function
names? I.e. why not use BUILT_IN_ASAN_{LOAD,STORE}{1,2,4,8,16,N}
(no underscore before N, no CHECK_)?
Makes sense.
Wouldn't it be better to do
...
so that you don't risk signed overflow? Maybe also
Yeah, that looks
It adds -lasan early, but after the libraries and
object files that are explicitly added to the linker command.
Since -lm is explicitly added to the linker command, the implicitly
added -lasan comes after. The -v command is below.
Hm, -lasan manages to override user-specified -lm on gcc
is now unified for const/variable lengths
but I'd still prefer to treat the use_calls case specially
because calling single __asan_loadN is more space-efficient
than emitting two separate calls with a length check.
-Y
2014-06-06 Yury Gribov y.gri...@samsung.com
New asan-instrumentation
1) instrument_mem_region_access/instrument_strlen should use a single
build_check_stmt call instead of two that they do now,
I agree with instrument_mem_region_access but the strlen case is quite
different because checks are inserted at different sides of instrumented
insn. Adding yet
Build_check_stmt is now unified for const/variable lengths
but I'd still prefer to treat the use_calls case specially
because calling single __asan_loadN is more space-efficient
than emitting two separate calls with a length check.
That is not what I meant.
1)
This is the resurrected patch with added GCC version information
into generated repro file.
I wonder whether we should also set ADDR_NO_RANDOMIZE and
ADDR_COMPAT_LAYOUT in addition to -frandom-seed (according to
https://gcc.gnu.org/wiki/Randomization).
-Y
, plus for NULL len also size_in_bytes, for non-NULL len
probably nothing, we don't know if len isn't zero.
Like this?
-Y
2014-06-11 Yury Gribov y.gri...@samsung.com
New asan-instrumentation-with-call-threshold parameter.
gcc/
* asan.c (check_func): New function.
(maybe_create_ssa_name
On 06/16/2014 12:23 PM, Jakub Jelinek wrote:
2014-06-11 Yury Gribov y.gri...@samsung.com
New asan-instrumentation-with-call-threshold parameter.
Ok, thanks.
Done in r211699.
On 06/16/2014 02:34 PM, Dominique Dhumieres wrote:
Done in r211699.
This breaks bootstrap on x86_64-apple-darwin13:
Hm, perhaps I didn't run full bootstrap after last round of review.
Does attached patch solve the problem for you? I've started bootstrap
but it'll take couple of hours to
On 06/16/2014 04:52 PM, Dominique Dhumieres wrote:
I have done the change to tree t = NULL_TREE; then bootstrap fails with
Bootstrap comparison failure!
gcc/plugin.o differs
gcc/toplev.o differs
Interesting, I didn't know that asan.c runs during normal bootstrap.
-Y
On 06/16/2014 04:47 PM, Yury Gribov wrote:
On 06/16/2014 02:34 PM, Dominique Dhumieres wrote:
Done in r211699.
This breaks bootstrap on x86_64-apple-darwin13:
Hm, perhaps I didn't run full bootstrap after last round of review.
Does attached patch solve the problem for you? I've started
Bootstrapped successfully on x64 with proposed patch.
The original commit indeed failed to bootstrap
(https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg01419.html).
Ok to commit fix?
Ok (with proper ChangeLog entry).
r211713.
-Y
Have already been done in r211699. Does it work for you? Adding a test
would still be useful.
-Y
Original Message
Subject: [PATCH] Fix for PR59600
Date: Tue, 21 Jan 2014 14:42:31 +0400
From: Yury Gribov y.gri...@samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org
Hi,
This patch fixes the problem reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 : functions
Original Message
Subject: [PATCH] Fix handling of context diff patches in mklog
Date: Wed, 22 Jan 2014 18:36:23 +0400
From: Yury Gribov y.gri...@samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org, Diego Novillo
dnovi...@google.com
CC: Viacheslav Garbuzov v.garbu
Diego wrote:
Ok to commit?
OK. Thanks.
Done in r207265.
-Y
Additionally I'm not really sure
why there is an additional load from the constant pool here - what is
the constant in this case ?
Given it is atmost a 16 bit constant
surely that should be loaded with a single mov(w) instruction
in armv7 land.
I've made some investigations with 4.8.
The
Uggh - what a mess. Surely that zero_extend:SI (const_int 1) should be
replaced by a move somewhere.
Actually the whole (zero_extend:SI (subreg:HI ...)) part is replaced by
(const_int 1). It still ends up in constant pool though.
-Y
The subreg being replaced is believable, but not the zero_extend.
That would mean we had a simple movhi pattern, not a zero-extend pattern.
Sorry, you are right. It's just subreg without zero_extend!
-Y
Uggh - what a mess. Surely that zero_extend:SI (const_int 1) should be
replaced by a move somewhere.
So I'm all for fixing this but I don't really know where to start. Do
you have any suggestions? Julian's patch now looks more like a workaround...
-Y
Original Message
Subject: [PATCH][PING] Fix for PR59600 (prohibit inlining if
no_sanitize_address)
Date: Tue, 28 Jan 2014 09:13:10 +0400
From: Yury Gribov y.gri...@samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org
Original Message
Subject: [PATCH] Fix
Richard wrote:
I think you can't rely on pointer equivalence of the lookup_attribute
result so you want instead of
Thanks, makes sense.
Please also name CIF_OPTION_MISMATCH as CIF_ATTRIBUTE_MISMATCH
and say function attribute mismatch in the description.
Done.
What about updated patch?
Richard wrote:
What about updated patch?
Ok if it passes bootstrap and regtesting.
It does, commited in r207497.
-Y
Ramana wrote:
The error is caused by unaligned vector load via two vldr instructions:
So, does this mean that we get unaligned vector loads
when munaligned-access is on, using vldr instructions ?
No, when -munaligned-access is on, the backend will enable movmisalign
patterns that generate
Kugan wrote:
Ok if no regressions.
Tested it on qemu for arm-none-linux-gnueabi and there is no new
regressions. I am sorry I didn’t mention it when I posted the patch.
Commited in r207533. Thanks!
-Y
As can be seen here:
http://cbuild.validation.linaro.org/build/cross-validation/gcc/207533/report-build-info.html
this has caused some regressions on armv5t targets.
IMHO this is expected: with this patch we prohibited unaligned loads on
all platforms with -mno-unaligned-access. Perhaps we
we prohibited unaligned loads
Sorry, meant to say vectorization of unaligned loads.
-Y
I'm not sure what you asking for here. But to learn how to format
your code, I think just look at the GCC source code and model your
code after that.
I am not understanding the standard.For example,should I use \t
instead of space?Should I use 4 spaces as indent or 2?
My understanding
That is not true. The indentation style is:
http://www.gnu.org/prep/standards/standards.html#Formatting
...
The above also mentions particular options
for GNU indent which set various rules.
Ah, good to know. So, are contributors expected to run indent on their
changes before sending patches?
Richard wrote:
The thread seems to have died down,
so should I go ahead and install it?
Looks like all reviews were more or less positive...
-Y
Jakub Jelinek wrote:
Richard Sandiford wrote:
OK, how about this? It looks like the builtins.c and stmt.c stuff wasn't
merged until 4.9, and at this stage it seemed safer to just add the same
use/clobber sequence to both places.
Please wait a little bit, the patch has been committed to the
Cc-ing Jakub cause he's the author of original set-target-env-var
support in GCC testsuite.
On 03/24/2014 01:46 PM, Maxim Ostapenko wrote:
Adding Dejagnu list this time.
On 03/24/2014 12:28 PM, Maxim Ostapenko wrote:
Hi all,
When porting Lsan on arm, I ran into problem with testing, because
On 10/13/2014 02:26 PM, Yury Gribov wrote:
On 10/02/2014 09:14 PM, Yury Gribov wrote:
On 09/17/2014 09:08 PM, Yury Gribov wrote:
On 09/16/2014 08:38 PM, Yury Gribov wrote:
Hi all,
This is the third version of the patch. A list of changes since last
version:
* move config to contrib
On 10/17/2014 08:13 PM, Jakub Jelinek wrote:
On Mon, Oct 13, 2014 at 02:47:07PM +0400, Yury Gribov wrote:
On 09/30/2014 09:39 PM, Jakub Jelinek wrote:
LGTM, will hack it up soon in GCC then.
Do you plan to work on this in near future?
Here is only very lightly tested patch, didn't get
Hi all,
On 09/29/2014 09:21 PM, Yury Gribov wrote:
This patch enables -fsanitize-recover for KASan by default. This causes
KASan to continue execution after error in case of inline
instrumentation. This feature is needed because
- reports during early bootstrap won't even be printed
- needed
On 10/23/2014 11:13 AM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 11:11:29AM +0400, Yury Gribov wrote:
Hi all,
On 09/29/2014 09:21 PM, Yury Gribov wrote:
This patch enables -fsanitize-recover for KASan by default. This causes
KASan to continue execution after error in case of inline
On 10/21/2014 05:26 PM, Maxim Ostapenko wrote:
Hi,
this is the second version of the patch. Here the major changes from the
previous one:
[snip]
case BUILT_IN_BCMP:
+ *intercepted_p = false;
The code which identifies interceptors seems to be duplicated in
expand_builtin. What
On 10/23/2014 02:20 PM, Andrey Ryabinin wrote:
On 10/23/2014 02:00 PM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 11:55:32AM +0200, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
IMO we don't need different versions of __asan_load* and
On 10/23/2014 02:16 PM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 02:09:47PM +0400, Andrey Ryabinin wrote:
On 10/23/2014 01:55 PM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
IMO we don't need different versions of __asan_load* and
On 10/23/2014 03:10 PM, Andrey Ryabinin wrote:
On 10/23/2014 02:38 PM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 02:33:42PM +0400, Yury Gribov wrote:
Actually this is a historical artifact. If inlining proves to be
significantly faster, they may want to switch.
Ok.
So, at that point
On 10/24/2014 01:44 PM, Dmitry Vyukov wrote:
On Fri, Oct 24, 2014 at 12:28 PM, Yury Gribov y.gri...@samsung.com wrote:
On 10/23/2014 03:10 PM, Andrey Ryabinin wrote:
On 10/23/2014 02:38 PM, Jakub Jelinek wrote:
On Thu, Oct 23, 2014 at 02:33:42PM +0400, Yury Gribov wrote:
Actually
Hi all,
On 10/17/2014 11:53 AM, Yury Gribov wrote:
On 09/29/2014 09:21 PM, Yury Gribov wrote:
Kasan developers has asked for an option to override offset of Asan
shadow memory region. This should simplify experimenting with memory
layouts on 64-bit architectures.
New patch which checks
Hi all,
On 10/23/2014 11:11 AM, Yury Gribov wrote:
This patch enables -fsanitize-recover for KASan by default. This causes
KASan to continue execution after error in case of inline
instrumentation. This feature is needed because
- reports during early bootstrap won't even be printed
- needed
On 10/28/2014 12:26 PM, Jakub Jelinek wrote:
On Tue, Oct 28, 2014 at 11:46:31AM +0300, Yury Gribov wrote:
2014-10-23 Yury Gribov y.gri...@samsung.com
gcc/
* asan.c (report_error_func): Add noabort path.
(check_func): Ditto. Formatting.
(asan_expand_check_ifn): Handle
On 10/31/2014 11:35 AM, Maxim Ostapenko wrote:
Hi,
this tiny patch fixes PR63696 (alloc-dealloc-mismatch in ipa-icf.c).
Tested on x86_64-unknown-linux-gnu, ok to commit?
Could you add PR comment to ChangeLog?
-Y
On 11/03/2014 05:27 PM, Marek Polacek wrote:
Another shot at optimizing redundant UBSAN_NULL statements.
This time we walk the dominator tree - that should result in
more effective optimization - and keep a list of UBSAN_NULL
statements that dominate the current block, see the comment
before
On 11/05/2014 12:33 PM, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 12:19:22PM +0300, Yury Gribov wrote:
On 11/03/2014 05:27 PM, Marek Polacek wrote:
Another shot at optimizing redundant UBSAN_NULL statements.
This time we walk the dominator tree - that should result in
more effective
On 11/05/2014 02:23 PM, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 11:50:20AM +0100, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 11:29:19AM +0100, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 12:54:37PM +0300, Yury Gribov wrote:
Are you going to work on ASan soon? I could rebase my
On 11/05/2014 03:21 PM, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 03:16:49PM +0300, Yury Gribov wrote:
On 11/05/2014 02:23 PM, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 11:50:20AM +0100, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 11:29:19AM +0100, Marek Polacek wrote:
On Wed, Nov 05
On 11/05/2014 03:34 PM, Yury Gribov wrote:
On 11/05/2014 03:21 PM, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 03:16:49PM +0300, Yury Gribov wrote:
On 11/05/2014 02:23 PM, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 11:50:20AM +0100, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 11:29:19AM
On 11/05/2014 04:23 PM, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 04:13:01PM +0300, Yury Gribov wrote:
Wouldn't it break most uses of __asan_poison_memory_region ?
Most probably but I wonder if we should ask people to simply do asm
volatile with memory clobber in this case? And we
On 11/06/2014 11:00 AM, Marat Zakirov wrote:
- if ($doubtfunc) {
- $idx = $line_idx;
+ $idx = $line_idx;
# Skip line info in context diffs.
- while ($is_context_diff $diff_lines[$idx + 1] =~ /^[-\*]{3}
[0-9]/) {
- ++$idx;
-
On 11/06/2014 12:07 PM, Yury Gribov wrote:
On 11/06/2014 11:00 AM, Marat Zakirov wrote:
-if ($doubtfunc) {
-$idx = $line_idx;
+$idx = $line_idx;
# Skip line info in context diffs.
-while ($is_context_diff $diff_lines[$idx + 1] =~
/^[-\*]{3} [0-9
On 10/21/2014 07:24 PM, Yury Gribov wrote:
On 10/13/2014 02:26 PM, Yury Gribov wrote:
On 10/02/2014 09:14 PM, Yury Gribov wrote:
On 09/17/2014 09:08 PM, Yury Gribov wrote:
On 09/16/2014 08:38 PM, Yury Gribov wrote:
Hi all,
This is the third version of the patch. A list of changes since
---
From: Yury Gribov
Sent: Friday, August 22, 2014 12:47PM
To: GCC Patches
Cc: Jakub Jelinek, Marek Polacek, t...@alumni.duke.edu, sabrina...@gmail.com
Subject: [PATCH] Fix Asan ICEs on unexpected types (PR62140, PR61897)
On 08/22/2014 12:47 PM, Yury
On 09/01/2014 08:28 PM, Jakub Jelinek wrote:
This situation occurs when somebody decides to build GCC with
-fexeptions and -frtti which are forbidden for libsanitizer.
I don't see a reason for this, simply don't do that, libsanitizer AFAIK
isn't the only library where it is highly undesirable
Ok to commit?
-Y
commit dd961868f625f2f3b3ac9c4349284904cdd56ad1
Author: Yury Gribov y.gri...@samsung.com
Date: Thu Sep 4 16:55:44 2014 +0400
2014-09-04 Laurynas Biveinis laurynas.bivei...@gmail.com
Yury Gribov y.gri...@samsung.com
* .local.vimrc: New file.
diff
for every test
- needed for interactive work on desktop
Bootstrapped and regtested on x64.
Ok to commit?
-Y
commit d470f4d1214cbcbebb818778e6f554b346ee43d5
Author: Yury Gribov y.gri...@samsung.com
Date: Fri Aug 29 16:43:42 2014 +0400
2014-09-05 Yury Gribov y.gri...@samsung.com
gcc
On 09/05/2014 11:32 AM, Dmitry Vyukov wrote:
Can we do it w/o doubling number of runtime entry points?
I didn't find a good way to achieve this. See, normal asan reporting
functions
have a noreturn attribute (defined in sanitizer.def) which can't be changed
depending on cmdline flag.
Looks
On 09/05/2014 12:23 PM, Dmitry Vyukov wrote:
I didn't find a good way to achieve this. See, normal asan reporting
functions
have a noreturn attribute (defined in sanitizer.def) which can't be changed
depending on cmdline flag.
I have not looked at the code in detail. But it looks weird to me
On 09/05/2014 12:59 PM, Andrey Ryabinin wrote:
And how does it work if someone wants to try -fsanitize=address
-fsanitize-recover.
Seems you didn't touch libsanitzer in this patch,
so I guess this will cause link time error, right ?
Exactly, Asan team does not want recovery mode for
On 09/05/2014 01:28 PM, Jakub Jelinek wrote:
Though, for that option the default is yes for ubsan purposes, while asan
wants a default to no, so it is unclear how to solve that. Either different
option for asan recovery, or tristate option etc.
Currently I force set it on encountering
On 09/04/2014 05:22 PM, Richard Biener wrote:
For some reason I use
set shiftwidth=4
set tabstop=8
set autoindent
set cinoptions={.5s,g0,p5,t0,(0,^-0.5s,n-0.5s
I note some differences to your
+ setlocal cinoptions=4,n-2,{2,^-2,:2,=2,g0,h2,p5,t0,+2,(0,u0,w1,m1
Ah, the vimfu.
So the
On 09/05/2014 12:22 AM, Bernhard Reutner-Fischer wrote:
Not sure from whom i borrowed this, perhaps even from you richi, but the
gcc_style.vim pasted in the mail below seems to be floating around ;)
https://gcc.gnu.org/ml/gcc-patches/2012-12/msg01228.html
Nice! Interestingly enough this gives
Segher Boessenkool segher at kernel.crashing.org writes:
On Fri, Sep 05, 2014 at 07:10:02PM +0400, Yury Gribov wrote:
Now I don't quite like the idea of plugin:
Anything that will make this enabled automatically will meet a lot of
resistance. Make something nice for contrib/ instead?
Hm
Bernhard Reutner-Fischer rep.dot.nop at gmail.com writes:
* gcc_style.vim enables GNU style globally, for all projects
How come? Please explain?
My understanding was that maybe_gcc_style gets run on all opened files and
this could cause problems with non-GCC projects. But given that you
Author: Yury Gribov y.gri...@samsung.com
Date: Fri Aug 29 11:58:03 2014 +0400
Allow to override Asan shadow offset.
2014-09-08 Yury Gribov y.gri...@samsung.com
gcc/
* asan.c (set_asan_shadow_offset): New function.
(asan_shadow_offset): Likewise
On 09/09/2014 10:51 AM, VandeVondele Joost wrote:
Attached is an extended version of the patch,
it brings a 100% improvement in make -j32 -k check-gcc
First of all, many thanks for working on this.
+# ls -1 | ../../../contrib/generate_tcl_patterns.sh 300
dg.exp=gfortran.dg/
How does this
On 09/09/2014 06:14 PM, VandeVondele Joost wrote:
I certainly don't want to claim that the patch I have now is perfect,
it is rather an incremental improvement on the current setup.
I'd second this. Writing patterns manually seems rather inefficient and
error-prone
(not undoable of course but
On 09/09/2014 06:33 PM, Jakub Jelinek wrote:
On Tue, Sep 09, 2014 at 06:27:10PM +0400, Yury Gribov wrote:
On 09/09/2014 06:14 PM, VandeVondele Joost wrote:
I certainly don't want to claim that the patch I have now is perfect,
it is rather an incremental improvement on the current setup.
I'd
in root folder per user's request
I personally prefer 2) because this would IMHO improve the quality of
patches
(e.g. no more silly tab-whitespace formatting bugs).
Thoughts? Ok to commit?
-Y
commit 879cd3e9bdcab780a9b96aff759ef684e3597d0c
Author: Yury Gribov y.gri...@samsung.com
Date: Thu
I personally prefer 2)
Sorry, I meant 1) of course that is enable vimrc config by default.
-Y
Segher Boessenkool segher at kernel.crashing.org writes:
I am saying it is very anti-social to make
people's editor behave differently from what they are used to.
...
The Emacs dir-locals file simply
configures some settings for files with certain major modes in that
dir.
For example, ours
On 09/11/2014 01:14 PM, pins...@gmail.com wrote:
I don't like auto formatting in any editor.
Ok, so +1 for moving to contrib/.
And some folks already have to deal with two more formatting styles already:
Linux kernel and gnu. So if you add auto formatting to one,
some folks are going to get
On 09/11/2014 01:18 PM, Richard Biener wrote:
On Thu, Sep 11, 2014 at 11:06 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, Sep 10, 2014 at 10:09 AM, Yury Gribovy.gri...@samsung.com wrote:
Hi all,
This is a second version of patch which adds a Vim config (.local.vimrc)
to root
On 09/11/2014 02:10 PM, Yury Gribov wrote:
On 09/11/2014 01:18 PM, Richard Biener wrote:
On Thu, Sep 11, 2014 at 11:06 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, Sep 10, 2014 at 10:09 AM, Yury Gribovy.gri...@samsung.com
wrote:
Hi all,
This is a second version of patch which
On 09/05/2014 10:54 AM, Yury Gribov wrote:
Hi all,
This patch enables -fsanitize-recover for KASan by default. This causes
KASan to continue execution after error in case of inline
instrumentation. This feature is needed because
- reports during early bootstrap won't even be printed
- needed
On 09/08/2014 06:29 PM, Yury Gribov wrote:
Hi all,
Kasan developers has asked for an option to override offset of Asan
shadow memory region. This should simplify experimenting with memory
layouts on 64-bit architectures.
I've bootstrapped and regtested this on x64.
Ok to commit?
-Y
commit
On 09/14/2014 02:30 PM, Alexander Monakov wrote:
On Thu, 11 Sep 2014, Yury Gribov wrote:
Ok, it tooks some time. Basically we want brace symbol to behave differently
in two contexts:
1) not add any additional offset when not following control flow operator:
void
f ()
{
int x
On 09/12/2014 05:17 AM, Trevor Saunders wrote:
On Thu, Sep 11, 2014 at 08:06:02PM -0400, David Malcolm wrote:
FWIW, in case it's helpful, I have a script here that I use to help make
ChangeLog entries:
https://github.com/davidmalcolm/gcc-refactoring-scripts/blob/master/generate-changelog.py
bad formatting
}
}
but it seems to be the best we can get with Vim's cindent
(and I don't think anyone seriously considers writing a custom indentexpr).
Ok to commit?
-Y
commit 67219512dac9a5cc14eea8f157222a226044dd72
Author: Yury Gribov y.gri...@samsung.com
Date: Thu Sep 4 16:55:44 2014
On 09/17/2014 05:01 PM, Segher Boessenkool wrote:
You can make Vim automatically adapt settings, but you cannot make the Vim
user adapt to that.
How about making Vim user adapt to GNU coding style though?
Not that I want to start flame again.
Sure. If you have the localrc thing installed,
Sure. If you have the localrc thing installed, anyone who can write
files
you can read can make your vim do *anything* (and I mean *anything*).
I thought that modern versions of localrc run .local.vimrc scripts in a
sandbox?
Ok, looks like Markus Braun's
On 09/16/2014 08:38 PM, Yury Gribov wrote:
Hi all,
This is the third version of the patch. A list of changes since last
version:
* move config to contrib so that it's _not_ enabled by default (current
score is 2/1 in favor of no Vim config by default)
* update Makefile.in to make .local.vimrc
On 09/18/2014 07:52 AM, Segher Boessenkool wrote: +# Local Vim config
+
+vimrc:
+ (cd $(srcdir); $(LN_S) contrib/vimrc .local.vimrc; $(LN_S)
contrib/vimrc .lvimrc)
+
This is another target than what the doc (in the script itself) mentions.
Right, I've forgot to fix it before sending the
On 09/18/2014 03:01 PM, Jakub Jelinek wrote:
On Mon, Sep 15, 2014 at 01:46:14PM +0400, Yury Gribov wrote:
On 09/08/2014 06:29 PM, Yury Gribov wrote:
Kasan developers has asked for an option to override offset of Asan
shadow memory region. This should simplify experimenting with memory
layouts
Added Marek to comment on proposed UBSan option change.
On 09/18/2014 02:52 PM, Jakub Jelinek wrote:
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1551,6 +1551,12 @@ common_handle_option (struct gcc_options *opts,
| SANITIZE_RETURNS_NONNULL_ATTRIBUTE))
101 - 200 of 387 matches
Mail list logo
