I think this is a valid question. It can be a bit hard to find up to date information on assembler.

1. Yes. A lot of resources printed and online describe i386 (x86) assembler and not the new amd64 (x86_64). Many things have changed, e.g. function arguments used to be passed on the stack but now they are passed in registers. This applies both to Unix and Windows.

   Basically, ensure you are reading about 64-bit assembly.

2. Why not try the [online manual][1]. Note that assemblers are not that different when it comes to simple stuff.

3. I don&#39;t have Windows but if you are having trouble with any specific program, you could ask about it here. You will need to post the actual failing program.

4. Yes but you have to link it against 32-bit libraries and use the 32-bit version of the Win32 API. But if you&#39;re starting out, why program in the 1980&#39;s when you can work with the modern instruction set?

5. Try [this][2].

**Also**, if you are going to be programming in assembly, I strongly recommend you get a debugger. I use GDB which works well and is free, on Windows you get to use the Visual Studio debugger which is superb.


  [1]: http://flatassembler.net/docs.php?article=manual
  [2]: https://stackoverflow.com/questions/1023593/how-to-write-hello-world-in-assembler-under-windows#answer-20032763

## UPDATE:
I&#39;ve written a detailed tutorial that incorporates the top two answers on this question: http://blog.johannesmp.com/2015/09/01/installing-clang-on-windows-pt1/

&lt;br/&gt;

----------


# TL;DR

On Windows, Given the following program:

    #include &lt;iostream&gt;

    int main()
    {
        int arr[] = {1, 2, 3, 4, 5};
        for(auto el : arr)
        {
            std::cout &lt;&lt; el &lt;&lt; std::endl;
        }
        return 0;
    }

I want to be able to do the following:

    clang++ hello.cpp -o hello.exe -std=c++14

And get a 64 bit executable that *just works*. I don&#39;t want to have to append a ton of `-I` includes to tell clang where to find `iostream` or other standard c++ headers; I don&#39;t want to have to link in multiple steps.

I don&#39;t care so much about performance, efficiency, what linker is used, etc. I just want to be able to have clang/gcc/whatever set up correctly so that I can use a single, quick and dirty, console command like the one above.


What do I need to install for that to *just work*?

----------

# The Problem

As a predominately mac/linux user I&#39;m used to being able to just use a package manager to install the latest version of clang, which *just works*.

I&#39;m now trying to set up clang/gnu compiler on windows and it seems to be far more difficult, If only because there is little to no straightforward documentation out there (that I&#39;ve been able to find)


I&#39;ve tried to follow this tutorial: https://yongweiwu.wordpress.com/2014/12/24/installing-clang-3-5-for-windows - and was able to use it to get clang to build and link (using gcc 4.8.2), but the resulting binaries were 32 bit.

I&#39;ve tried installing the latest prebuilt binaries of clang ([3.6.2][1]) and the 64 bit version of mingw-w64 ([4.9.3 for 64 bit with posix and sjlj for exceptions][2]), and am getting:

    hello.cpp:1:10: fatal error: &#39;iostream&#39; file not found
    #include &lt;iostream&gt;
             ^
    1 error generated.

Which seems to indicate that clang is not seeing gcc&#39;s files. It seems that some versions of LLVM/clang are looking for only certain versions of gcc, but that doesn&#39;t seem to be documented anywhere?

Similarly someone mentioned to me on the LLVM IRC that you need to modify clang&#39;s driver to look for gcc in certain paths?

---

# What I&#39;m looking for

I&#39;m fine with building LLVM/Clang from source if necessary, but I&#39;m really just looking for clear, step-by-step instructions that allow me to use `clang++` as easily as I&#39;m able to do with mac/linux

Something like:

1. Build `this version` of LLVM/Clang and place it in `that directory`
2. Download and install `this version` of cygwin (or mingw32 or mingw-w64) and install `these packages`.
3. etc..


  [1]: http://llvm.org/releases/3.6.2/LLVM-3.6.2-win32.exe
  [2]: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.3/threads-posix/sjlj/x86_64-4.9.3-release-posix-sjlj-rt_v4-rev0.7z/download

What do you need to install to use Clang on windows to build c++14 for 64 bit?

I have downloaded the Visual Studio Community 2015 (free version) and I don&#39;t see when the expiration date is.

I have tried to see the expiration date at Help Menu -&gt; About Microsoft Visual Studio and there is no expiration date there.

Is there any expiration date (I have a Microsoft account)? If yes, Where can I see it? Or until when is it?

