[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #48 from Sven C. Dack sven.c.dack at virginmedia dot com --- ... With the linker plugin enabled does it actually link libgcc_s.so and libstdc++.so dynamically to it, while for the other three it did not: That looks odd. Btw, -fuse-linker-plugin should be the default if you have recent enough binutils. Richard I have been trying to get around this oddity by creating a statically linked compiler, but I keep running into the same problem. Is the building of a statically linked gcc (with lto and linker plugin enabled) actually supported? I keep using --with-boot-ldflags=... -static -fuse-linker-plugin, but get the message: xgcc: error: -fuse-linker-plugin is not supported in this configuration This happens while make is configuring for stage 3: ... rm -f stage_current make[3]: Leaving directory '/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin' make[2]: Leaving directory '/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin' make[2]: Entering directory '/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin' Configuring stage 3 in ./lto-plugin Configuring stage 3 in ./zlib Configuring stage 3 in ./intl Configuring stage 3 in ./libdecnumber Configuring stage 3 in ./libiberty Configuring stage 3 in ./libbacktrace ... $ more libbacktrace/config.log ... configure:2936: checking for C compiler default output file name configure:2958: /var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/xgcc -B/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home /sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/lib/ -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/include -isystem /home/sven/gcc-lto-plu gin/x86_64-unknown-linux-gnu/sys-include-g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -static -flto=1 -flto-partition=none -fuse-linker-plugin conftest.c 5 xgcc: error: -fuse-linker-plugin is not supported in this configuration ... It can be seen for all the directories that are being configured for stage 3. Without -fuse-linker-plugin does it create a compiler and it also works for a non-static build.
[Bug tree-optimization/59586] [4.8/4.9/5 Regression] [graphite] Segmentation fault with -Ofast -floop-parallelize-all -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added CC||drfiemost at email dot it --- Comment #5 from Matthias Klose doko at gcc dot gnu.org --- *** Bug 62114 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/62114] [graphite] ICE using -floop-parallelize-all and -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62114 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Matthias Klose doko at gcc dot gnu.org --- this seems to be a duplicate of PR59586 *** This bug has been marked as a duplicate of bug 59586 ***
[Bug tree-optimization/59586] [4.8/4.9 Regression] [graphite] Segmentation fault with -Ofast -floop-parallelize-all -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added CC||doko at gcc dot gnu.org Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] |[graphite] Segmentation |[graphite] Segmentation |fault with -Ofast |fault with -Ofast |-floop-parallelize-all |-floop-parallelize-all |-ftree-parallelize-loops|-ftree-parallelize-loops --- Comment #6 from Matthias Klose doko at gcc dot gnu.org --- this is fixed in r212122 on the trunk (without mentioning the bug number).
[Bug c++/62164] New: 5.0: ICE: error: Both section and comdat group is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62164
Bug ID: 62164
Summary: 5.0: ICE: error: Both section and comdat group is set
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at os dot inf.tu-dresden.de
The following code causes an ICE:
class T { static void t(); };
class U
{
public:
static void u() __attribute__ ((__section__ (.initcall.text)));
};
inline void U::u() {}
void T::t() { U::u(); }
$ g++ --version
g++ (GCC) 5.0.0 20140817 (experimental)
$ g++ -c t.c
t.c:11:23: error: Both section and comdat group is set
void T::t() { U::u(); }
^
_ZN1U1uEv/0 (static void U::u()) @0x7f3c83ebe000
Type: function definition analyzed
Visibility: public weak comdat comdat_group:_ZN1U1uEv one_only
section:.initcall.text
References:
Referring:
First run: 0
Function flags: body
Called by: _ZN1T1tEv/2 (1.00 per call)
Calls:
t.c:11:23: internal compiler error: verify_cgraph_node failed
0x858967 cgraph_node::verify_node()
../../gcc/gcc/cgraph.c:2978
0x84f757 symtab_node::verify()
../../gcc/gcc/symtab.c:1200
0x850eb7 symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.c:1220
0x85e73a compile()
../../gcc/gcc/cgraphunit.c:2157
0x860874 finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2331
0x6500b5 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4649
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
The problem seems to be that U::u() is tagged inline. If it is not inline,
there is no ICE.
No ICE for = 4.9.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #49 from Sven C. Dack sven.c.dack at virginmedia dot com --- The problem seems to be a missing liblto_plugin.so in gcc's directory for stage2. I used: --with-boot-ldflags=-static -flto=1 -flto-partition=none -fuse-linker-plugin together with: --enable-linker-plugin-flags=-pipe -O2 -march=native -fomit-frame-pointer -fno-builtin-memcmp to avoid the -static option from being passed onto the plugin, but it fails. During stage1 does it still work and builds liblto_plugin.so as follows: ... /bin/bash ./libtool --tag=CC --tag=disable-static --mode=compile gcc -DHAVE_CONFIG_H -I. -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin lto-plugin -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin ../include -DHAVE_CONFIG_H -Wall -g -c -o lto-plugin.lo /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/lto-plugin.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/../include -DHAVE_CONFIG_H -Wall -g -c /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/lto-plugin.c -fPIC -DPIC -o .libs/lto-plugin.o /bin/bash ./libtool --tag=CC --tag=disable-static --mode=link gcc -Wall -g -Wc,-static-libgcc -module -bindir /home/sven/gcc-lto-plugin/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2 -static-libstdc++ -static-libgcc -pipe -O2 -march=native -fomit-frame-pointer -fno-builtin-memcmp -o liblto_plugin.la -rpath /home/sven/gcc-lto-plugin/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2 lto-plugin.lo -Wc,../libiberty/pic/libiberty.a libtool: link: gcc -shared .libs/lto-plugin.o-static-libgcc -march=native ../libiberty/pic/libiberty.a -Wl,-soname -Wl,liblto_plugin.so.0 -o .libs/liblto_plugin.so.0.0.0 libtool: link: (cd .libs rm -f liblto_plugin.so.0 ln -s liblto_plugin.so.0.0.0 liblto_plugin.so.0) libtool: link: (cd .libs rm -f liblto_plugin.so ln -s liblto_plugin.so.0.0.0 liblto_plugin.so) libtool: link: ( cd .libs rm -f liblto_plugin.la ln -s ../liblto_plugin.la liblto_plugin.la ) ... This leads to stage1 having a working plugin. For stage2 does it change: /bin/bash ./libtool --tag=CC --tag=disable-static --mode=compile /var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/xgcc -B/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/lib/ -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/include -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/../include -DHAVE_CONFIG_H -Wall -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -c -o lto-plugin.lo /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/lto-plugin.c ... This already looks wrong. Although it has removed -static from the options is it actually using those I have given with --with-boot-ldflags=... and it is not using those given with --enable-linker-plugin-flags= It continues with: libtool: compile: /var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/xgcc -B/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/lib/ -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/include -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/../include -DHAVE_CONFIG_H -Wall -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -c /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/lto-plugin.c -fPIC -DPIC -o .libs/lto-plugin.o # (line B) /bin/bash ./libtool --tag=CC --tag=disable-static --mode=link /var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/xgcc -B/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/lib/ -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/include -isystem /home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/sys-include-Wall -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects -Wc,-static-libgcc -module -bindir /home/sven/gcc-lto-plugin/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2 -static -flto=1 -flto-partition=none -fuse-linker-plugin -o liblto_plugin.la -rpath /home/sven/gcc-lto-plugin/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2 lto-plugin.lo -Wc,../libiberty/pic/libiberty.a libtool: link: ar rc .libs/liblto_plugin.a
[Bug c++/62165] New: Misleading error messages when using impossible brace initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62165 Bug ID: 62165 Summary: Misleading error messages when using impossible brace initializer list Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: public at enkore dot de Created attachment 33343 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33343action=edit Demonstrates the issue. When trying to brace-initialize a container or something similar with non-aggregate key or value types the error messages become long and misleading. Since such initialization is not possible the error message should simply point to that and why it is not possible. err_neg.cc generates a pile of error messages unrelated to the error cause — in this example the issue is simply that struct s is not an aggregate since it has default values and thus an implicit default ctor. Thus it is not possible to initialize a map with that value typ via brace initialization. A smart compiler should point that out.
[Bug c++/62165] Misleading error messages when using impossible brace initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62165 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-17 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Can you create a testcase without using map or any other #include? https://gcc.gnu.org/bugs/minimize.html
[Bug c++/62165] Misleading error messages when using impossible brace initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62165 --- Comment #2 from marian public at enkore dot de --- Created attachment 33344 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33344action=edit Simpler example Sure, but it doesn't produce the vast amount of error messages as with the map example - still not good, though :)
[Bug c++/62165] Misleading error messages when using impossible brace initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62165 --- Comment #3 from marian public at enkore dot de --- A good error message about this would probably be something like cannot brace-initialize `xyz` because `some type` is not an aggregate
[Bug c++/62165] Misleading error messages when using impossible brace initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62165 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Yes, I agree the error is not very clear. It would be even more helpful if it said why type is not an aggregate (in this case, because there is an equal initializer for a non-static member).
[Bug c++/61721] GCC 4.8-4.10 miscompiles webkit hashing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61721 Lauri Kasanen cand at gmx dot com changed: What|Removed |Added Known to fail|4.10.0 |5.0 --- Comment #7 from Lauri Kasanen cand at gmx dot com --- Latest trunk (214073) is still broken. Using latest trunk, I tried all optimization sub-options in O2 to find the smallest hammer that fixes it. -O2 -fno-thread-jumps: crash -O2 -fno-align-functions: crash ... -O2 -fno-use-caller-save: crash The only combos that worked: -O2 -fno-inline-small-functions: works -O2 -fno-strict-aliasing: works Moving to -O1 with those: -O1 -finline-small-functions: works -O1 -fstrict-aliasing: works -O1 -fstrict-aliasing -finline-small-functions: crash This does point to the code being wrong somehow, but in that case, -Wall -Wextra should say something, and this would be a missing warning bug in gcc.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #50 from Sven C. Dack sven.c.dack at virginmedia dot com --- The additional configuration options --enable-linker-plugin-configure-flags= and --enable-linker-plugin-flags=, which I have trusted in and taken from https://gcc.gnu.org/install/configure.html do not seem to exist in 4.9, but only exist with the upcoming 4.10. Someone has been fast with the web updates and now one cannot trust them for building a stable compiler *sigh*. Anyhow, it explains why I cannot bootstrap a statically linked compiler with lto and linker plugin. Will this be taken care of for 4.9.2? And can I leave this here or shall I make a new report for it?
[Bug tree-optimization/62071] [4.10 Regression] ICE: in before_dom_children, at tree-ssa-pre.c:4411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62071 --- Comment #9 from Jan Hubicka hubicka at ucw dot cz --- The constructor is keyed to other compilation unit here, but we are provided with a body that we will never use (modulo the tree-ssa-pre bug that brings the reference into code). Hmm, we might consider overriding DECL_EXTERNAL so that there's a definition available for devirtualization. I can always implement logic to use it only when it is inlined, but that will probably drag in references to other symbols belonging to the class... I'm not too concerned about that; users should expect an inline function to be inlined. Thiking about this - can't we make these just DECL_COMDAT? If it is safe to inline them, it is also safe to introduce COMDAT copy of the body if we introduce the reference to it. Becaue the method is keyed, it will be overriden by non-weak in the case user links with the implementation. If he doesn't then the weak copy is no worse (reference wise) than inline copy... Honza
[Bug c/62059] signed integer overflow in diagnostic.c adjust_line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62059 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Sun Aug 17 16:19:43 2014 New Revision: 214074 URL: https://gcc.gnu.org/viewcvs?rev=214074root=gccview=rev Log: PR c/62059 * diagnostic.c (adjust_line): Add gcc_checking_assert. (diagnostic_show_locus): Don't print caret diagnostic if a column is larger than the line_width. Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic.c
[Bug c/62059] signed integer overflow in diagnostic.c adjust_line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62059 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug libstdc++/41495] libstdc++ --enable-clocale=ieee_1003.1-2001 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41495 Václav Zeman vhaisman at gmail dot com changed: What|Removed |Added CC||vhaisman at gmail dot com --- Comment #11 from Václav Zeman vhaisman at gmail dot com --- I have started working on this but I have never finished. If anybody is interested, the work is available at https://github.com/wilx/gcc/compare/gcc-mirror:master...posix-2008-locale. The branch is a bit misnamed because I had to use some Darwin extensions instead of only POSIX 2008 functions.
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
--- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
I'm trying to find out what is going on.
Here is a part of RTL dump for the test case before reload:
(insn 6 5 9 2 (set (reg:DI 160 [ D.1463 ])
(mem/c:DI (plus:DI (reg/f:DI 166)
(const_int 8 [0x8])) [2 empty_zero_page+8 S8 A64])) xxx.c:15
282 {*movdi_media_nofpu}
(expr_list:REG_EQUIV (mem/c:DI (plus:DI (reg/f:DI 166)
(const_int 8 [0x8])) [2 empty_zero_page+8 S8 A64])
(nil)))
(insn 9 6 28 2 (set (reg:SI 169 [ D.1464 ])
(zero_extend:SI (truncate:HI (reg:DI 160 [ D.1463 ] xxx.c:15 226
{*zero_extendhisi2_media}
(nil))
and reload combines these two insns into the insn
(insn 9 6 28 2 (set (reg:SI 2 r2 [orig:169 D.1464 ] [169])
(zero_extend:SI (truncate:HI (mem/c:DI (plus:DI (reg/f:DI 10 r10 [166])
(const_int 8 [0x8])) [2 empty_zero_page+8 S8 A64]
xxx.c:15 226 {*zero_extendhisi2_media}
(nil))
which results this ICE. It looks that reload recognizes the last
insn is a valid *zero_extendhisi2_media insn:
(define_insn *zero_extendhisi2_media
[(set (match_operand:SI 0 register_operand =r,r)
(zero_extend:SI (match_operand:HI 1 general_extend_operand r,m)))]
...
even though general_extend_operand doesn't permit (truncate (mem ...)).
An easy workaround might be to disable truncate in general_extend_operand
before reload.
--- gcc/config/sh/predicates.md.orig2014-08-02 11:55:29.228875715 +0900
+++ gcc/config/sh/predicates.md2014-08-17 08:30:20.439326569 +0900
@@ -398,7 +398,7 @@
(define_predicate general_extend_operand
(match_code subreg,reg,mem,truncate)
{
- if (GET_CODE (op) == TRUNCATE)
+ if (reload_completed GET_CODE (op) == TRUNCATE)
return arith_operand (op, mode);
if (MEM_P (op) || (GET_CODE (op) == SUBREG MEM_P (SUBREG_REG (op
[Bug target/62166] New: Poor code generation (x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62166
Bug ID: 62166
Summary: Poor code generation (x86-64)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at consulting dot net.nz
$ gcc-snapshot.sh --version
gcc (Debian 20140814-1) 4.10.0 20140814 (experimental) [trunk revision 213954]
weird_code_gen.c:
#include stdint.h
typedef void (*f_t)(uint64_t rdi, uint64_t rsi, uint64_t rdx, uint64_t rcx);
void weird_code_gen(uint64_t rdi, uint64_t rsi, uint64_t rdx, uint64_t rcx);
f_t dispatch[] = {weird_code_gen};
void weird_code_gen(uint64_t rdi, uint64_t rsi, uint64_t rdx, uint64_t rcx) {
int64_t s8 = (int8_t) rcx;
uint32_t u8 = (uint8_t) (rcx 8);
//asm volatile ( : +r (rcx));
rdx += s8;
rcx = 16;
dispatch[u8](rdi, rsi, rdx, rcx);
}
int main(void) {
return 0;
}
$ gcc-snapshot.sh -O3 weird_code_gen.c objdump -d -m i386:x86-64:intel a.out
|less
004004c0 weird_code_gen:
4004c0: 48 89 c8movrax,rcx
4004c3: 53 push rbx
4004c4: 0f b6 ddmovzx ebx,ch
4004c7: 48 0f be c0 movsx rax,al
4004cb: 48 c1 e9 10 shrrcx,0x10
4004cf: 48 01 c2addrdx,rax
4004d2: 48 8b 04 dd d8 08 60movrax,QWORD PTR [rbx*8+0x6008d8]
4004d9: 00
4004da: 5b poprbx
4004db: ff e0 jmprax
Code generation with asm volatile uncommented:
004004c0 weird_code_gen:
4004c0: 4c 0f be c1 movsx r8,cl
4004c4: 0f b6 c5movzx eax,ch
4004c7: 89 c0 moveax,eax
4004c9: 48 c1 e9 10 shrrcx,0x10
4004cd: 4c 01 c2addrdx,r8
4004d0: ff 24 c5 d0 08 60 00jmpQWORD PTR [rax*8+0x6008d0]
The asm volatile workaround fails if u8 is of type uint64_t.
