You need to add `-fsanitize=address` to compiler flags (both `CFLAGS` and `CXXFLAGS`) and linker flags (`LDFLAGS`). You&#39;ve probably added it to your compiler flags only. 

Note that using explicit `-lasan` option has been widely discouraged by ASan developers (e.g. [here](https://groups.google.com/d/msg/address-sanitizer/SD590XDinfQ/NMUPj_G0BgAJ)) as it misses some other important linker flags. The only recommended way to link is to use `-fsanitize=address`.

As a side note, for more aggressive verification flags check [Asan FAQ](https://github.com/google/sanitizers/wiki/AddressSanitizer#faq) (look for &quot;more aggressive diagnostics&quot;).

Make sure you have libasan installed.  For example, in Fedora:

```dnf install libasan libasan-static
```


You need to add the switch &lt;s&gt;`-lasan`&lt;/s&gt; `-fsanitize=address` to your _both_ your compile _and_ link command line to link the correct library.

Note: the original answer -lasan is outdated and should not be used, as per comments

I am currently trying to migrate a `Maven` project to `Gradle`

In my `Maven` version I have the dependency versions all listed out like this in my **parent** pom:

    &lt;properties&gt;
        &lt;spring.version&gt;4.2.3.RELEASE&lt;/spring.version&gt;
        &lt;spring.boot.version&gt;1.3.3.RELEASE&lt;/spring.boot.version&gt;
        ...
    &lt;/properties&gt;

And then I can define a dependency like this in any of my sub-modules:

    &lt;dependency&gt;
        &lt;groupId&gt;org.springframework&lt;/groupId&gt;
        &lt;artifactId&gt;spring-jdbc&lt;/artifactId&gt;
        &lt;version&gt;${spring.version}&lt;/version&gt;
    &lt;/dependency&gt;

I am attempting to do the same thing on `Gradle`, because some of my modules share dependency versions like this, and I wouldn&#39;t like to modify more then one place if I want to upgrade Spring or do a similar operation.

The closest  I have gotten to it is this:

    dependencies {
        ext.springVersion = &#39;4.2.3.RELEASE&#39;
        compile &quot;org.springframework:spring-jdbc:$springVersion&quot;
    }

Yet that still doesn&#39;t work. What is the recommended way to achieve this in Gradle? Or does  Gradle treat this differently? Perhaps my mind is still too much on Maven to see another solution.

Please keep in mind that that attempt on Gradle isn&#39;t *exactly*  what I want yet. I would like to be able to define the dependencies in a **separate** file, not directly on the file that will use it.


How do I define a variable for the dependency version in Gradle

When trying to check if a user is signed in via `firebase.auth().currentUser` like this:

    if (firebase.auth().currentUser === null) {
      console.log(&#39;User not signed in&#39;);
    }
Whenever I refresh the page, or navigate around the above returns null (even though I have just logged in).

The weird thing is, that if I log 

    console.log(firebase.auth().currentUser) // This returns null
    console.log(firebase.auth()) // Here I can inspect the object and currentUser exists...!

I don&#39;t really know what&#39;s going on here. I&#39;m using React and Redux, but it shouldn&#39;t really matter I&#39;d say.

Is there a small delay where the firebase initialises and you can&#39;t access the currentUser? If so, how can I see it in the log output of `firebase.auth()`? 


Can&#39;t get currentUser on load

I&#39;m trying to build my project with 

    g++ -O0 -g -fsanitize=address -fno-omit-frame-pointer

but get lots of errors like:

    /home/user/libs/opencv/include/opencv2/core/mat.hpp:715: undefined reference to `__asan_report_load8&#39;

How to compile project with AddressSanitize support?

My gcc version is 4.8.4.

How to use AddressSanitizer with GCC?

I'm trying to build my project with
<pre><code class="hljs language-ini">g++ -O0 -g -fsanitize=address -fno-omit-frame-pointer
</code></pre>
but get lots of errors like:
<pre><code class="hljs language-bash">/home/user/libs/opencv/include/opencv2/core/mat.hpp:715: undefined reference to `__asan_report_load8'
</code></pre>
How to compile project with AddressSanitize support?
My gcc version is 4.8.4.

I need a function that (like SecureZeroMemory from the WinAPI) always zeros memory and doesn&#39;t get optimized away, even if the compiler thinks the memory is never going to accessed again after that. Seems like a perfect candidate for volatile. But I&#39;m having some problems actually getting this to work with GCC. Here is an example function:

    void volatileZeroMemory(volatile void* ptr, unsigned long long size)
    {
    	volatile unsigned char* bytePtr = (volatile unsigned char*)ptr;
    	
    	while (size--)
    	{
    		*bytePtr++ = 0;
    	}
    }

Simple enough. But the code that GCC actually generates if you call it varies wildly with the compiler version and the amount of bytes you&#39;re actually trying to zero. https://godbolt.org/g/cMaQm2

 - GCC 4.4.7 and 4.5.3 never ignore the volatile.
 - GCC 4.6.4 and 4.7.3 ignore volatile for array sizes 1, 2, and 4.
 - GCC 4.8.1 until 4.9.2 ignore volatile for array sizes 1 and 2.
 - GCC 5.1 until 5.3 ignore volatile for array sizes 1, 2, 4, 8.
 - GCC 6.1 just ignores it for any array size (bonus points for consistency).

Any other compiler I have tested (clang, icc, vc) generates the stores one would expect, with any compiler version and any array size. So at this point I&#39;m wondering, is this a (pretty old and severe?) GCC compiler bug, or is the definition of volatile in the standard that imprecise that this is actually conforming behavior, making it essentially impossible to write a portable &quot;SecureZeroMemory&quot; function?

Edit: Some interesting observations.

    #include &lt;cstddef&gt;
    #include &lt;cstdint&gt;
    #include &lt;cstring&gt;
    #include &lt;atomic&gt;
    
    void callMeMaybe(char* buf);
    
    void volatileZeroMemory(volatile void* ptr, std::size_t size)
    {
    	for (auto bytePtr = static_cast&lt;volatile std::uint8_t*&gt;(ptr); size-- &gt; 0; )
    	{
    		*bytePtr++ = 0;
    	}
    	
    	//std::atomic_thread_fence(std::memory_order_release);
    }
    
    std::size_t foo()
    {
    	char arr[8];
    	callMeMaybe(arr);
    	volatileZeroMemory(arr, sizeof arr);
    	return sizeof arr;
    }

[The possible write from callMeMaybe() will make all GCC versions except 6.1 generate the expected stores.](https://godbolt.org/g/v8lMjG) Commenting in the memory fence will also make GCC 6.1 generate the stores, although only in combination with the possible write from callMeMaybe().

Someone has also suggested to flush the caches. [Microsoft does **not** try to flush the cache at all in &quot;SecureZeroMemory&quot;.](http://codepad.org/1yC7a8J8) The cache is likely going to be invalidated pretty fast anyway, so this is probably not be a big deal. Also, if another program was trying to probe the data, or if it was going to be written to the page file, it would always be the zeroed version.

There are also some concerns about GCC 6.1 using memset() in the standalone function. The GCC 6.1 compiler on godbolt might a broken build, as GCC 6.1 seems to generate a normal loop (like 5.3 does on godbolt) for the standalone function for some people. (Read comments of zwol&#39;s answer.)

Is the definition of &quot;volatile&quot; this volatile, or is GCC having some standard compliancy problems?

I want to inspect the assembly output of applying `boost::variant` in my code in order to see which intermediate calls are optimized away.

When I compile the following example (with GCC 5.3 using `g++ -O3 -std=c++14 -S`), it seems as if the compiler optimizes away everything and directly returns 100:

    (...)
    main:
    .LFB9320:
    	.cfi_startproc
    	movl	$100, %eax
    	ret
    	.cfi_endproc
    (...)

---


    #include &lt;boost/variant.hpp&gt;
    
    struct Foo
    {
        int get() { return 100; }
    };
    
    struct Bar
    {
        int get() { return 999; }
    };
    
    using Variant = boost::variant&lt;Foo, Bar&gt;;
    
    
    int run(Variant v)
    {
        return boost::apply_visitor([](auto&amp; x){return x.get();}, v);
    }
    int main()
    {
        Foo f;
        return run(f);
    }

However, the full assembly output contains much more than the above excerpt, which to me looks like it is never called. **Is there a way to tell GCC/clang to remove all that &quot;noise&quot; and just output what is actually called when the program is ran?**

---

**full assembly output:**

    	.file	&quot;main1.cpp&quot;
    	.section	.rodata.str1.8,&quot;aMS&quot;,@progbits,1
    	.align 8
    .LC0:
    	.string	&quot;/opt/boost/include/boost/variant/detail/forced_return.hpp&quot;
    	.section	.rodata.str1.1,&quot;aMS&quot;,@progbits,1
    .LC1:
    	.string	&quot;false&quot;
    	.section	.text.unlikely._ZN5boost6detail7variant13forced_returnIvEET_v,&quot;axG&quot;,@progbits,_ZN5boost6detail7variant13forced_returnIvEET_v,comdat
    .LCOLDB2:
    	.section	.text._ZN5boost6detail7variant13forced_returnIvEET_v,&quot;axG&quot;,@progbits,_ZN5boost6detail7variant13forced_returnIvEET_v,comdat
    .LHOTB2:
    	.p2align 4,,15
    	.weak	_ZN5boost6detail7variant13forced_returnIvEET_v
    	.type	_ZN5boost6detail7variant13forced_returnIvEET_v, @function
    _ZN5boost6detail7variant13forced_returnIvEET_v:
    .LFB1197:
    	.cfi_startproc
    	subq	$8, %rsp
    	.cfi_def_cfa_offset 16
    	movl	$_ZZN5boost6detail7variant13forced_returnIvEET_vE19__PRETTY_FUNCTION__, %ecx
    	movl	$49, %edx
    	movl	$.LC0, %esi
    	movl	$.LC1, %edi
    	call	__assert_fail
    	.cfi_endproc
    .LFE1197:
    	.size	_ZN5boost6detail7variant13forced_returnIvEET_v, .-_ZN5boost6detail7variant13forced_returnIvEET_v
    	.section	.text.unlikely._ZN5boost6detail7variant13forced_returnIvEET_v,&quot;axG&quot;,@progbits,_ZN5boost6detail7variant13forced_returnIvEET_v,comdat
    .LCOLDE2:
    	.section	.text._ZN5boost6detail7variant13forced_returnIvEET_v,&quot;axG&quot;,@progbits,_ZN5boost6detail7variant13forced_returnIvEET_v,comdat
    .LHOTE2:
    	.section	.text.unlikely._ZN5boost6detail7variant13forced_returnIiEET_v,&quot;axG&quot;,@progbits,_ZN5boost6detail7variant13forced_returnIiEET_v,comdat
    .LCOLDB3:
    	.section	.text._ZN5boost6detail7variant13forced_returnIiEET_v,&quot;axG&quot;,@progbits,_ZN5boost6detail7variant13forced_returnIiEET_v,comdat
    .LHOTB3:
    	.p2align 4,,15
    	.weak	_ZN5boost6detail7variant13forced_returnIiEET_v
    	.type	_ZN5boost6detail7variant13forced_returnIiEET_v, @function
    _ZN5boost6detail7variant13forced_returnIiEET_v:
    .LFB9757:
    	.cfi_startproc
    	subq	$8, %rsp
    	.cfi_def_cfa_offset 16
    	movl	$_ZZN5boost6detail7variant13forced_returnIiEET_vE19__PRETTY_FUNCTION__, %ecx
    	movl	$39, %edx
    	movl	$.LC0, %esi
    	movl	$.LC1, %edi
    	call	__assert_fail
    	.cfi_endproc
    .LFE9757:
    	.size	_ZN5boost6detail7variant13forced_returnIiEET_v, .-_ZN5boost6detail7variant13forced_returnIiEET_v
    	.section	.text.unlikely._ZN5boost6detail7variant13forced_returnIiEET_v,&quot;axG&quot;,@progbits,_ZN5boost6detail7variant13forced_returnIiEET_v,comdat
    .LCOLDE3:
    	.section	.text._ZN5boost6detail7variant13forced_returnIiEET_v,&quot;axG&quot;,@progbits,_ZN5boost6detail7variant13forced_returnIiEET_v,comdat
    .LHOTE3:
    	.section	.text.unlikely,&quot;ax&quot;,@progbits
    .LCOLDB4:
    	.text
    .LHOTB4:
    	.p2align 4,,15
    	.globl	_Z3runN5boost7variantI3FooJ3BarEEE
    	.type	_Z3runN5boost7variantI3FooJ3BarEEE, @function
    _Z3runN5boost7variantI3FooJ3BarEEE:
    .LFB9310:
    	.cfi_startproc
    	subq	$8, %rsp
    	.cfi_def_cfa_offset 16
    	movl	(%rdi), %eax
    	cltd
    	xorl	%edx, %eax
    	cmpl	$19, %eax
    	ja	.L7
    	jmp	*.L9(,%rax,8)
    	.section	.rodata
    	.align 8
    	.align 4
    .L9:
    	.quad	.L30
    	.quad	.L10
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.quad	.L7
    	.text
    	.p2align 4,,10
    	.p2align 3
    .L7:
    	call	_ZN5boost6detail7variant13forced_returnIiEET_v
    	.p2align 4,,10
    	.p2align 3
    .L30:
    	movl	$100, %eax
    .L8:
    	addq	$8, %rsp
    	.cfi_remember_state
    	.cfi_def_cfa_offset 8
    	ret
    	.p2align 4,,10
    	.p2align 3
    .L10:
    	.cfi_restore_state
    	movl	$999, %eax
    	jmp	.L8
    	.cfi_endproc
    .LFE9310:
    	.size	_Z3runN5boost7variantI3FooJ3BarEEE, .-_Z3runN5boost7variantI3FooJ3BarEEE
    	.section	.text.unlikely
    .LCOLDE4:
    	.text
    .LHOTE4:
    	.globl	_Z3runN5boost7variantI3FooI3BarEEE
    	.set	_Z3runN5boost7variantI3FooI3BarEEE,_Z3runN5boost7variantI3FooJ3BarEEE
    	.section	.text.unlikely
    .LCOLDB5:
    	.section	.text.startup,&quot;ax&quot;,@progbits
    .LHOTB5:
    	.p2align 4,,15
    	.globl	main
    	.type	main, @function
    main:
    .LFB9320:
    	.cfi_startproc
    	movl	$100, %eax
    	ret
    	.cfi_endproc
    .LFE9320:
    	.size	main, .-main
    	.section	.text.unlikely
    .LCOLDE5:
    	.section	.text.startup
    .LHOTE5:
    	.section	.rodata
    	.align 32
    	.type	_ZZN5boost6detail7variant13forced_returnIvEET_vE19__PRETTY_FUNCTION__, @object
    	.size	_ZZN5boost6detail7variant13forced_returnIvEET_vE19__PRETTY_FUNCTION__, 58
    _ZZN5boost6detail7variant13forced_returnIvEET_vE19__PRETTY_FUNCTION__:
    	.string	&quot;T boost::detail::variant::forced_return() [with T = void]&quot;
    	.align 32
    	.type	_ZZN5boost6detail7variant13forced_returnIiEET_vE19__PRETTY_FUNCTION__, @object
    	.size	_ZZN5boost6detail7variant13forced_returnIiEET_vE19__PRETTY_FUNCTION__, 57
    _ZZN5boost6detail7variant13forced_returnIiEET_vE19__PRETTY_FUNCTION__:
    	.string	&quot;T boost::detail::variant::forced_return() [with T = int]&quot;
    	.ident	&quot;GCC: (Ubuntu 5.3.0-3ubuntu1~14.04) 5.3.0 20151204&quot;
    	.section	.note.GNU-stack,&quot;&quot;,@progbits

How to remove &quot;noise&quot; from GCC/clang assembly output?

Windows 10 Anniversary Update includes the Linux Subsystem for Ubuntu. I installed gcc with `sudo apt-get install gcc`.

I wrote some simple C code for testing purposes:

    #include &lt;stdio.h&gt;
    int main(void){
    	printf(&quot;Hello\n&quot;);
    	return 0;
    }

And compiled it with `gcc -c main.c` but the execute (Linux only) `main.o` is generated. If I run it `./main.o`, it displays `Hello`.

My question is, how can I compile `main.c` so that Windows can run it? Basically, how do you generate a `*.exe` file with GCC in Linux Subsystem ?


How to compile executable for Windows with GCC with Linux Subsystem?

It is possible for a GCC plugin to add a new builtin function? If so, how to do it properly?

GCC version is 5.3 (or newer). The code is compiled and processed by the plugin written in C.

It is mentioned in the [rationale for GCC plugins at gcc-melt.org](http://starynkevitch.net/Basile/gcc-melt/) that this is doable but I cannot see how.

As far as I can see in the sources of GCC, the builtins are created using `add_builtin_function()` from [gcc/langhooks.c](https://github.com/gcc-mirror/gcc/blob/gcc-5-branch/gcc/langhooks.c#L605):

    tree
    add_builtin_function (const char *name,
          tree type,
          int function_code,
          enum built_in_class cl,
          const char *library_name,
          tree attrs)

It is more or less clear which values the arguments of this function should have, except for `function_code`, a unique numeric ID of the function.

Looks like (see `add_builtin_function_common()`), a value from `enum built_in_function` is expected there but a GCC plugin cannot change that enum.

One cannot pass any random value greater than `END_BUILTINS` as `function_code` either, it seems. `builtin_decl_implicit()` and `builtin_decl_explicit()` would have a failed assertion in that case.

So, what is the proper way to add a builtin in a GCC plugin (without using MELT and such, just GCC plugin API)?

**Update**
I looked again at the implementation of `add_builtin_function_common()` and of `langhooks.builtin_function()` for C as well as at how these are used in GCC. It seems that 0 is acceptable as `function_code` in some cases. You cannot use `builtin_decl_implicit()` then but you can save the DECL returned by `add_builtin_function()` and use it later.

Looks like the only event when I can try to create built-ins that way is PLUGIN_START_UNIT (otherwise GCC may crash due to `external_scope` variable being NULL).

I tried the following at that stage (`fntype` was created before):

    decl = add_builtin_function (
        &quot;my_helper&quot;, fntype,
        0 /* function_code */,
        BUILT_IN_NORMAL /* enum built_in_class cl */,
        NULL /* library_name */,
        NULL_TREE /* attrs */)

`my_helper` was defined in a different C source file compiled and linked with the main source file. Then I used decl to insert the calls to that function into other functions (`gimple_build_call`) during my GIMPLE pass.

GCC output no errors and indeed inserted the call to `my_helper` but as a call to an ordinary function. I actually needed a builtin to avoid a call but rather insert the body of the function.

On the other hand, `tsan0` pass, which executes right after my pass, inserts the calls of builtin functions just like one would expect: there is no explicit call as a result, just the body of the function is inserted. Its builtins, however, are defined by GCC itself rather than by the plugins.

So I suppose my builtin still needs something to be a valid builtin, but I do not know what it is. What could that be?


How to add a builtin function in a GCC plugin?

I saw a program in C that had code like the following:

    static void *arr[1]  = {&amp;&amp; varOne,&amp;&amp; varTwo,&amp;&amp; varThree};

    varOne: printf(&quot;One&quot;) ;
    varTwo: printf(&quot;Two&quot;) ;
    varThree: printf(&quot;Three&quot;) ;


I am confused about what the `&amp;&amp;` does because there is nothing to the left of it. Does it evaluate as null by default? Or is this a special case?

Edit: 
Added some more information to make the question/code more clear for my question.
Thank you all for the help. This was a case of the gcc specific extension.

What does a &amp;&amp; operator do when there is no left side in C?

I&#39;ve added AddressSanitizer flag as follow:

    set (CMAKE_CXX_FLAGS &quot;${CMAKE_CXX_FLAGS} -fsanitize=address&quot;)

Everything builds and runs fine when using `Unix Makefiles`.

The problem comes when generating the Xcode project, it just doesn&#39;t want to link because it cannot find the ASan library.

I already found two solutions, but decided not to use them because they cannot be automated using just CMake:

 1. Adding `-Wl,-undefined,dynamic_lookup` to the linked flags, so it skips linking to dynamic libraries. 
 2. Link with `libclang_rt.asan_osx_dynamic.dylib` directly.

So what&#39;s the problem with these two solutions?

 - When using solution #1, I have to manually open the target scheme in Xcode and add `DYLD_INSERT_LIBRARIES` environment variable pointing to `libclang_rt.asan_osx_dynamic.dylib`.
 - When using solution #2, the path for the ASan library varies between computers.

Additionally as another solution, I tried enabling Address Sanitizer flag from the Xcode target scheme but interestingly it didn&#39;t detect the issues I added, so I didn&#39;t list this as a solution because it failed my test.

Any help will be much appreciated.

Content Type	Original Author	Original Content on Stackoverflow
Question	mrgloom	View Question on Stackoverflow
Solution 1 - Gcc	yugr	View Answer on Stackoverflow
Solution 2 - Gcc	Jonny	View Answer on Stackoverflow
Solution 3 - Gcc	Smeeheey	View Answer on Stackoverflow

How to use AddressSanitizer with GCC?

Gcc Problem Overview

Gcc Solutions

Solution 1 - Gcc

Solution 2 - Gcc

Solution 3 - Gcc

Can't get currentUser on load

How do I define a variable for the dependency version in Gradle

Attributions