Visual Studio Community 2015 expiration date

Okay so I know C++, C#, Java and some other languages and I decided to learn assembly next but I feel like I&#39;ve hit a solid brick wall right from the start. I just need someone to point me in the right direction.

Here are the questions:

1. I&#39;ve been told that it&#39;s better to learn assembly from the internet than from books because assembly depends on your hardware and books are mostly outdated. Is that true?

2. I&#39;ve got a 64 bit CPU and I&#39;m using (or at least trying to use) FASM. Where do I find the necessary documentation?

3. I&#39;m totaly confused because most of the tutorials I&#39;ve seen don&#39;t even work for me. Is that because of the hardware differences? How do I find the right tutorials?

4. Can I run x86 and x32 assembly on my 64 bit computer?

5. Could you please be so kind and write me a simple program in assembly (that works on my PC) with a breakdown in the comments? I&#39;m running 64 bit Windows 10 on my intel core i5 CPU. Please.

Where to learn x64 assembly from?

Okay so I know C++, C#, Java and some other languages and I decided to learn assembly next but I feel like I've hit a solid brick wall right from the start. I just need someone to point me in the right direction.
Here are the questions:
<ol>
<li>
I've been told that it's better to learn assembly from the internet than from books because assembly depends on your hardware and books are mostly outdated. Is that true?
</li>
<li>
I've got a 64 bit CPU and I'm using (or at least trying to use) FASM. Where do I find the necessary documentation?
</li>
<li>
I'm totaly confused because most of the tutorials I've seen don't even work for me. Is that because of the hardware differences? How do I find the right tutorials?
</li>
<li>
Can I run x86 and x32 assembly on my 64 bit computer?
</li>
<li>
Could you please be so kind and write me a simple program in assembly (that works on my PC) with a breakdown in the comments? I'm running 64 bit Windows 10 on my intel core i5 CPU. Please.
</li>
</ol>

All the following instructions do the same thing: set `%eax` to zero. Which way is optimal (requiring fewest machine cycles)?

    xorl   %eax, %eax
    mov    $0, %eax
    andl   $0, %eax


What is the best way to set a register to zero in x86 assembly: xor, mov or and?

LOOP ([Intel ref manual entry][1])
decrements ecx / rcx, [and then jumps if non-zero][2].  It&#39;s slow, but couldn&#39;t Intel have cheaply made it fast?  `dec/jnz` already [macro-fuses into a single uop][3] on Sandybridge-family; the only difference being that that sets flags.

