Hi all,
I've recently submitted a bug report regarding invalid unpoisoning of
stack frame redzones
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543). Could someone take
a look at proposed patch (a simple one-liner) and check whether it's ok
for commit?
Thanks!
-Yuri
diff --git a/gcc/asan
sing a ChangeLog entry.
Attached.
-Y
2013-09-30 Yury Gribov
PR sanitizer/58543
* asan.c: Use new temporary for iteration in asan_clear_shadow.
Hi Jakub,
>> I've recently submitted a bug report regarding invalid unpoisoning
of stack frame redzones
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543). Could someone take
a look at proposed patch (a simple one-liner) and check whether it's ok
for commit?
>
> Can you please be more verbo
>>> I've recently submitted a bug report regarding invalid unpoisoning
of stack frame redzones
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543). Could someone take
a look at proposed patch (a simple one-liner) and check whether it's ok
for commit?
>>
>> Can you please be more verbose
>
> Do
> Sorry for the delay, I finally found time to look at it.
Np, thanks for helping!
> While your patch fixes the issue, I wonder
> ...
> potentially increase register pressure.
Makes sense. I didn't take care of this because I believed that we can
freely allocate vregs and rely on register allo
> so in the end I guess I have nothing against the original patch
> (with whatever form of the copy to reg call is desirable).
So ok to commit?
-Y
>> So ok to commit?
> Ok with the change suggested by Richard, I think it was:
addr = copy_to_mode_reg (Pmode, XEXP (shadow_mem, 0));
Done, r204251. Tested against x64 and ARM.
-Y
> This patch is supposed to fix PR59063
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063).
>
> The original bug results from libasan providing clock_gettime wrapper
and then trying to call the "real" clock_gettime.
> The "real" symbol is supposed to come from librt.so which was not
necessaril
Hi all,
As discussed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 only a
subset of libubsan should be built with RTTI support. Attached patch
adds custom build rules for relevant files.
-Y
diff --git a/libsanitizer/ubsan/Makefile.am b/libsanitizer/ubsan/Makefile.am
index e98984a..eaab
> I don't like the unconditional -lrt added for -static-lib*san (note,
you need it for both -static-lib{a,t}san).
Makes sense.
> Perhaps it is time for libsanitizer.spec filled in during configure
of libsanitizer
> that the spec would source in?
Draft patch is attached, let's see if I unders
> Wasn't that already checked in?
No, that's an addition to previous commit.
-Y
>> This patch is supposed to fix PR59063
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063).
>
> This is fine. I'm assuming that the minor changes to the sanitizer
libraries are in bits that are maintained within GCC rather than
upstream in LLVM. Right?
Yes. This patch only touches Autotoo
>>> This patch is supposed to fix PR59063
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063).
>>
>> This is fine. I'm assuming that the minor changes to the sanitizer
libraries are in bits that are maintained within GCC rather than
upstream in LLVM. Right?
>
> Yes. This patch only touches A
rs_cxx.% ubsan_type_hash.% : AM_CXXFLAGS += -frtti
+
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
2013-11-28 Jakub Jelinek
Yury Gribov
PR sanitizer/59106
* ubsan/
> The above hunk is not needed anymore, is it?
Right.
> Ok for trunk without that hunk (and with Makefile.in regenerated again).
Done, r205482.
-Y
27; in cflags when testing.
I changed asan/ubsan-dg.exp but I'm not sure it's the right place.
-Y
2013-11-13 Yury Gribov
Jakub Jelinek
PR sanitizer/59063
* config/gnu-user.h: Removed old code for setting up sanitizer
libs.
* gcc.c: Using li
> Please fix up formatting
> Also, isn't libsanitizer/libsanitizer.spec.in missing from the patch?
>
> Ok with that fixed.
Thanks, r205524
-Y
>>> I am checking in this as an obvious fix. Tested
>>> on Linux/x86.
>>>
>>> H.J.
>>
>> I think bootstrap-asan.mk should also be updated.
>>
>>> H.J.
>
> I checked in this as an obvious fix. Tested on Linux/x86-64.
>
> H.J.
Thanks HJ. I wonder how this managed to pass tests here without your
> This is causing all the tests being run on all targets,
> even if libsanitizer is not supported,
> most of them failing due to link errors.
Thanks for the info and sorry about this. I should probably check
non-sanitized platforms as well before commiting patches. Does the
attached patch make
Hi all!
Currently gcc has tests for AddressSanitizer and UBSanitizer. Do you
think it would make sense to add support for ThreadSanitizer testing as
well? If the answer is positive, we can work on dg infrastructure
(tsan-dg.exp, tsan.exp) and initial set of tests. As for the latter:
should we
Konstantin Serebryany wrote:
> Other mode may work too, but we will not own the tests
> (similarly, we don't own the existing asan tests in GCC,
> although if the tests need fixing during integrate we do it).
I think everyone agrees on this. Once tests are in, Gcc team will
maintain them.
-Y
Jakub Jelinek wrote:
> The problem is that at least by default we
> don't want very expensive tests in the testsuite, whether it is runtime
> expensive or eats too much memory.
I see. We can only merge small tests then. From what I see in
compiler-rt/lib/tsan/lit_tests, most of the tests are rat
So ok to commit this fix?
---
From: Yury Gribov
Sent: Monday, December 02, 2013 10:12AM
To: Andreas Schwab
Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org,
eugeni.stepa...@gmail.com, VandeVondele Joost
, Evgeny Gavrin ,
Viacheslav Garbuzov
Subject
9.html
(i386-unknown-freebsd10.0 from Dec 2). I hope Andreas can confirm
whether we still need this patch.
-Y
---
From: Jeff Law
Sent: Tuesday, December 03, 2013 9:01AM
To: Yury Gribov , Andreas Schwab
Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org,
> The situation hasn't changed in the last four days.
Thanks. Do you think you can check the patch in question?
-Y
shell cat $(top_srcdir)/../gcc/BASE-VER)
# Work around what appears to be a GNU make bug handling MAKEFLAGS
# values defined in terms of make variables, as is the case for CC and
2013-12-05 Yury Gribov
PR sanitizer/59368
* Makefile.am (gcc_version): added gcc_ve
* } } } */
/* { dg-options "-static-libasan" } */
#include
2013-12-05 Yury Gribov
PR sanitizer/59369
* c-c++-common/asan/pr59063-1.c: Disable on non-Linux platforms.
* c-c++-common/asan/pr59063-2.c: Likewise.
>> * Makefile.am (gcc_version): added gcc_version.
> Capital letter A here.
Thanks, fixed.
> Ok
Done in r205698.
-Y
Fixed in r205699.
>> Ok to commit?
> Sure, that was the "Ok, thanks." in the previous mail.
Commited in r205704.
-Y
Jeff Law wrote:
> It looks like Jakub took care of it.
True.
Hi all,
GCC version of Asan currently lacks options for detailed control over
code instrumentation. These are not usually necessary but for embedded
systems with scarce system resources Asan memory overhead of 2x-3x may
often be unacceptable.
It seems that LLVM provides some options to allow
Konstantin Serebryany wrote:
> only -asan-stack and -asan-globals affect the memory overhead
But disabling code also counts. -asan-instrument-reads=0 may result in
big code size reduction (I'd say over 50%).
-Y
> big code size reduction
I meant to say "instrumented code size reduction"...
-Y
---
From: Yury Gribov
Sent: Friday, December 06, 2013 3:55PM
To: Konstantin Serebryany
Cc: GCC Patches , Viacheslav Garbuzov
, Max Ostapenko
Subject:
Konstantin wrote:
> Jakub wrote:
>> I'm strongly against the blacklist,
> I don't like it either. We were forced to implement it by reality.
> ...
> imagine third-party code which you can build but can not change
Same situation here. Reality is that Asan is often thrown at huge (I
mean several M
Konstantin wrote:
> Can you have a target specific config for the particular target
> that will have its own shadow offset & scale?
Yes, we have this but I don't see how this can help with code
instrumentation overheads.
-Y
Konstantin wrote:
> My comment about "don't implement them" was only about the flags
> that change shadow offset & scale
Ah, I see. I didn't mention them in the first place so I got puzzled.
So it looks like people are generally ok with
* --param asan-instrument-reads=0/1
* --param asan-instrume
> I'm strongly against the blacklist,
> that is not the way things are done in GCC,
> you have corresponding attribute to mark functions
> you don't want to instrument, people can macroize that with
> __typeof (symbol) symbol __attribute__((__no_sanitize_address__));
> But in any case, you mark it
Jakub wrote:
> You can still -include some header file from the command line and put the
> attributes in there or similar.
True although this probably won't work with C++ methods.
> The blacklist is really terribly ugly hack,
> which can't work reliably. What do you do for anonymous namespaces?
Done, r205853.
HJ wrote:
>> Done, r205853.
> I think it caused:
> http://gcc.gnu.org/ml/gcc-regression/2013-12/msg00214.html
Right, I think we are missing torture-finish. Will send a fix after test.
-Y
g-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c $srcdir/c-c++-common
}
# All done.
+torture-finish
tsan_finish
dg-finish
2013-12-10 Yury Gribov
* gcc-dg/tsan/tsan.exp: Added missing call to torture-finish.
* g++-dg/tsan/tsan.exp: Likewise.
Done in r205858.
---
From: Jakub Jelinek
Sent: Tuesday, December 10, 2013 7:37PM
To: Yury Gribov
Cc: H.J. Lu , Maxim Ostapenko
, GCC Patches
, Slava Garbuzov
Subject: Re: Fix tsan tests.
On 12/10/2013 07:37 PM, Jakub Jelinek wrote:
On Tue, Dec
> This test would fail on strict alignment targets.
Ok, we'll throw in a dg-skip-if.
> Why is the test C++ only though?
> Again, why C++ only?
> Ditto.
> Likewise.
I think main reason is having same versions of code with Clang. I had an
impression that minimization of changes would be preferre
> I guess I can live with it as is, just was wondering why the tests
> were written so carelessly that when they don't really need to test
> any C++ features they are still written in C++.
Adding Kostya to comment.
-Y
> No gcc/ prefixes in ChangeLog entries.
Should we update contrib/mklog then?
-Y
In my experience mklog is pretty much useless, e.g. if you
add a new function, it will list the previous function as being modified
rather than the new one, etc.
In my experience it prints both the old and the new one. If that's a
problem we could probably fix it (I mean I can volunteer).
Her
On 12/19/2013 04:17 PM, Yury Gribov wrote:
>> In my experience mklog is pretty much useless, e.g. if you
>> add a new function, it will list the previous function as being modified
>> rather than the new one, etc.
>
> In my experience it prints both the old and the new on
o abbreviate ChangeLog, instead of 'clog'.
Got it. Attached new version of script and ChangeLog entry. Will submit
tomorrow if noone objects.
-Y
2013-12-19 Yury Gribov
* mklog: Split generated message in parts.
diff --git a/contrib/mklog b/contrib/mklog
index a874c72..d3f0
The patch is OK. Feel free to submit now, if you want.
Thanks. Done in r206116.
-Y
Ultimately, mklog ought to write the ChangeLog itself.
We get rid of that headache, at least.
How about this then? Updated mklog now adds 'New file'/'New
test'/'Remove' when necessary.
I did some tests with unified/context-diffed SVN and git and it worked
as expected. I can do more testing i
Diego wrote:
How about this then? Updated mklog now adds 'New file'/'New
test'/'Remove' when necessary.
This is OK. Thanks.
Submitted in r206175.
Let me know if you have ideas on improving the current script. I think
it may make sense to address Jakub's complaint about redundant functions:
Hi folks,
This patch fixes problem with UBSan tests failing on remote target
platforms (ARM via SSH). The error is caused by DejaGNU harness
stripping trailing newline from test output (and thus causing pattern
matching failures).
Link to PR: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59585
Yury wrote:
>> Still sounds like a bug elsewhere to me.
>
> Let me investigate this deeper tomorrow (rebuilding fresh Dg, etc.).
So I've double-checked that this is a problem with trunk DejaGNU rsh.exp
script removing trailing newline from test output:
# Delete one trailing \n because that
Chung-Wu wrote:
> But I notice your ChangeLog formatting is not correct.
>
> You can refer to other entries in ChangeLog to refine yours,
> and then resubmit the patch for review. :)
Or - use contrib/mklog to autogenerate template ChangeLog for you.
-Y
Jakub wrote:
IMNSHO it is far better to just change those
tests into compile time tests and verify assembly using dg-final
scan-assembler.
We did exactly this for majority of tests except for
* c-c++-common/asan/use-after-return-1.c (back-ported from Clang, no UB)
* c-c++-common/asan/no-asan-st
Jakub wrote:
> Ok, I guess I can live with the original patch then.
r206219.
-Y
> I hacked a simple addition to mklog which skips unchanged functions
> in diff-log while adding function names to the final ChangeLog.
>
> New mklog results were verified by testsuite which compares reference
> ChangeLogs of patches from gcc trunk with logs generated by mklog.
>
> Patched mklog c
On 10/13/2015 02:16 PM, Maxim Ostapenko wrote:
This patch introduces required compiler changes. Now, we don't version
asan_init, we have a special __asan_version_mismatch_check_v[n] symbol
for this.
Also, asan_stack_malloc_[n] doesn't take a local stack as a second
parameter anymore, so don't pa
On 10/14/2015 12:34 PM, Maxim Ostapenko wrote:
On 14/10/15 10:54, Jakub Jelinek wrote:
Do you plan to update the asan tests we have to reflect the changes in
upstream?
Hm, there aren't changes into instrumentation, so the only thing is new
interceptors. If it is desirable, I can migrate some t
On 10/14/2015 10:15 PM, Renato Golin wrote:
On 14 October 2015 at 20:00, Andrew Pinski wrote:
Then until that happens I think we should disable asan and tsan for
AARCH64 for GCC.
I can't comment on that, but we'll continue running the tests on our
side on both 39 and 42 VMA configurations, to
of platform-specific bugs there.
Best regards,
Yury Gribov
t be enabled at all.
Linaro has stated several times that main reason for missing 48-bit
support is lack of HW. Could Cavium provide them with ThunderX bot?
Best regards,
Yury Gribov
On 11/24/2015 02:55 PM, Maxim Ostapenko wrote:
On 24/11/15 14:27, Jakub Jelinek wrote:
On Tue, Nov 24, 2015 at 12:23:05PM +0100, Christophe Lyon wrote:
On 24 November 2015 at 12:12, Jakub Jelinek wrote:
On Tue, Nov 24, 2015 at 12:08:13PM +0100, Christophe Lyon wrote:
Sure.
I had a build in p
On 12/04/2015 04:41 PM, Jakub Jelinek wrote:
Hi!
While this has been posted after stage1 closed and I'm not really happy
that it missed the deadline, I'm willing to grant an exception, the patch
is small enough that it is ok at this point of stage3. That said, next time
please try to submit new
On Tue, Aug 8, 2017 at 12:32 AM, Segher Boessenkool
wrote:
> Hi Yuri,
>
> Sorry I missed this. Please cc: me to prevent that from happening.
Segher,
Sorry, somehow I missed your reply!
> On Fri, Jul 28, 2017 at 05:42:00AM +0100, Yury Gribov wrote:
>> This patch fixes
Hi all,
This is an updated version of patch for PR 81535. The patch was last
discussed in November. The new version addresses Segher's comments in
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00558.html
The patch was tested on
x86_64-pc-linux-gnu
powerpc64-unknown-linux-gnu
powerpc64le-u
On Thu, Feb 15, 2018 at 8:13 PM, Yury Gribov
wrote:
> Hi all,
>
> This is an updated version of patch for PR 81535. The patch was last
> discussed in November. The new version addresses Segher's comments in
> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00558.html
For
Hi all,
This uses ${TMPDIR:-/tmp} instead of /tmp in scripts in contrib folder.
Ok for trunk?
-Y
Respect-TMPDIR-1.patch
Description: Binary data
parameter to more closely match
LLVM.
The patch was bootstrapped, regtested and asan-bootstrapped on x64.
Ok for trunk?
-Y
commit 22a79d39656d3d600e97c7ae599b86b6d25efe00
Author: Yury Gribov
Date: Wed Aug 6 11:06:24 2014 +0400
Move inlining of Asan memory checks to sanopt pass.
Change asan
functions using this machinery would be
UBSAN_NULL and ASAN_CHECK (both would take EAF_DIRECT and EAF_NOESCAPE
for their pointer argument).
The patch was bootstrapped and regtested on x64.
Ok for trunk?
-Y
commit b90c4abf0b804c60b548f94fe59118d029363140
Author: Yury Gribov
Date: Wed Aug 6 11:05
ators.
-Y
(*) The patch relies on some additional changes in hash-table and CFG
which have not yet been upstreamed so it won't go with current trunk.
commit 602792daa983a6304205cd8fe8ec07b9fd348c3e
Author: Yury Gribov
Date: Thu Jul 31 15:07:30 2014 +0400
Global elimination
On 08/08/2014 12:09 PM, Jakub Jelinek wrote:
> Ok, thanks.
Done in r213807.
-Y
> On 08/08/2014 12:07 PM, Jakub Jelinek wrote:
> Ok, thanks, with a minor nit:
Done in r213806 (the nit fixed in patch 2/2).
-Y
On 08/11/2014 11:22 AM, Tom de Vries wrote:
+if ($#ARGV == 1 && ("$ARGV[0]" eq "-i" || "$ARGV[0]" eq "--inline")) {
I'd do >= 1 but that's a question of personal preference.
What is the purpose of that proposed change ?
Kind of laying foundation for adding more flags in the future. But as I
This is a fix for off-by-one bug that I've recently introduced in
r213806. Bootstrapped, regtested and Asan-boostrapped on x64.
Ok to commit?
-Y
commit cc88579f072240686605783229129700f9eb78a0
Author: Yury Gribov
Date: Mon Aug 11 19:30:24 2014 +0400
2014-08-12 Yury G
On 08/12/2014 11:20 AM, Jakub Jelinek wrote:
>> This is a fix for off-by-one bug that I've recently introduced in
r213806.
>> Bootstrapped, regtested and Asan-boostrapped on x64.
>>
>> Ok to commit?
>
> Sure.
Done, r213848.
-Y
5a10147cef710e6f43365567615f37261d7e70c5
Author: Yury Gribov
Date: Mon Aug 11 15:09:45 2014 +0400
2014-08-12 Yury Gribov
gcc/
PR sanitizer/62089
* asan.c (instrument_derefs): Fix bitfield check.
gcc/testsuite/
PR sanitizer/62089
* c-c++-common/asan/pr62089
tsize != size_in_bytes * BITS_PER_UNIT)
return;
Something like this?
BTW we probably need support for BIT_FIELD_REF as well, I've seen it in
e.g. GCC code. I'll see if I can cook a patch for this.
-Y
commit 57cb45239f24057e1b309f72795042c5b018d07e
Author: Yury Gribov
Date: Mon Aug 11 15:0
On 08/14/2014 09:46 AM, Yury Gribov wrote:
Something like this?
Forgot to mention: full tested the new patch on x64 (bootstrap, regtest,
Asan-bootstrap).
ndled.
Makes sense, I've attached new patch (retested as usual).
-Y
commit 77f65357c65fd86650027ce9498c4960953a2760
Author: Yury Gribov
Date: Mon Aug 11 15:09:45 2014 +0400
2014-08-15 Yury Gribov
gcc/
PR sanitizer/62089
* asan.c (instrument_derefs): Fix bitf
On 08/19/2014 03:37 PM, Dominique Dhumieres wrote:
Makes sense, I've attached new patch (retested as usual).
Well, you probably did not test with -m32:
Right, I only did plain "make check" until now. Thanks for reporting,
I'll check this tomorrow.
-Y
?
BTW regarding ChangeLog: should I mention both bugs (they are
duplicates) or just one of them?
-Y
commit e3324d8d3528f0cb1a56e784f0887a4743a3e0f2
Author: Yury Gribov
Date: Wed Aug 20 13:56:03 2014 +0400
2014-08-22 Yury Gribov
gcc/
PR sanitizer/62140
* asan.c
On 08/22/2014 12:47 PM, Yury Gribov wrote:
Attached patch fixes this.
As usual I forgot to mention tests: this was bootstrapped on x64 and
regtested for x64 and i686 and also Asan-bootstrapped for x64.
-Y
On 08/19/2014 04:31 PM, Yury Gribov wrote:
On 08/19/2014 03:37 PM, Dominique Dhumieres wrote:
Makes sense, I've attached new patch (retested as usual).
Well, you probably did not test with -m32:
Right, I only did plain "make check" until now. Thanks for reporting,
I'll
On 08/25/2014 11:04 AM, Maxim Ostapenko wrote:
> This patch adds necessary flags to provide a linkage of these tests in
> bootstrap-asan case.
I think you'll want to modify Makefile.def and Makefile.tpl because
Makefile is generated from them.
-Y
-Y
commit aa3258be3749174a407185835a0484ebcbaf9bd3
Author: Yury Gribov
Date: Mon Aug 25 12:04:01 2014 +0400
2014-08-26 Yury Gribov
* c-c++-common/asan/pr62089.c: Fix test on 32-bit platforms.
diff --git a/gcc/testsuite/c-c++-common/asan/pr62089.c b/gcc/testsuite/c-c++-common/asan/pr620
On 08/18/2014 07:37 PM, Marat Zakirov wrote:
Hi there!
I have a fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875.
This situation occurs when somebody decides to build GCC with
-fexeptions and -frtti which are forbidden for libsanitizer. They get
strange error (see bug above) which I kn
---
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 to
Ok to commit?
-Y
commit dd961868f625f2f3b3ac9c4349284904cdd56ad1
Author: Yury Gribov
Date: Thu Sep 4 16:55:44 2014 +0400
2014-09-04 Laurynas Biveinis
Yury Gribov
* .local.vimrc: New file.
diff --git a/.local.vimrc b/.local.vimrc
new file mode 100644
index 000
e for every test
- needed for interactive work on desktop
Bootstrapped and regtested on x64.
Ok to commit?
-Y
commit d470f4d1214cbcbebb818778e6f554b346ee43d5
Author: Yury Gribov
Date: Fri Aug 29 16:43:42 2014 +0400
2014-09-05 Yury Gribov
gcc/
* asan.c (report_error
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 tha
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 userspace
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 -fsaniti
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 differe
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 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
Bernhard Reutner-Fischer 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 check for
GC
1 - 100 of 390 matches
Mail list logo