`loop` on various microarchitectures, from [Agner Fog&#39;s instruction tables][4]:

* K8/K10: 7 m-ops
* **Bulldozer-family/Ryzen**: 1 m-op (same cost as macro-fused test-and-branch, or `jecxz`)

* P4: 4 uops (same as `jecxz`)
* P6 (PII/PIII): 8 uops
* Pentium M, Core2: 11 uops
* Nehalem: 6 uops.  (11 for `loope` / `loopne`).  Throughput = 4c (`loop`) or 7c (`loope/ne`).
* **SnB-family**: 7 uops.  (11 for `loope` / `loopne`).  **Throughput = one per 5 cycles**, as much of a bottleneck as keeping your loop counter in memory! `jecxz` is only 2 uops with same throughput as regular `jcc`
* Silvermont: 7 uops
* AMD Jaguar (low-power): 8 uops, 5c throughput
* Via Nano3000: 2 uops


---

Couldn&#39;t the decoders just decode the same as `lea rcx, [rcx-1]` / `jrcxz`?  That would be 3 uops.  At least that would be the case with no address-size prefix, otherwise it has to use `ecx` and truncate `RIP` to `EIP` if the jump is taken; **maybe the odd choice of address-size controlling the width of the decrement explains the many uops?**  (Fun fact: `rep`-string instructions have the same behaviour with using `ecx` with 32-bit address-size.)

Or better, just decode it as a fused dec-and-branch that doesn&#39;t set flags?  `dec ecx` / `jnz` on SnB decodes to a single uop (which does set flags).

I know that real code doesn&#39;t use it (because it&#39;s been slow since at least P5 or something), but AMD decided it was worth it to make it fast for Bulldozer.  Probably because it was easy.

---

* **Would it be easy for SnB-family uarch to have fast `loop`?**  If so, why don&#39;t they?  If not, why is it hard?  A lot of decoder transistors?  Or extra bits in a fused dec&amp;branch uop to record that it doesn&#39;t set flags?  What could those 7 uops be doing?  It&#39;s a really simple instruction.

* **What&#39;s special about Bulldozer that made a fast `loop` easy / worth it?**  Or did AMD waste a bunch of transistors on making `loop` fast?  If so, presumably someone thought it was a good idea.

----

**If `loop` was fast**, it would be perfect for [BigInteger arbitrary-precision `adc` loops, to avoid partial-flag stalls / slowdowns][5]  (see my comments on my answer), or any other case where you want to loop without touching flags.  It also has a minor code-size advantage over `dec/jnz`.  (And `dec/jnz` only macro-fuses on SnB-family).

On modern CPUs where `dec/jnz` is ok in an ADC loop, `loop` would still be nice for ADCX / ADOX loops (to preserve OF).

If `loop` had been fast, compilers would already be using it as a peephole optimization for code-size + speed on CPUs without macro-fusion.

---

It wouldn&#39;t stop me from getting annoyed at all the questions with bad 16bit code that uses `loop` for every loop, even when they also need another counter inside the loop.  But at least it wouldn&#39;t be *as* bad.


  [1]: http://felixcloutier.com/x86/LOOP:LOOPcc.html
  [2]: https://stackoverflow.com/questions/46881279/how-exactly-does-the-x86-loop-instruction-work/46881622#46881622
  [3]: https://stackoverflow.com/questions/31771526/x86-64-assembly-loop-conditions-and-out-of-order
  [4]: http://agner.org/optimize/
  [5]: https://stackoverflow.com/questions/32084204/problems-with-adc-sbb-and-inc-dec-in-tight-loops-on-some-cpus

Why is the loop instruction slow? Couldn&#39;t Intel have implemented it efficiently?

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?

While I&#39;ve seen docs on using `rustc` directly to output assembly, having to manually extract commands used by Cargo and edit them to write assembly is tedious.

Is there a way to run Cargo that writes out assembly files?

How to get assembly output from building with Cargo?

In general, for `int num`, `num++` (or `++num`), as a read-modify-write operation, is **not atomic**. But I often see compilers, for example [GCC][1], generate the following code for it ([try here][2]):

```c
void f()
{
  int num = 0;
  num++;
}
```

```assembly
f():
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], 0
        add     DWORD PTR [rbp-4], 1
        nop
        pop     rbp
        ret
```

Since line 5, which corresponds to `num++` is one instruction, can we conclude that `num++` **is atomic** in this case?

And if so, **does it mean that so-generated `num++` can be used in concurrent (multi-threaded) scenarios without any danger of data races** (i.e. we don&#39;t need to make it, for example, `std::atomic&lt;int&gt;` and impose the associated costs, since it&#39;s atomic anyway)?

**UPDATE**

Notice that this question is *not* whether increment *is* atomic (it&#39;s not and that was and is the opening line of the question). It&#39;s whether it *can* be in particular scenarios, i.e. whether one-instruction nature can in certain cases be exploited to avoid the overhead of the `lock` prefix. And, as the accepted answer mentions in the section about uniprocessor machines, as well as [this answer][3], the conversation in its comments and others explain, **it can** (although not with C or C++).


  [1]: https://en.wikipedia.org/wiki/GNU_Compiler_Collection
  [2]: https://godbolt.org/g/UFKEvp
  [3]: https://stackoverflow.com/a/39414316/4973224

Can num++ be atomic for &#39;int num&#39;?

When I try to run my Android app on an emulator I get this error: 

&gt; /dev/kvm permission denied. 

I checked the permissions and added the user I am currently logged in with to the kvm group. What is wrong?

Android Studio: /dev/kvm device permission denied

So here&#39;s the bug: In a **64-Bit** VBA host (for example Access 365 64-bit or Excel 2016 64-bit) create a class module `SomeClass`:

```lang-vb
&#39; this needs to be here to trigger the bug: 
Private Sub Class_Terminate()
End Sub
```

and then some module `Test`: 

```lang-vb
Function ReturnFalse(o As Object) As Boolean
    ReturnFalse = False
End Function

Sub Test()
    Debug.Print ReturnFalse(New SomeClass)
    If ReturnFalse(New SomeClass) Then
        Debug.Print True
    Else
        Debug.Print False
    End If    
End Sub
```

Now, if you are using a **32-bit** VBA host and run &quot;Test&quot; in the immediate window, the the expected result shows up: 

```
False
False
```

However, if you are using a **64-bit** VBA host, then this comes out: 

```
False
True
```

Except, when you remove or rename the `Class_Terminate()` sub, in which case the correct output appears. 

I&#39;ve tracked the bug down to this minimal example. Apparently, the problem seems to be, that using a temporary object (`new SomeClass` here) breaks the evaluation of the `IF` condition somehow, making it appear that the value of the condition is `True` not matter what. 

OK, that&#39;s a serious bug, because the 64 bit compiler is bonkers and all `IF` are in trouble. 

All `IF`? what about `WHILE`?

    While ReturnFalse(New SomeClass)
     Debug.Print &quot;Oh no!&quot;
    Wend

Yes, `WHILE` is also in trouble, because this prints &quot;Oh No!&quot; in a loop.

That&#39;s a lot of trouble and I could reproduce it everywhere: 

* Microsoft&#174; Access&#174; f&#252;r Microsoft 365 MSO (16.0.14026.20294) 64-Bit 
* Microsoft Access 2016 MSO (16.0.9029.2167) 64-Bit
* Microsoft Access 2013 (15.0.4420.1017) MSO (15.0.4420.1017) 64-Bit

..And also in **Excel** of course. 

Summary: I could find this bug in all versions of Office I have, starting from 2013 and it is probably at least 8 years old. 

Ok, did this bug affect other people before? Yes: 

This post last year: 

https://stackoverflow.com/questions/65041832/vba-takes-wrong-branch-at-if-statement-severe-compiler-bug/68032045#68032045

This post in excel.uservoice.com (which apparently is Microsoft&#39;s user suggestion box or something) from *October 2018*: 

https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/35735881-fix-inlined-member-calls-on-user-objects-on-64-bi

Allright, so let&#39;s file a bug report. 

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_excel-mso_mac-mso_mac2016/how-do-i-report-vba-bugs/bb4e5dea-9996-4232-9b5b-7dd57f76736c

&gt; If, after testing with others, the code fails and it really shouldn&#39;t, you can report the issue directly to Microsoft using the Smile button in Excel.

What? 

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_excel-mso_win10-mso_2016/excel-2016-vba-bug/b799dfc2-7cef-417d-8a41-96661a360c43

&gt; 1. Open Excel &gt; File &gt; Feedback &gt; Send a Frown
&gt; 2. Through Uservoice - Click the following link to see the feedback of others and to provide feedback - https://excel.uservoice.com/

This is not a suggestion for a new icon color scheme. It is an 8 year old bug, which makes Access apps and Excel sheets with macros compute wrong answers (and also it blocks a migration to Office 64 here, because we can not get our code out). 

Now here are my question:

* How can I get this bug fixed? 
* Is someone with a reasonably impressive SLA or better connections here who would support my request? 
* Is there a way to report VBA bugs directly? (This, because we currently suspect more bugs in the 64-bit VBA)
* I&#39;ve made a new report in uservoice. Do you think it could be voted up? https://access.uservoice.com/forums/319956-access-desktop-application/suggestions/43660329-fix-this-64-bit-vba-compiler-bug-temporary-object

**UPDATE**: x-posted to

https://answers.microsoft.com/en-us/msoffice/forum/msoffice_excel-msoffice_custom-mso_2019/invalid-code-by-vba-64-bit-compiler/b91f984a-194c-4453-b8c5-02881afaf83b

**UPDATE 2**:

I had the chance to try the code on a Office 365 for Mac installation (where Win64 is defined as `true`) and *the bug does not show up there*. So it&#39;s a PC thing right now.

**UPDATE 3**: 

Post made it to HN and The Register: 

https://www.theregister.com/2021/08/19/64_bit_microsoft_vba_bug/
https://news.ycombinator.com/item?id=28188251

**UPDATE 4**: 

Just checked today (2021-11-15) against Office 365 and the ***bug ist gone now***! Looks like somebody payed attention. I can&#39;t figure out however, which of the gazillion cumulative updates I received this year did the trick and don&#39;t know yet, if the other Office versions are fixed too. 


Content Type	Original Author	Original Content on Stackoverflow
Question	AlanKalane	View Question on Stackoverflow
Solution 1 - Assembly	jforberg	View Answer on Stackoverflow

Where to learn x64 assembly from?

Assembly Problem Overview

Assembly Solutions

Solution 1 - Assembly

Visual Studio Community 2015 expiration date

What do you need to install to use Clang on windows to build c++14 for 64 bit?

Attributions