[Bug bootstrap/84450] bootstrap-lto ICE in g-dyntab.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84450 --- Comment #1 from Steven Noonan --- Sorry for the comment spam, but... I think DMARC/DKIM caused the notification for this bug to drop on the floor, as I saw a DMARC report for my domain saying 65 messages on *@gnu.org were rejected because they didn't originate from my domain's mailservers and didn't have the right DKIM signature. I've changed my domain's DMARC policy to "none" so hopefully messages forged by Bugzilla don't drop anymore, until I can figure out a better policy. Adding this comment to make sure this issue gets seen at least once on the mailing list.
[Bug bootstrap/84450] New: bootstrap-lto ICE in g-dyntab.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84450 Bug ID: 84450 Summary: bootstrap-lto ICE in g-dyntab.adb Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: steven at uplinklabs dot net Target Milestone: --- This bug has been around for at least a few GCC versions now, but I hadn't gotten around to reporting it. My configure flags: --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu \ --prefix=/usr \ --libdir=/usr/lib \ --libexecdir=/usr/lib \ --mandir=/usr/share/man \ --infodir=/usr/share/info \ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ \ --with-build-config=bootstrap-lto \ --disable-libssp \ --disable-libstdcxx-pch \ --disable-libunwind-exceptions \ --disable-werror \ --enable-__cxa_atexit \ --enable-checking=release \ --enable-clocale=gnu \ --enable-gnu-indirect-function \ --enable-gnu-unique-object \ --enable-initfini-array \ --enable-install-libiberty \ --enable-libmpx \ --enable-linker-build-id \ --enable-lto \ --enable-multilib \ --enable-plugin \ --enable-shared \ --enable-threads=posix \ --with-isl \ --with-linker-hash-style=gnu \ --with-multilib-list=m32,m64,mx32 \ --with-system-zlib Non-bootstrap-lto builds work fine, but if I -do- try a bootstrap-lto build, I get this: /build/gcc-multilib/src/gcc/gcc/ada/g-dyntab.adb: In function ‘prep__symbol_table__free’: /build/gcc-multilib/src/gcc/gcc/ada/g-dyntab.adb:140:9: internal compiler error: in gen_typedef_die, at dwarf2out.c:24370 end Free; ^ 0x8b8125 gen_typedef_die /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24370 0x8ba02b gen_decl_die /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25390 0x8b866b gen_type_die_with_usage /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24547 0x8b8de2 gen_type_die /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24758 0x8ba0aa gen_decl_die /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25410 0x8b9204 process_scope_var /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24903 0x8b9262 decls_for_scope /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24928 0x8b3d1a gen_subprogram_die /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:22465 0x8b9f58 gen_decl_die /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25364 0x8badaa dwarf2out_decl /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25879 0x8bae09 dwarf2out_function_decl /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25894 0x939efe rest_of_handle_final /build/gcc-multilib/src/gcc/gcc/final.c:4520 0x93a06c execute /build/gcc-multilib/src/gcc/gcc/final.c:4562 This is built from gcc-7-branch@257786. Any more details I can provide?
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
--- Comment #14 from Steven Noonan ---
"testcase.i" can be reduced a lot (thanks creduce!). Literally just this:
---
__attribute__((target_clones("arch=sandybridge", "default"))) static _saxpy() {
#pragma omp parallel
;
}
saxpy() {}
---
is sufficient to demonstrate the link issue (compile with/without -fopemp)
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808 Steven Noonan changed: What|Removed |Added Attachment #42417|0 |1 is obsolete|| --- Comment #13 from Steven Noonan --- Created attachment 42419 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42419=edit testcase.i - full saxpy test preprocessed attempt #2 for the link issue. preprocessed with stdlib.h included. Flags are as simple as: $ gcc -o test testcase.i $ gcc -fopenmp -o test testcase.i The former links fine, the latter doesn't
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808 --- Comment #12 from Steven Noonan --- Created attachment 42418 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42418=edit nbody_CPU_AOS compile error testcase preprocessed source Compile error case, preprocessed source. Compile with: $ gcc -O3 -march=native -ffast-math -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE -DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11 -I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement -Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes -Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings -Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread -fopenmp -MMD -c -o nbody_CPU_AOS.o nbody_CPU_AOS-compile-error.i
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808 Steven Noonan changed: What|Removed |Added Attachment #40333|0 |1 is obsolete|| Attachment #40334|0 |1 is obsolete|| Attachment #40335|0 |1 is obsolete|| --- Comment #11 from Steven Noonan --- Created attachment 42417 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42417=edit testcase.c - full saxpy test program for target_clones new testcase.c for undefined symbols with target_clones + opemp The preprocessed source for this is basically not different from the .c at all. I'll provide preprocessed source for the compile error case though, which will be a different testcase.
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808 --- Comment #9 from Steven Noonan --- Actually, I lied. It's not quite working. It's obviously close though. The following examples of the issue are using my n-body implementation: https://github.com/tycho/nbody Each of the variants of n-body have a bunch of link issues: $ make CFOPTIMIZE="-O3 -march=core2" [...] nbody_CPU_SOA.o: In function `_ComputeGravitation_SOA.default.8': nbody_CPU_SOA.c:(.text+0x1e): undefined reference to `_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc' nbody_CPU_SOA.o: In function `_ComputeGravitation_SOA.arch_skylake.4': nbody_CPU_SOA.c:(.text+0x59b): undefined reference to `_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc' nbody_CPU_SOA.o: In function `_ComputeGravitation_SOA.arch_haswell.5': nbody_CPU_SOA.c:(.text+0x63b): undefined reference to `_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc' nbody_CPU_SOA.o: In function `_ComputeGravitation_SOA.arch_sandybridge.6': nbody_CPU_SOA.c:(.text+0x6db): undefined reference to `_ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc' [...] Symbols in nbody_CPU_SOA.o: $ nm src/nbody_CPU_SOA.o 00a0 t bodyBodyInteraction 0c00 T ComputeGravitation_SOA 0610 t _ComputeGravitation_SOA.arch_haswell.5 06b0 t _ComputeGravitation_SOA.arch_sandybridge.6 0570 t _ComputeGravitation_SOA.arch_skylake.4 t _ComputeGravitation_SOA.default.8 0bb0 i _ComputeGravitation_SOA._GLOBAL___ComputeGravitation_SOA.ifunc 0290 t _ComputeGravitation_SOA._omp_fn.0.arch_haswell.2 0400 t _ComputeGravitation_SOA._omp_fn.0.arch_sandybridge.3 0120 t _ComputeGravitation_SOA._omp_fn.0.arch_skylake.1 0750 t _ComputeGravitation_SOA._omp_fn.0.default.7 U _ComputeGravitation_SOA._omp_fn.0._GLOBAL___ComputeGravitation_SOA.ifunc 0b60 t _ComputeGravitation_SOA._omp_fn.0.resolver 0bb0 t _ComputeGravitation_SOA.resolver U __cpu_indicator_init U __cpu_model U GOMP_loop_end_nowait U GOMP_loop_ull_guided_next U GOMP_loop_ull_guided_start U GOMP_parallel r .LC0 0004 r .LC1 0008 r .LC2 r .LC4 0010 r .LC5 U libtime_cpu_to_wall There's a second issue as well. If I tell it to build with -march=native, I get compile errors: $ make CFOPTIMIZE="-O3 -march=native" V=1 make -C libc11 libc11.a make -C libtime libtime.a make -C src nbody gcc -O3 -march=native -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE -DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11 -I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement -Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes -Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings -Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread -fopenmp -MMD -c -o nbody_CPU_AOS.o nbody_CPU_AOS.c gcc -O3 -march=native -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE -DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11 -I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement -Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes -Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings -Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread -fopenmp -MMD -c -o nbody_CPU_AOS_tiled.o nbody_CPU_AOS_tiled.c gcc -O3 -march=native -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE -DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11 -I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement -Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes -Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings -Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread -fopenmp -MMD -c -o nbody_CPU_SOA.o nbody_CPU_SOA.c gcc -O3 -march=native -std=gnu11 -fno-strict-aliasing -D_GNU_SOURCE -DLIBTIME_STATIC -DUSE_OPENMP -DHAVE_SIMD -DNO_CUDA -DUSE_LIBC11 -I../libc11/include -I../libtime/include -Wall -Wdeclaration-after-statement -Werror=implicit -Werror=undef -Wmissing-declarations -Wmissing-prototypes -Wno-declaration-after-statement -Wno-long-long -Wno-overlength-strings -Wno-unknown-pragmas -Wold-style-definition -Wstrict-prototypes -pthread -fopenmp -MMD -c -o nbody_CPU_SOA_tiled.o nbody_CPU_SOA_tiled.c In file included from nbody_CPU_AOS.c:42:0: nbody_CPU_AOS.c: In function ‘_ComputeGravitation_AOS.arch_skylake.4’: nbody_util.h:114:21: error: SSE register return with SSE disabled static DECLARE_AOS(_ ## Name) ^ nbody_util.h:96:2: note: in definition of macro ‘DECLARE_AOS’ Name( \ ^~~~ nbody_CPU_AOS.c:47:1:
[Bug go/80914] gcc-go binaries don't run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914 --- Comment #12 from Steven Noonan --- Oh this is kind of interesting. It runs fine at '-O1 -ggdb3' $ go.gcc test -o testbin -gccgoflags '-O1 -ggdb3 -Wl,--compress-debug-sections=zlib' OK: 136 passed PASS ok github.com/twstrike/ed448 0.289s And at '-O0 -g0': $ go.gcc test -o testbin1 -gccgoflags '-O0 -g0 -Wl,--compress-debug-sections=zlib' OK: 136 passed PASS ok github.com/twstrike/ed448 0.496s But not at '-O0 -ggdb3': $ go.gcc test -o testbin -gccgoflags '-O0 -ggdb3 -Wl,--compress-debug-sections=zlib' fatal error: ranges offset out of range goroutine 1 [running, locked to thread]: fatal error: ranges offset out of range panic during panic goroutine 1 [running, locked to thread]: fatal error: ranges offset out of range stack trace unavailable exit status 4 FAILgithub.com/twstrike/ed448 0.054s
[Bug go/80914] gcc-go binaries don't run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914 --- Comment #11 from Steven Noonan --- Weird, I wonder why you can't repro it. I built with this to get a stack trace (I assume -O and -ggdb work properly when placed here): $ go.gcc test -o testbin -gccgoflags '-O0 -ggdb3 -Wl,--compress-debug-sections=zlib' Added a breakpoint on exit() and this was the call stack: (gdb) bt #0 0x75a3d4a0 in exit () from /usr/lib/libc.so.6 #1 0x77272217 in runtime.startpanic () at /build/gcc-multilib-trunk/src/gcc/libgo/go/runtime/panic.go:859 #2 0x77261785 in runtime.throw (s=...) at /build/gcc-multilib-trunk/src/gcc/libgo/go/runtime/panic.go:806 #3 0x76df4181 in runtime_throw (s=s@entry=0x7750cae1 "ranges offset out of range") at /build/gcc-multilib-trunk/src/gcc/libgo/runtime/panic.c:13 #4 0x76df1cf3 in error_callback (data=data@entry=0x755cca30, msg=msg@entry=0x7750cae1 "ranges offset out of range", errnum=errnum@entry=0) at /build/gcc-multilib-trunk/src/gcc/libgo/runtime/go-callers.c:154 #5 0x77384a98 in add_unit_ranges (addrs=0x755cbf40, data=0x755cca30, error_callback=0x76df1cc0 , dwarf_ranges_size=0, dwarf_ranges=0x0, is_bigendian=0, base=0, ranges=640, u=0x77f7a920, base_address=0, state=0x77f9d000) at /build/gcc-multilib-trunk/src/gcc/libbacktrace/dwarf.c:1195 #6 find_address_ranges (state=state@entry=0x77f9d000, base_address=base_address@entry=0, unit_buf=unit_buf@entry=0x755cbfa0, dwarf_str=dwarf_str@entry=0x77f6 "uint16", dwarf_str_size=dwarf_str_size@entry=87720, dwarf_ranges=dwarf_ranges@entry=0x0, dwarf_ranges_size=0, is_bigendian=0, error_callback=0x76df1cc0 , data=0x755cca30, u=0x77f7a920, addrs=0x755cbf40) at /build/gcc-multilib-trunk/src/gcc/libbacktrace/dwarf.c:1356 #7 0x77387355 in build_address_map (addrs=0x755cbf40, data=0x755cca30, error_callback=0x76df1cc0 , is_bigendian=0, dwarf_str_size=87720, dwarf_str=0x77f6 "uint16", dwarf_ranges_size=0, dwarf_ranges=0x0, dwarf_abbrev_size=4564, dwarf_abbrev=0x77f76000 "\001\021\001%\016\023\v\003\016\033\016\021\001\022\a\020\027", dwarf_info_size=152763, dwarf_info=0x7451b000 "\361\026", base_address=0, state=0x77f9d000) at /build/gcc-multilib-trunk/src/gcc/libbacktrace/dwarf.c:1498 #8 build_dwarf_data (data=0x755cca30, error_callback=0x76df1cc0 , is_bigendian=0, dwarf_str_size=87720, dwarf_str=0x77f6 "uint16", dwarf_ranges_size=0, dwarf_ranges=0x0, dwarf_abbrev_size=4564, dwarf_abbrev=0x77f76000 "\001\021\001%\016\023\v\003\016\033\016\021\001\022\a\020\027", dwarf_line_size=0, dwarf_line=0x0, dwarf_info_size=152763, dwarf_info=0x7451b000 "\361\026", base_address=0, state=0x77f9d000) at /build/gcc-multilib-trunk/src/gcc/libbacktrace/dwarf.c:2935 #9 backtrace_dwarf_add (state=state@entry=0x77f9d000, base_address=base_address@entry=0, dwarf_info=0x7451b000 "\361\026", dwarf_info_size=152763, dwarf_line=0x0, dwarf_line_size=0, dwarf_abbrev=0x77f76000 "\001\021\001%\016\023\v\003\016\033\016\021\001\022\a\020\027", dwarf_abbrev_size=4564, dwarf_ranges=0x0, dwarf_ranges_size=0, dwarf_str=0x77f6 "uint16", dwarf_str_size=87720, is_bigendian=0, error_callback=0x76df1cc0 , data=0x755cca30, fileline_fn=0x755cc598) at /build/gcc-multilib-trunk/src/gcc/libbacktrace/dwarf.c:2995 #10 0x7738ab49 in elf_add () at /build/gcc-multilib-trunk/src/gcc/libbacktrace/elf.c:3027 #11 0x7738aff2 in backtrace_initialize (state=state@entry=0x77f9d000, filename=filename@entry=0x7fffce44 "/home/steven/Development/gocode/src/github.com/twstrike/ed448/testbin", descriptor=3, error_callback=error_callback@entry=0x76df1cc0 , data=data@entry=0x755cca30, fileline_fn=fileline_fn@entry=0x755cc648) at /build/gcc-multilib-trunk/src/gcc/libbacktrace/elf.c:3152 #12 0x773878d7 in fileline_initialize (state=state@entry=0x77f9d000, error_callback=error_callback@entry=0x76df1cc0 , data=data@entry=0x755cca30) at /build/gcc-multilib-trunk/src/gcc/libbacktrace/fileline.c:143 #13 0x77387a02 in backtrace_pcinfo (state=0x77f9d000, pc=140737335205254, callback=0x76df1a40 , error_callback=0x76df1cc0 , data=0x755cca30) at /build/gcc-multilib-trunk/src/gcc/libbacktrace/fileline.c:177 #14 0x77387fb7 in unwind (context=, vdata=0x755cc9e0) at /build/gcc-multilib-trunk/src/gcc/libbacktrace/backtrace.c:91 #15 0x75dcd349 in _Unwind_Backtrace (trace=trace@entry=0x77387f10 , trace_argument=trace_argument@entry=0x755cc9e0) at /build/gcc-multilib-trunk/src/gcc/libgcc/unwind.inc:295 #16 0x7738804c in backtrace_full (state=0x77f9d000, skip=skip@entry=0, callback=callback@entry=0x76df1a40 , error_callback=error_callback@entry=0x76df1cc0 , data=data@entry=0x755cca30) at /build/gcc-multilib-trunk/src/gcc/libbacktrace/backtrace.c:127 #17 0x76df1d87 in
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808 --- Comment #8 from Steven Noonan --- Oh, awesome! I just tested a gcc trunk build and it's definitely working there.
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808 Steven Noonan changed: What|Removed |Added Version|6.2.0 |7.2.1 --- Comment #6 from Steven Noonan --- Any chance this work will be picked up sometime soon? It's been waiting quite a while. I'm bumping the GCC version on this report since it still affects the current 7.x branch.
[Bug go/80914] gcc-go binaries don't run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914 --- Comment #9 from Steven Noonan --- (In reply to Ian Lance Taylor from comment #8) > Which version of GCC are you using in comment #7? Oops, forgot to mention that bit. Built from trunk a few hours ago: $ go.gcc version go version go1.9 gccgo (GCC) 8.0.0 20171010 (experimental) linux/amd64
[Bug tree-optimization/65337] [5 regression] LTO bootstrap failure with Ada enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337 --- Comment #18 from Steven Noonan --- I'm still seeing an Ada-related failure when using --with-build-config=bootstrap-lto on the current gcc-7-branch (r253607). /build/gcc-multilib/src/gcc/gcc/ada/g-dyntab.adb: In function ‘prep__symbol_table__free’: /build/gcc-multilib/src/gcc/gcc/ada/g-dyntab.adb:140:9: internal compiler error: in gen_typedef_die, at dwarf2out.c:24370 end Free; ^ 0x8b8067 gen_typedef_die /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24370 0x8b9f6d gen_decl_die /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25390 0x8b85ad gen_type_die_with_usage /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24547 0x8b8d24 gen_type_die /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24758 0x8b9fec gen_decl_die /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25410 0x8b9146 process_scope_var /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24903 0x8b91a4 decls_for_scope /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:24928 0x8b3c5c gen_subprogram_die /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:22465 0x8b9e9a gen_decl_die /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25364 0x8bacd2 dwarf2out_decl /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25873 0x8bad31 dwarf2out_function_decl /build/gcc-multilib/src/gcc/gcc/dwarf2out.c:25888 0x939924 rest_of_handle_final /build/gcc-multilib/src/gcc/gcc/final.c:4520 0x939a92 execute /build/gcc-multilib/src/gcc/gcc/final.c:4562 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
[Bug go/80914] gcc-go binaries don't run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914 --- Comment #7 from Steven Noonan --- With the compressed debug section support added to libbacktrace, gccgo will run fine when built using a binutils configured with --enable-compressed-debug-sections=all. However, programs built with that gccgo + binutils will crash: (Using the github.com/twstrike/ed448 go package as an example) $ go.gcc test -gccgoflags -Wl,--compress-debug-sections=none OK: 136 passed PASS ok github.com/twstrike/ed448 0.366s $ go.gcc test -gccgoflags -Wl,--compress-debug-sections=zlib fatal error: ranges offset out of range runtime stack: fatal error: ranges offset out of range panic during panic runtime stack: fatal error: ranges offset out of range stack trace unavailable exit status 4 FAILgithub.com/twstrike/ed448 0.051s
[Bug go/80914] gcc-go binaries don't run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914 --- Comment #4 from Steven Noonan --- This bug is still present, but I believe I know what is causing this. At the time I reported this, I was using a binutils configured with --enable-compressed-debug-sections=all. The resulting go.gcc binary just crashed when run. If I build GCC using a binutils configured with --enable-compressed-debug-sections=none instead, then the resulting go.gcc runs fine: $ go.gcc version go version go1.8.3 gccgo (GCC) 7.2.1 20171005 linux/amd64 I see that libbacktrace was made to support compressed debug sections in trunk only very recently: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67165 So while it's likely unreasonable to ask that this be ported over into 7.2.x, could some work be done to make libbacktrace fail more gracefully if GCC is built without compressed debug section support enabled?
[Bug sanitizer/82379] [7/8 Regression] internal_sigreturn not defined in libasan.so or libubsan.so with -mx32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82379 --- Comment #6 from Steven Noonan --- Seems to resolve the link issue. Not sure how to test that internal_sigreturn does what it should, though.
[Bug sanitizer/82379] [7/8 Regression] internal_sigreturn not defined in libasan.so or libubsan.so with -mx32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82379
--- Comment #5 from Steven Noonan ---
(In reply to H.J. Lu from comment #4)
> (In reply to Steven Noonan from comment #3)
> > Are you sure that patch is sufficient? __x86_64__ is defined on both the
> > normal x86_64 ABI and on the x32 ABI. The combination most often used to
> > identify x32 is 'defined(__x86_64__) && defined(__ILP32__)'
> >
> > I've currently got this patch applied locally which allows me to build
> > against the x32 ABI with -fsanitize=foo:
> >
> > diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.cc
> > b/libsanitizer/sanitizer_common/sanitizer_linux.cc
> > index 5b6f18602e7..a11592614a4 100644
> > --- a/libsanitizer/sanitizer_common/sanitizer_linux.cc
> > +++ b/libsanitizer/sanitizer_common/sanitizer_linux.cc
> > @@ -674,7 +674,7 @@ int internal_sigaction_syscall(int signum, const void
> > *act, void *oldact) {
> > return internal_sigaction_norestorer(signum, act, oldact);
> >__sanitizer_sigaction u_adjust;
> >internal_memcpy(_adjust, act, sizeof(u_adjust));
> > -#if !SANITIZER_ANDROID || !SANITIZER_MIPS32
> > +#if (!SANITIZER_ANDROID || !SANITIZER_MIPS32) && !defined(__ILP32__)
> > if (u_adjust.sa_restorer == nullptr) {
> >u_adjust.sa_restorer = internal_sigreturn;
> > }
>
> I don't believe this is correct.
If you mean the patch itself, then I agree. It was just what happened to
unblock me.
> Please try my patch.
I gave your patch a second look and I see why it'd work now
("x$ac_cv_sizeof_void_p = x8" would be false on x32). I'm building GCC with
your patch now, it'll be a while.
[Bug sanitizer/82379] [7/8 Regression] internal_sigreturn not defined in libasan.so or libubsan.so with -mx32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82379
--- Comment #3 from Steven Noonan ---
Are you sure that patch is sufficient? __x86_64__ is defined on both the normal
x86_64 ABI and on the x32 ABI. The combination most often used to identify x32
is 'defined(__x86_64__) && defined(__ILP32__)'
I've currently got this patch applied locally which allows me to build against
the x32 ABI with -fsanitize=foo:
diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.cc
b/libsanitizer/sanitizer_common/sanitizer_linux.cc
index 5b6f18602e7..a11592614a4 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux.cc
+++ b/libsanitizer/sanitizer_common/sanitizer_linux.cc
@@ -674,7 +674,7 @@ int internal_sigaction_syscall(int signum, const void *act,
void *oldact) {
return internal_sigaction_norestorer(signum, act, oldact);
__sanitizer_sigaction u_adjust;
internal_memcpy(_adjust, act, sizeof(u_adjust));
-#if !SANITIZER_ANDROID || !SANITIZER_MIPS32
+#if (!SANITIZER_ANDROID || !SANITIZER_MIPS32) && !defined(__ILP32__)
if (u_adjust.sa_restorer == nullptr) {
u_adjust.sa_restorer = internal_sigreturn;
}
[Bug sanitizer/82379] New: internal_sigreturn not defined in libasan.so or libubsan.so with -mx32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82379
Bug ID: 82379
Summary: internal_sigreturn not defined in libasan.so or
libubsan.so with -mx32
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
The symbol "internal_sigreturn" isn't defined when building for the x32 ABI on
x86_64:
$ cat test.c
int main(){ return 0; }
$ gcc -mx32 -fsanitize=address -o test test.c
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../libx32/libasan.so: undefined
reference to `internal_sigreturn'
collect2: error: ld returned 1 exit status
$ gcc -mx32 -fsanitize=undefined -o test test.c
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/../../../../libx32/libubsan.so:
undefined reference to `internal_sigreturn'
collect2: error: ld returned 1 exit status
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/src/gcc/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://www.uplinklabs.net/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --disable-libssp
--disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror
--enable-__cxa_atexit --enable-checking=release --enable-clocale=gnu
--enable-gnu-indirect-function --enable-gnu-unique-object
--enable-initfini-array --enable-install-libiberty --enable-libmpx
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --with-isl --with-linker-hash-style=gnu
--with-multilib-list=m32,m64,mx32 --with-system-zlib
Thread model: posix
gcc version 7.2.1 20170929 (GCC)
My GCC was built from latest in gcc-7-branch yesterday.
Defining something like this in my application does technically work, but
really shouldn't be necessary:
void (*internal_sigreturn)(void) = 0;
[Bug go/80914] gcc-go binaries don't run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914 --- Comment #3 from Steven Noonan --- This is from a different go.gcc binary, because I've rebuilt several times to try and troubleshoot. But this one still exhibits the bad behavior. Just in case, I've uploaded a copy of the binary, the entire 'readelf --debug=info' output, and the current gdb output: https://www.uplinklabs.net/files/gcc-pr80914/gcc-go-debug-info.txt https://www.uplinklabs.net/files/gcc-pr80914/gdb.txt https://www.uplinklabs.net/files/gcc-pr80914/go.gcc.gz Here's 'tail -n 30' of the gcc-go-debug-info.txt from above: <2338a> DW_AT_location: 2 byte block: 91 60 (DW_OP_fbreg: -32) <2><2338d>: Abbrev Number: 0 <1><2338e>: Abbrev Number: 7 (DW_TAG_pointer_type) <2338f> DW_AT_byte_size : 8 <23390> DW_AT_type: <0x22f27> <1><23394>: Abbrev Number: 43 (DW_TAG_subprogram) <23395> DW_AT_name: (indirect string, offset: 0x32231): base_of_encoded_value <23399> DW_AT_decl_file : 1 <2339a> DW_AT_decl_line : 101 <2339b> DW_AT_prototyped : 1 <2339b> DW_AT_type: <0x22e30> <2339f> DW_AT_low_pc : 0x4bc54a <233a7> DW_AT_high_pc : 0x83 <233af> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <233b1> DW_AT_GNU_all_tail_call_sites: 1 <2><233b1>: Abbrev Number: 28 (DW_TAG_formal_parameter) <233b2> DW_AT_name: (indirect string, offset: 0x3216f): encoding <233b6> DW_AT_decl_file : 1 <233b7> DW_AT_decl_line : 101 <233b8> DW_AT_type: <0x22a32> <233bc> DW_AT_location: 2 byte block: 91 6c (DW_OP_fbreg: -20) <2><233bf>: Abbrev Number: 28 (DW_TAG_formal_parameter) <233c0> DW_AT_name: (indirect string, offset: 0x21373): context <233c4> DW_AT_decl_file : 1 <233c5> DW_AT_decl_line : 101 <233c6> DW_AT_type: <0x22f10> <233ca> DW_AT_location: 2 byte block: 91 60 (DW_OP_fbreg: -32) <2><233cd>: Abbrev Number: 0 <1><233ce>: Abbrev Number: 0
[Bug go/80914] gcc-go binaries don't run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
--- Comment #1 from Steven Noonan ---
Possibly better backtrace from an -O0 -g build of GCC:
Program received signal SIGSEGV, Segmentation fault.
0x7731307e in __generic_morestack (pframe_size=0x77fa3050,
old_stack=0x77fa3070, param_size=0) at
/build/gcc-multilib/src/gcc/libgcc/generic-morestack.c:573
573 /build/gcc-multilib/src/gcc/libgcc/generic-morestack.c: No such file or
directory.
(gdb) bt full
#0 0x7731307e in __generic_morestack (pframe_size=0x77fa3050,
old_stack=0x77fa3070, param_size=0) at
/build/gcc-multilib/src/gcc/libgcc/generic-morestack.c:573
frame_size = 1576
current = 0x77313ef3 <__morestack+47>
pp = 0x77fa3008
dynamic = 0x0
from = 0xa3c13bd723171300
to = 0x0
ret = 0x0
i = 4
aligned = 0
#1 0x77313ef3 in __morestack () at
/build/gcc-multilib/src/gcc/libgcc/config/i386/morestack.S:510
No locals.
#2 0x772fb590 in dwarf_buf_error (buf=0x77fa32b0,
msg=0x774b71ef "DWARF underflow") at
/build/gcc-multilib/src/gcc/libbacktrace/dwarf.c:380
b = "DWARF underflow in .debug_info at 4", '\000'
#3 0x772fb5ea in require (buf=0x77fa32b0, count=2) at
/build/gcc-multilib/src/gcc/libbacktrace/dwarf.c:394
No locals.
#4 0x772fb61f in advance (buf=0x77fa32b0, count=2) at
/build/gcc-multilib/src/gcc/libbacktrace/dwarf.c:407
No locals.
#5 0x772fb708 in read_uint16 (buf=0x77fa32b0) at
/build/gcc-multilib/src/gcc/libbacktrace/dwarf.c:445
p = 0x77e386cb ""
#6 0x772fd8b1 in build_address_map (state=0x77fa7000,
base_address=0, dwarf_info=0x77e386c7 "\001", dwarf_info_size=70042,
dwarf_abbrev=0x77e49861 "\001", dwarf_abbrev_size=1206,
dwarf_ranges=0x77e6770a "\001", dwarf_ranges_size=458,
dwarf_str=0x77e5155a "\001", dwarf_str_size=90544, is_bigendian=0,
error_callback=0x76e6ec32 , data=0x77fa3cd0,
addrs=0x77fa33d0) at /build/gcc-multilib/src/gcc/libbacktrace/dwarf.c:1461
len = 1
unit_buf = {
name = 0x774b72f7 ".debug_info",
start = 0x77e386c7 "\001",
buf = 0x77e386cb "",
left = 1,
is_bigendian = 0,
error_callback = 0x76e6ec32 ,
data = 0x77fa3cd0,
reported_underflow = 0
}
addrsize = 32767
u = 0x77e78c08
unit_data_start = 0x77e386c7 "\001"
is_dwarf64 = 0
version = -147843478
abbrev_offset = 0
info = {
name = 0x774b72f7 ".debug_info",
start = 0x77e386c7 "\001",
buf = 0x77e386cc "",
left = 70037,
is_bigendian = 0,
error_callback = 0x76e6ec32 ,
data = 0x77fa3cd0,
reported_underflow = 0
}
abbrevs = {
num_abbrevs = 0,
abbrevs = 0x0
}
#7 0x77300c75 in build_dwarf_data (state=0x77fa7000,
base_address=0, dwarf_info=0x77e386c7 "\001", dwarf_info_size=70042,
dwarf_line=0x77e49d17 "\001", dwarf_line_size=30787,
dwarf_abbrev=0x77e49861 "\001", dwarf_abbrev_size=1206,
dwarf_ranges=0x77e6770a "\001", dwarf_ranges_size=458,
dwarf_str=0x77e5155a "\001", dwarf_str_size=90544, is_bigendian=0,
error_callback=0x76e6ec32 , data=0x77fa3cd0) at
/build/gcc-multilib/src/gcc/libbacktrace/dwarf.c:2932
addrs_vec = {
vec = {
base = 0x0,
size = 0,
alc = 0
},
count = 0
}
addrs = 0x18
addrs_count = 140737353757712
fdata = 0x773016c7
#8 0x77300e46 in backtrace_dwarf_add (state=0x77fa7000,
base_address=0, dwarf_info=0x77e386c7 "\001", dwarf_info_size=70042,
dwarf_line=0x77e49d17 "\001", dwarf_line_size=30787,
dwarf_abbrev=0x77e49861 "\001", dwarf_abbrev_size=1206,
dwarf_ranges=0x77e6770a "\001", dwarf_ranges_size=458,
dwarf_str=0x77e5155a "\001", dwarf_str_size=90544, is_bigendian=0,
error_callback=0x76e6ec32 , data=0x77fa3cd0,
fileline_fn=0x77fa3810) at
/build/gcc-multilib/src/gcc/libbacktrace/dwarf.c:2992
fdata = 0x77fa3cd0
#9 0x77302d07 in elf_add (state=0x77fa7000, descriptor=-1,
base_address=0, error_callback=0x76e6ec32 ,
data=0x77fa3cd0, fileline_fn=0x77fa3810, found_sym=0x77fa3804,
found_dwarf=0x77fa3808, exe=1) at
/build/gcc-multilib/src/gcc/libbacktrace/elf.c:817
ehdr_view = {
data = 0x77fa1000,
base = 0x77fa1000,
len = 4096
}
ehdr = {
e_ident = "\177ELF\002\001\001\000\000\000\000\000\000\000\000",
e_type = 2,
e_machine = 62,
e_version = 1,
e_entry = 4258992,
e_phoff = 64,
e_shoff = 1621392,
e_flags =
[Bug go/80914] New: gcc-go binaries don't run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914 Bug ID: 80914 Summary: gcc-go binaries don't run Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: steven at uplinklabs dot net CC: cmang at google dot com Target Milestone: --- I can't seem to get gcc-go to work in my builds of GCC, and I don't understand why. Here's my build configuration: $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc-multilib/src/gcc/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://www.uplinklabs.net/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror --enable-__cxa_atexit --enable-checking=release --enable-clocale=gnu --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-libmpx --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --with-isl --with-linker-hash-style=gnu --with-multilib-list=m32,m64,mx32 --with-system-zlib Thread model: posix gcc version 7.1.1 20170529 (GCC) Whenever I run the gcc-provided 'go' binary, I just get this: $ go.gcc fatal error: DWARF underflow in .debug_info at 4 runtime stack: fatal error: DWARF underflow in .debug_info at 4 panic during panic runtime stack: Segmentation fault (core dumped) $ Assuming my GCC build process is doing what it should, the go.gcc binary should have debug info and not be stripped, and 'file' appears to agree that's the case: $ file /usr/bin/go.gcc /usr/bin/go.gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=4467591638a8ccaebbab3384129ec221295ad6a9, not stripped, with debug_info But based on the "DWARF underflow" messages, I guess the debug information in the binary is somehow broken? Here's what GDB has to say about it: $ gdb go.gcc GNU gdb (GDB) 7.12.1 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from go.gcc...done. (gdb) run Starting program: /usr/bin/go.gcc [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". fatal error: DWARF underflow in .debug_info at 4 runtime stack: fatal error: DWARF underflow in .debug_info at 4 panic during panic runtime stack: Program received signal SIGSEGV, Segmentation fault. __generic_morestack (pframe_size=0x77fa3250, old_stack=0x77fa3270, param_size=0) at /build/gcc-multilib/src/gcc/libgcc/generic-morestack.c:573 573 /build/gcc-multilib/src/gcc/libgcc/generic-morestack.c: No such file or directory. (gdb) bt full #0 __generic_morestack (pframe_size=0x77fa3250, old_stack=0x77fa3270, param_size=0) at /build/gcc-multilib/src/gcc/libgcc/generic-morestack.c:573 frame_size = 1544 current = 0x76e80840 pp = 0x77fa3008 dynamic = 0x0 from = to = ret = i = aligned = #1 0x77314581 in __morestack () at /build/gcc-multilib/src/gcc/libgcc/config/i386/morestack.S:510 No locals. #2 0x77306510 in dwarf_buf_error (buf=buf@entry=0x77fa34b0, msg=msg@entry=0x774b777f "DWARF underflow") at /build/gcc-multilib/src/gcc/libbacktrace/dwarf.c:380 b = "DWARF underflow in .debug_info at 4", '\000' #3 0x77306a58 in require (count=, buf=) at /build/gcc-multilib/src/gcc/libbacktrace/dwarf.c:394 No locals. #4 advance (buf=0x77fa34b0, count=) at /build/gcc-multilib/src/gcc/libbacktrace/dwarf.c:407 count = buf = 0x77fa34b0 #5 0x77306b17 in read_uint16 (buf=buf@entry=0x77fa34b0) at /build/gcc-multilib/src/gcc/libbacktrace/dwarf.c:445
[Bug ada/80626] [7/8 Regression] Ada x32 multilib build failure for a-cfinve.ads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80626 --- Comment #5 from Steven Noonan --- (In reply to H.J. Lu from comment #3) > Please try > > diff --git a/gcc/ada/system-linux-x86.ads b/gcc/ada/system-linux-x86.ads > index 22a212e..533d94e 100644 > --- a/gcc/ada/system-linux-x86.ads > +++ b/gcc/ada/system-linux-x86.ads > @@ -70,7 +70,7 @@ package System is > > Storage_Unit : constant := 8; > Word_Size: constant := Standard'Word_Size; > - Memory_Size : constant := 2 ** Word_Size; > + Memory_Size : constant := 2 ** Long_Integer'Size; > > -- Address comparison This seems to build perfectly for --with-multilib=m32,m64,mx32.
[Bug other/80634] strangely missed vectorization optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80634 --- Comment #1 from Steven Noonan --- Created attachment 41323 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41323=edit icc 17.0.1 outputs for ELEMS=1 through ELEMS=32
[Bug other/80634] New: strangely missed vectorization optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80634
Bug ID: 80634
Summary: strangely missed vectorization optimizations
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Target Milestone: ---
Created attachment 41322
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41322=edit
gcc 6.3.1 outputs for ELEMS=1 through ELEMS=32
(Not sure which component is the correct one for this issue).
I've noticed that the vectorizer makes some strange choices occasionally, and
will turn some straightforward code into a large branchy code sequence. Take
this, for example:
void saxpy(float a, float * restrict x, float * restrict y)
{
for (int i = 0; i < ELEMS; ++i)
y[i] = a*x[i] + y[i];
}
If I use the flags "-O3 -march=haswell" (or "-O3 -xAVX2" on ICC) and use
varying definitions of ELEMS, I will sometimes get odd results with GCC 6.3.1.
Here's -DELEMS=6 with GCC 6.3.1:
saxpy:
vshufps $0, %xmm0, %xmm0, %xmm1
vmovups (%rsi), %xmm2
vfmadd132ps (%rdi), %xmm2, %xmm1
vmovss 20(%rsi), %xmm3
vmovups %xmm1, (%rsi)
vmovss 16(%rdi), %xmm1
vfmadd213ss 16(%rsi), %xmm0, %xmm1
vfmadd132ss 20(%rdi), %xmm3, %xmm0
vmovss %xmm1, 16(%rsi)
vmovss %xmm0, 20(%rsi)
ret
Seems reasonable.
Here's -DELEMS=7 with GCC 6.3.1:
saxpy:
movq%rsi, %rax
shrq$2, %rax
negq%rax
andl$3, %eax
je .L7
vmovss (%rdi), %xmm1
vfmadd213ss (%rsi), %xmm0, %xmm1
vmovss %xmm1, (%rsi)
cmpl$1, %eax
je .L8
vmovss 4(%rdi), %xmm1
vfmadd213ss 4(%rsi), %xmm0, %xmm1
vmovss %xmm1, 4(%rsi)
cmpl$3, %eax
jne .L9
vmovss 8(%rdi), %xmm1
vfmadd213ss 8(%rsi), %xmm0, %xmm1
movl$4, %r8d
movl$3, %edx
vmovss %xmm1, 8(%rsi)
.L3:
movl$7, %ecx
movl%eax, %r9d
subl%eax, %ecx
.L2:
leaq(%rsi,%r9,4), %rax
vshufps $0, %xmm0, %xmm0, %xmm1
vmovaps (%rax), %xmm3
vfmadd132ps (%rdi,%r9,4), %xmm3, %xmm1
vmovaps %xmm1, (%rax)
leal4(%rdx), %eax
cmpl$4, %ecx
je .L19
cltq
addl$5, %edx
leaq(%rsi,%rax,4), %rcx
vmovss (%rdi,%rax,4), %xmm1
vfmadd213ss (%rcx), %xmm0, %xmm1
vmovss %xmm1, (%rcx)
cmpl$5, %r8d
je .L17
movslq %edx, %rdx
leaq(%rsi,%rdx,4), %rax
vmovss (%rdi,%rdx,4), %xmm1
vfmadd213ss (%rax), %xmm0, %xmm1
vmovss %xmm1, (%rax)
cmpl$6, %r8d
je .L17
vmovss 24(%rsi), %xmm2
vfmadd132ss 24(%rdi), %xmm2, %xmm0
vmovss %xmm0, 24(%rsi)
ret
.L17:
ret
.L7:
movl$7, %ecx
xorl%r9d, %r9d
movl$7, %r8d
xorl%edx, %edx
jmp .L2
.L19:
ret
.L8:
movl$6, %r8d
movl$1, %edx
jmp .L3
.L9:
movl$5, %r8d
movl$2, %edx
jmp .L3
This might be explained away by it being an odd number just short of a power of
two, but ICC does an apparently better job (one packed FMA plus three single
FMAs):
saxpy:
vbroadcastss %xmm0, %xmm2
vmovups (%rdi), %xmm1
vmovss16(%rdi), %xmm3
vmovss20(%rdi), %xmm4
vmovss24(%rdi), %xmm5
vfmadd213ps (%rsi), %xmm1, %xmm2
vfmadd213ss 16(%rsi), %xmm0, %xmm3
vfmadd213ss 20(%rsi), %xmm0, %xmm4
vfmadd213ss 24(%rsi), %xmm5, %xmm0
vmovups %xmm2, (%rsi)
vmovss%xmm3, 16(%rsi)
vmovss%xmm4, 20(%rsi)
vmovss%xmm0, 24(%rsi)
ret
The results from GCC 6.3.1 for ELEMS values 8 through 14 look fine (short
branchless code sequences similar to what ICC emits), but things go to crap
again for what seems to be *any* value ELEMS=15 or above.
It even misses the opportunity with ELEMS=16 to just do two packed FMAs with
YMM registers:
saxpy:
movq%rsi, %rax
shrq$2, %rax
negq%rax
andl$7, %eax
je .L7
vmovss (%rdi), %xmm1
vfmadd213ss (%rsi), %xmm0, %xmm1
vmovss %xmm1, (%rsi)
cmpl$1, %eax
je .L8
vmovss 4(%rdi), %xmm1
vfmadd213ss 4(%rsi), %xmm0, %xmm1
vmovss %xmm1, 4(%rsi)
cmpl$2, %eax
je .L9
vmovss 8(%rdi), %xmm1
vfmadd213ss 8(%rsi), %xmm0, %xmm1
vmovss %xmm1, 8(%rsi)
cmpl$3, %eax
je .L10
vmovss 12(%rdi),
[Bug ada/80626] Ada x32 multilib build failure for a-cfinve.ads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80626 --- Comment #2 from Steven Noonan --- It looks like this is just the first of several files with that build issue. If I build with 'make -k' I see several others fail with the same warning, e.g.: /home/steven/gcc-multilib/src/gcc-build/./gcc/xgcc -B/home/steven/gcc-multilib/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -c -g -O2 -mx32 -fpic -W -Wall -gnatpg -nostdinc -mx32 g-allein.ads -o g-allein.o g-allein.ads:183:04: warning: types for unchecked conversion have different sizes g-allein.ads:185:04: warning: types for unchecked conversion have different sizes g-allein.ads:187:04: warning: types for unchecked conversion have different sizes g-allein.ads:189:04: warning: types for unchecked conversion have different sizes g-allein.ads:191:04: warning: types for unchecked conversion have different sizes [... many more in the same file ...] /home/steven/gcc-multilib/src/gcc-build/./gcc/xgcc -B/home/steven/gcc-multilib/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -c -g -O2 -mx32 -fpic -W -Wall -gnatpg -nostdinc -mx32 s-wwdenu.adb -o s-wwdenu.o s-wwdenu.adb:55:07: warning: types for unchecked conversion have different sizes s-wwdenu.adb:94:07: warning: types for unchecked conversion have different sizes s-wwdenu.adb:133:07: warning: types for unchecked conversion have different sizes s-wwdenu.adb:172:07: warning: types for unchecked conversion have different sizes s-wwdenu.adb:211:07: warning: types for unchecked conversion have different sizes s-wwdenu.adb:250:07: warning: types for unchecked conversion have different sizes And several files fail with a different warning: /home/steven/gcc-multilib/src/gcc-build/./gcc/xgcc -B/home/steven/gcc-multilib/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -c -g -O2 -mx32 -fpic -W -Wall -gnatpg -nostdinc -mx32 a-dispat.adb -o a-dispat.o s-osinte.ads:608:07: size for "Address" too small, minimum allowed is 64 make[9]: *** [../gcc-interface/Makefile:296: a-dispat.o] Error 1 /home/steven/gcc-multilib/src/gcc-build/./gcc/xgcc -B/home/steven/gcc-multilib/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -c -g -O2 -mx32 -fpic -W -Wall -gnatpg -nostdinc -mx32 a-dynpri.adb -o a-dynpri.o s-osinte.ads:608:07: size for "Address" too small, minimum allowed is 64 make[9]: *** [../gcc-interface/Makefile:296: a-dynpri.o] Error 1 /home/steven/gcc-multilib/src/gcc-build/./gcc/xgcc -B/home/steven/gcc-multilib/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -c -g -O2 -mx32 -fpic -W -Wall -gnatpg -nostdinc -mx32 a-interr.adb -o a-interr.o s-osinte.ads:608:07: size for "Address" too small, minimum allowed is 64 make[9]: *** [../gcc-interface/Makefile:296: a-interr.o] Error 1
[Bug ada/80626] Ada x32 multilib build failure for a-cfinve.ads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80626 --- Comment #1 from Steven Noonan --- I configured with these flags, if they're needed for repro: --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://www.uplinklabs.net/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror --enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-libmpx --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --with-isl --with-linker-hash-style=gnu --with-multilib-list=m32,m64,mx32 --with-system-zlib
[Bug ada/80626] New: Ada x32 multilib build failure for a-cfinve.ads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80626 Bug ID: 80626 Summary: Ada x32 multilib build failure for a-cfinve.ads Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: steven at uplinklabs dot net Target Milestone: --- I'm sure this would be trivial to fix if I knew any Ada at all, but I've run into this build failure for GCC 7.1.0 when built with --with-multilib=m32,m64,mx32 for x86_64. make[9]: Entering directory '/home/steven/gcc-multilib/src/gcc-build/gcc/ada/rts_x32' [...] /home/steven/gcc-multilib/src/gcc-build/./gcc/xgcc -B/home/steven/gcc-multilib/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -c -g -O2 -mx32 -fpic -W -Wall -gnatpg -nostdinc -mx32 a-cfinve.adb -o a-cfinve.o a-cfinve.ads:245:04: warning: in instantiation at a-coboho.adb:55 a-cfinve.ads:245:04: warning: types for unchecked conversion have different sizes make[9]: *** [../gcc-interface/Makefile:296: a-cfinve.o] Error 1 Any ideas?
[Bug other/78844] New: target_clones causes compiler memory corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78844
Bug ID: 78844
Summary: target_clones causes compiler memory corruption
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Target Milestone: ---
Using modified version of test case from PR78808:
---
__attribute__((target_clones("avx2,fma,bmi,bmi2", "arch=sandybridge",
"default")))
static void _saxpy(int n, float a, float * restrict x, float * restrict y)
{
#pragma omp parallel for
for (int i = 0; i < n; ++i)
y[i] = a*x[i] + y[i];
}
void saxpy(int n, float a, float * restrict x, float * restrict y)
{
return _saxpy(n, a, x, y);
}
---
Only difference is the first argument for target_clones. Original intent was to
list the necessary features provided in arch=haswell without requiring an exact
architecture match (i.e. arch=haswell code path doesn't selected on a Skylake
host, so my theory was that feature checks would work better).
Attempting to compile the above results in memory corruption in cc1:
$ gcc -O3 -std=gnu11 -ffast-math -S test.c
*** Error in `/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1': malloc(): memory
corruption (fast): 0x02e5f690 ***
=== Backtrace: =
/usr/lib/libc.so.6(+0x70cdb)[0x7f8442a3fcdb]
/usr/lib/libc.so.6(+0x770b6)[0x7f8442a460b6]
/usr/lib/libc.so.6(+0x794e1)[0x7f8442a484e1]
/usr/lib/libc.so.6(__libc_malloc+0x54)[0x7f8442a49eb4]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(xmalloc+0x18)[0x10bd1f8]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1[0xff477a]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_ZN12symbol_table29call_cgraph_duplication_hooksEP11cgraph_nodeS1_+0x2c)[0x6e93bc]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_ZN11cgraph_node20create_version_cloneEP9tree_node3vecIP11cgraph_edge7va_heap6vl_ptrEP11bitmap_head+0x232)[0x6f9082]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_ZN11cgraph_node30create_version_clone_with_bodyE3vecIP11cgraph_edge7va_heap6vl_ptrEPS0_IP15ipa_replace_map5va_gc8vl_embedEP11bitmap_headbSD_P15basic_block_defPKc+0xb1)[0x6f9161]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1[0x101a7a0]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1[0x101a865]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_Z16execute_one_passP8opt_pass+0x163)[0x954113]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_Z21execute_ipa_pass_listP8opt_pass+0x92)[0x954d72]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1[0x6f57aa]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_ZN12symbol_table25finalize_compilation_unitEv+0xd3)[0x6f7533]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1[0xa02c85]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_ZN6toplev4mainEiPPc+0x6d4)[0x5de7d4]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(main+0x27)[0x5e09a7]
/usr/lib/libc.so.6(__libc_start_main+0xf1)[0x7f84429ef321]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_start+0x2a)[0x5e0daa]
=== Memory map:
0040-01a7b000 r-xp fe:00 25167806
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1
01c7b000-01c81000 r--p 0167b000 fe:00 25167806
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1
01c81000-01c8e000 rw-p 01681000 fe:00 25167806
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1
01c8e000-01dd8000 rw-p 00:00 0
02d47000-02ec1000 rw-p 00:00 0 [heap]
7f843c00-7f843c021000 rw-p 00:00 0
7f843c021000-7f844000 ---p 00:00 0
7f84423d6000-7f84423ec000 r-xp fe:00 25171169
/usr/lib/libgcc_s.so.1
7f84423ec000-7f84425eb000 ---p 00016000 fe:00 25171169
/usr/lib/libgcc_s.so.1
7f84425eb000-7f84425ec000 r--p 00015000 fe:00 25171169
/usr/lib/libgcc_s.so.1
7f84425ec000-7f84425ed000 rw-p 00016000 fe:00 25171169
/usr/lib/libgcc_s.so.1
7f84425ed000-7f84427ed000 rw-p 00:00 0
7f84427ed000-7f84429cf000 r--p fe:00 25186508
/usr/lib/locale/locale-archive
7f84429cf000-7f8442b64000 r-xp fe:00 25171021
/usr/lib/libc-2.24.90.so
7f8442b64000-7f8442d63000 ---p 00195000 fe:00 25171021
/usr/lib/libc-2.24.90.so
7f8442d63000-7f8442d67000 r--p 00194000 fe:00 25171021
/usr/lib/libc-2.24.90.so
7f8442d67000-7f8442d69000 rw-p 00198000 fe:00 25171021
/usr/lib/libc-2.24.90.so
7f8442d69000-7f8442d6d000 rw-p 00:00 0
7f8442d6d000-7f8442e7 r-xp fe:00 25171130
/usr/lib/libm-2.24.90.so
7f8442e7-7f844306f000 ---p 00103000 fe:00 25171130
/usr/lib/libm-2.24.90.so
7f844306f000-7f844307 r--p 00102000 fe:00 25171130
/usr/lib/libm-2.24.90.so
7f844307-7f8443071000 rw-p 00103000 fe:00 25171130
/usr
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808 --- Comment #3 from Steven Noonan --- Created attachment 40335 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40335=edit compiled with -fopenmp
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808 --- Comment #2 from Steven Noonan --- Created attachment 40334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40334=edit compiled without -fopenmp
[Bug other/78808] target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808 --- Comment #1 from Steven Noonan --- Created attachment 40333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40333=edit test.c - test case for target_clones with(out) -fopenmp
[Bug other/78808] New: target_clones not applying to openmp functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78808
Bug ID: 78808
Summary: target_clones not applying to openmp functions
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Target Milestone: ---
Simple test case:
---
__attribute__((target_clones("arch=haswell", "arch=sandybridge", "default")))
static void _saxpy(int n, float a, float * restrict x, float * restrict y)
{
#pragma omp parallel for
for (int i = 0; i < n; ++i)
y[i] = a*x[i] + y[i];
}
void saxpy(int n, float a, float * restrict x, float * restrict y)
{
return _saxpy(n, a, x, y);
}
---
Compile with:
gcc-6 -O3 -std=gnu11 -ffast-math -S
If -fopenmp is specified, the OpenMP-generated function for the parallelized
for() loop is generated with the default optimizations (not respecting
target_clones).
See attachments for comparison.
[Bug target/70858] __builtin_ia32_bextr_u64 ICE with '-m32 -march=core-avx2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70858 --- Comment #3 from Steven Noonan --- Cool. I'll let the project maintainer know to not use the __builtin_* variants. _bextr_u32 and _bextr_u64 look much more friendly, too.
[Bug target/70858] New: __builtin_ia32_bextr_u64 ICE with '-m32 -march=core-avx2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70858
Bug ID: 70858
Summary: __builtin_ia32_bextr_u64 ICE with '-m32
-march=core-avx2'
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/6.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-6.1.0/configure
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://www.uplinklabs.net/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --disable-libssp
--disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror
--enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit
--enable-gnu-indirect-function --enable-gnu-unique-object
--enable-install-libiberty --enable-libmpx --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --with-isl --with-linker-hash-style=gnu
--with-multilib-list=m32,m64,mx32 --with-system-zlib
Thread model: posix
gcc version 6.1.0 (GCC)
Reduced testcase via creduce:
$ cat test.i
int a, b, c;
int d() { c = __builtin_ia32_bextr_u64(a, b); }
$ gcc -m32 -march=core-avx2 -c test.i
test.i: In function ‘d’:
test.i:2:1: error: unrecognizable insn:
int d() { c = __builtin_ia32_bextr_u64(a, b); }
^~~
(insn 9 8 10 2 (parallel [
(set (reg:DI 91 [ _6 ])
(unspec:DI [
(reg:DI 90 [ _5 ])
(reg:DI 88 [ _3 ])
] UNSPEC_BEXTR))
(clobber (reg:CC 17 flags))
]) test.i:2 -1
(nil))
test.i:2:1: internal compiler error: in extract_insn, at recog.c:2287
[Bug tree-optimization/65337] [5/6 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337
--- Comment #9 from Steven Noonan steven at uplinklabs dot net ---
Sure.
$ gdb --args
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-build/./prev-gcc/xgcc
-B/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-build/./prev-gcc/
-B/usr/x86_64-unknown-linux-gnu/bin/ -B/usr/x86_64-unknown-linux-gnu/bin/
-B/usr/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/x86_64-unknown-linux-gnu/include -isystem
/usr/x86_64-unknown-linux-gnu/sys-include-c -g -O2 -flto=jobserver
-frandom-seed=1 -gnatpg -W -Wall -nostdinc -I- -I. -Iada/generated -Iada
-I/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-5-20150602/gcc/ada
-I/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-5-20150602/gcc/ada/gcc-interface
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-5-20150602/gcc/ada/comperr.adb
-o ada/comperr.o
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-unknown-linux-gnu.
Type show configuration for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type help.
Type apropos word to search for commands related to word...
Reading symbols from
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-build/./prev-gcc/xgcc...done.
warning: File
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-build/gcc/.gdbinit
auto-loading has been declined by your `auto-load safe-path' set to
$debugdir:$datadir/auto-load.
To enable execution of this file add
add-auto-load-safe-path
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-build/gcc/.gdbinit
line to your configuration file /home/snoonan/.gdbinit.
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file /home/snoonan/.gdbinit.
For more information about this security protection see the
Auto-loading safe path section in the GDB manual. E.g., run from the shell:
info (gdb)Auto-loading safe path
(gdb) set follow-fork-mode child
(gdb) run
Starting program:
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-build/prev-gcc/xgcc
-B/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-build/./prev-gcc/
-B/usr/x86_64-unknown-linux-gnu/bin/ -B/usr/x86_64-unknown-linux-gnu/bin/
-B/usr/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/x86_64-unknown-linux-gnu/include -isystem
/usr/x86_64-unknown-linux-gnu/sys-include -c -g -O2 -flto=jobserver
-frandom-seed=1 -gnatpg -W -Wall -nostdinc -I- -I. -Iada/generated -Iada
-I/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-5-20150602/gcc/ada
-I/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-5-20150602/gcc/ada/gcc-interface
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-5-20150602/gcc/ada/comperr.adb
-o ada/comperr.o
[New process 16017]
process 16017 is executing new program:
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-build/prev-gcc/gnat1
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 16017]
0x00c354ed in ei_edge (i=...) at
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-5-20150602/gcc/basic-block.h:460
460 return EDGE_I (ei_container (i), i.index);
(gdb) thread apply all bt full
Thread 2 (process 16017):
#0 0x00c354ed in ei_edge (i=...) at
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-5-20150602/gcc/basic-block.h:460
No locals.
#1 0x00c376cf in inverted_post_order_compute (post_order=0x2e3d9a0,
start_points=0x2bb0858 bb_contains_live_stmts) at
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-5-20150602/gcc/cfganal.c:837
ei = {
index = 0,
container = 0x768543a8
}
pred = 0x76c8b8be malloc+110
has_unvisited_bb = false
bb = 0x0
stack = 0x2e1e740
sp = 171
post_order_num = 0
visited = 0x2decb40
__FUNCTION__ = inverted_post_order_compute
#2 0x011ddcdc in remove_dead_stmt (i=0x7fffc950,
bb=0x75ad07b8) at
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc-5-20150602/gcc/tree-ssa-dce.c:1076
postorder = 0x2e3d9a0
postorder_num = 0
ei = {
index = 4121675328,
container = 0x7fffc860
}
e = 0x0
e2 = 0xdc9474 gimple_call_flags(gimple_statement_base const*)+47
stmt = 0x75abc640
__FUNCTION__ = remove_dead_stmt
#3 0x011de918 in eliminate_unnecessary_stmts () at
/home/snoonan/Development/ec2-packages/gcc-multilib/src/gcc
[Bug tree-optimization/65337] [5/6 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337 --- Comment #7 from Steven Noonan steven at uplinklabs dot net --- Tried applying the patch mentioned in comment 6 and doing a build using --with-build-config=bootstrap-lto. Ended with: [...] /build/gcc-multilib/src/gcc-build/./prev-gcc/xgcc -B/build/gcc-multilib/src/gcc-build/./prev-gcc/ -B/usr/x86_64-unknown-linux-gnu/bin / -B/usr/x86_64-unknown-linux-gnu/bin/ -B/usr/x86_64-unknown-linux-gnu/lib/ -isystem /usr/x86_64-unknown-linux-gnu/include -isystem / usr/x86_64-unknown-linux-gnu/sys-include-c -g -O2 -flto=jobserver -frandom-seed=1 -gnatpg -W -Wall -nostdinc -I- -I. -Iada/gene rated -Iada -I/build/gcc-multilib/src/gcc-5-20150602/gcc/ada -I/build/gcc-multilib/src/gcc-5-20150602/gcc/ada/gcc-interface /build/gc c-multilib/src/gcc-5-20150602/gcc/ada/comperr.adb -o ada/comperr.o [...] raised STORAGE_ERROR : stack overflow or erroneous memory access /build/gcc-multilib/src/gcc-5-20150602/gcc/ada/gcc-interface/Make-lang.in:119: recipe for target 'ada/comperr.o' failed Ideas?
[Bug lto/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828 --- Comment #2 from Steven Noonan steven at uplinklabs dot net --- I just noticed that libtool appears to be stripping some of the arguments in LDFLAGS when invoking GCC: /bin/sh ../libtool --tag=CC --mode=link gcc -flto -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Werror=missing-prototypes -Werror=implicit-function-declaration -Werror=pointer-arith -Werror=init-self -Werror=format=2 -Werror=missing-include-dirs -fvisibility=hidden -O2 -fsanitize=undefined -Wl,-Bsymbolic-functions -version-info 4400:0:4400 -export-dynamic -O2 -fsanitize=undefined -o libglib-2.0.la -rpath /usr/local/lib [[.lo files]] libcharset/libcharset.la pcre/libpcre.la -lpthread libtool: link: gcc -flto -shared -fPIC -DPIC [[.o files]] -Wl,--whole-archive libcharset/.libs/libcharset.a pcre/.libs/libpcre.a -Wl,--no-whole-archive -lpthread -flto -O2 -Wl,-Bsymbolic-functions -O2 -Wl,-soname -Wl,libglib-2.0.so.0 -o .libs/libglib-2.0.so.0.4400.0 In particular it dropped the -fsanitize=undefined flag. If I invoke the libtool-generated GCC command line with '-fsanitize=undefined' added then there's no ICE. $ gcc -flto -shared -fPIC -DPIC [[.o files]] -Wl,--whole-archive libcharset/.libs/libcharset.a pcre/.libs/libpcre.a -Wl,--no-whole-archive -lpthread -flto -O2 -Wl,-Bsymbolic-functions -O2 -Wl,-soname -Wl,libglib-2.0.so.0 -o .libs/libglib-2.0.so.0.4400.0 -fsanitize=undefined $ ls -cahl .libs/libglib-2.0.so.0.4400.0 -rwxr-xr-x 1 snoonan snoonan 4.3M Apr 21 03:31 .libs/libglib-2.0.so.0.4400.0 Hmm.
[Bug lto/65828] New: [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828 Bug ID: 65828 Summary: [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: steven at uplinklabs dot net Host architecture is x86_64, GCC version is the 4.9-20150415 snapshot. I've also seen this ICE on the 5-20150414 snapshot under the same conditions. The only thing I'm doing that's really unusual is combining -flto and -fsanitize=undefined. Normally I'd provide a reduced test case, but delta decided after some churning that the args file provided to lto1 was already reduced -- and the tarball of those objects was larger than the max attachment size. So in lieu of a nice attached repro, here are some steps: $ wget http://ftp.gnome.org/pub/GNOME/sources/glib/2.44/glib-2.44.0.tar.xz $ tar xf glib-2.44.0.tar.xz $ cd glib-2.44.0 $ ./configure --disable-debug CC=gcc -flto AR=gcc-ar RANLIB=gcc-ranlib CFLAGS=-O2 -fsanitize=undefined $ make It will break on the libglib-2.0.la link step: $ gcc -v -save-temps -flto -shared -fPIC -DPIC .libs/libglib_2_0_la-gallocator.o .libs/libglib_2_0_la-gcache.o .libs/libglib_2_0_la-gcompletion.o .libs/libglib_2_0_la-grel.o .libs/libglib_2_0_la-gthread-deprecated.o .libs/libglib_2_0_la-garray.o .libs/libglib_2_0_la-gasyncqueue.o .libs/libglib_2_0_la-gatomic.o .libs/libglib_2_0_la-gbacktrace.o .libs/libglib_2_0_la-gbase64.o .libs/libglib_2_0_la-gbitlock.o .libs/libglib_2_0_la-gbookmarkfile.o .libs/libglib_2_0_la-gbytes.o .libs/libglib_2_0_la-gcharset.o .libs/libglib_2_0_la-gchecksum.o .libs/libglib_2_0_la-gconvert.o .libs/libglib_2_0_la-gdataset.o .libs/libglib_2_0_la-gdate.o .libs/libglib_2_0_la-gdatetime.o .libs/libglib_2_0_la-gdir.o .libs/libglib_2_0_la-genviron.o .libs/libglib_2_0_la-gerror.o .libs/libglib_2_0_la-gfileutils.o .libs/libglib_2_0_la-ggettext.o .libs/libglib_2_0_la-ghash.o .libs/libglib_2_0_la-ghmac.o .libs/libglib_2_0_la-ghook.o .libs/libglib_2_0_la-ghostutils.o .libs/libglib_2_0_la-giochannel.o .libs/libglib_2_0_la-gkeyfile.o .libs/libglib_2_0_la-glib-init.o .libs/libglib_2_0_la-glib-private.o .libs/libglib_2_0_la-glist.o .libs/libglib_2_0_la-gmain.o .libs/libglib_2_0_la-gmappedfile.o .libs/libglib_2_0_la-gmarkup.o .libs/libglib_2_0_la-gmem.o .libs/libglib_2_0_la-gmessages.o .libs/libglib_2_0_la-gnode.o .libs/libglib_2_0_la-goption.o .libs/libglib_2_0_la-gpattern.o .libs/libglib_2_0_la-gpoll.o .libs/libglib_2_0_la-gprimes.o .libs/libglib_2_0_la-gqsort.o .libs/libglib_2_0_la-gquark.o .libs/libglib_2_0_la-gqueue.o .libs/libglib_2_0_la-grand.o .libs/libglib_2_0_la-gregex.o .libs/libglib_2_0_la-gscanner.o .libs/libglib_2_0_la-gsequence.o .libs/libglib_2_0_la-gshell.o .libs/libglib_2_0_la-gslice.o .libs/libglib_2_0_la-gslist.o .libs/libglib_2_0_la-gstdio.o .libs/libglib_2_0_la-gstrfuncs.o .libs/libglib_2_0_la-gstring.o .libs/libglib_2_0_la-gstringchunk.o .libs/libglib_2_0_la-gtestutils.o .libs/libglib_2_0_la-gthread.o .libs/libglib_2_0_la-gthreadpool.o .libs/libglib_2_0_la-gtimer.o .libs/libglib_2_0_la-gtimezone.o .libs/libglib_2_0_la-gtranslit.o .libs/libglib_2_0_la-gtrashstack.o .libs/libglib_2_0_la-gtree.o .libs/libglib_2_0_la-guniprop.o .libs/libglib_2_0_la-gutf8.o .libs/libglib_2_0_la-gunibreak.o .libs/libglib_2_0_la-gunicollate.o .libs/libglib_2_0_la-gunidecomp.o .libs/libglib_2_0_la-gurifuncs.o .libs/libglib_2_0_la-gutils.o .libs/libglib_2_0_la-gvariant.o .libs/libglib_2_0_la-gvariant-core.o .libs/libglib_2_0_la-gvariant-parser.o .libs/libglib_2_0_la-gvariant-serialiser.o .libs/libglib_2_0_la-gvarianttypeinfo.o .libs/libglib_2_0_la-gvarianttype.o .libs/libglib_2_0_la-gversion.o .libs/libglib_2_0_la-gwakeup.o .libs/libglib_2_0_la-gprintf.o .libs/libglib_2_0_la-glib-unix.o .libs/libglib_2_0_la-gthread-posix.o .libs/giounix.o .libs/gspawn.o -Wl,--whole-archive libcharset/.libs/libcharset.a pcre/.libs/libpcre.a -Wl,--no-whole-archive -lpthread -flto -O2 -Wl,-Bsymbolic-functions -Wl,-soname -Wl,libglib-2.0.so.0 -o .libs/libglib-2.0.so.0.4400.0 Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-4.9-20150415/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-multilib --disable-werror --with-multilib-list=m32,m64,mx32
[Bug lto/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828 --- Comment #1 from Steven Noonan steven at uplinklabs dot net --- If you want a nice tarball with a ready-to-go repro case, I've put it here: https://www.uplinklabs.net/files/lto-65828.tar.xz Should just be able to run something like: $ /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto1 -quiet -dumpdir .libs/ -dumpbase libglib-2.0.so.0.4400.0.wpa -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase libglib_2_0_la-gallocator -O2 -O2 -version -fno-trapv -fPIC -fltrans-output-list=libglib-2.0.so.0.4400.0.ltrans.out -fwpa -fresolution=libglib-2.0.so.res @ccWGeoup.args from inside the extracted directory and see the issue.
[Bug target/64409] ICE building Mesa 10.4.0 for x32 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64409 --- Comment #4 from Steven Noonan steven at uplinklabs dot net --- Ahh, didn't even think about an x32/ms_abi compatibility problems. That totally makes sense. It probably shouldn't work anyway, but an ICE is obviously not the right reaction from the compiler. What I should be doing is passing --disable-nine to the Mesa configure script and it will just skip the ms_abi-dependent features.
[Bug middle-end/64409] New: ICE building Mesa 10.4.0 for x32 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64409 Bug ID: 64409 Summary: ICE building Mesa 10.4.0 for x32 ABI Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: steven at uplinklabs dot net Created attachment 34335 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34335action=edit Preprocessed source Trying to build Mesa 10.4.0 for the X32 ABI on an x86_64 host, encountered an ICE in the process. Preprocessed source attached. Invocation was: $ gcc -mx32 -DPACKAGE_NAME=\Mesa\ -DPACKAGE_TARNAME=\mesa\ -DPACKAGE_VERSION=\10.4.0\ -DPACKAGE_STRING=\Mesa 10.4.0\ -DPACKAGE_BUGREPORT=\https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\; -DPACKAGE_URL=\\ -DPACKAGE=\mesa\ -DVERSION=\10.4.0\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DHAVE___BUILTIN_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1 -DHAVE___BUILTIN_CLZ=1 -DHAVE___BUILTIN_CLZLL=1 -DHAVE___BUILTIN_CTZ=1 -DHAVE___BUILTIN_EXPECT=1 -DHAVE___BUILTIN_FFS=1 -DHAVE___BUILTIN_FFSLL=1 -DHAVE___BUILTIN_POPCOUNT=1 -DHAVE___BUILTIN_POPCOUNTLL=1 -DHAVE___BUILTIN_UNREACHABLE=1 -DHAVE_FUNC_ATTRIBUTE_FLATTEN=1 -DHAVE_FUNC_ATTRIBUTE_FORMAT=1 -DHAVE_FUNC_ATTRIBUTE_MALLOC=1 -DHAVE_FUNC_ATTRIBUTE_PACKED=1 -DHAVE_DLADDR=1 -DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD=1 -I. -DNINE_TARGET -DGALLIUM_STATIC_TARGETS=1 -DGALLIUM_NOUVEAU -DGALLIUM_R300 -DGALLIUM_R600 -DGALLIUM_RADEONSI -DGALLIUM_SOFTPIPE -DGALLIUM_LLVMPIPE -I../../../../include/D3D9 -I../../../../src/loader -I../../../../src/mapi/ -I../../../../src/mesa/ -I../../../../src/mesa/drivers/dri/common/ -I../../../../src/mesa/drivers/dri/common/ -I../../../../src/gallium/winsys -I../../../../src/gallium/state_trackers/nine -I../../../../include -I../../../../src/loader -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I../../../../src/gallium/winsys -DUSE_EXTERNAL_DXTN_LIB=1 -D_GNU_SOURCE -DUSE_SSE41 -DTEXTURE_FLOAT_ENABLED -DHAVE_XLOCALE_H -DHAVE_STRTOF -DHAVE_DLOPEN -DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM -DHAVE_LIBUDEV -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DHAVE_ALIAS -DHAVE_DRI3 -DHAVE_MINCORE -DHAVE_LLVM=0x0305 -DLLVM_VERSION_PATCH=0 -pthread -I/usr/include/libdrm -fvisibility=hidden -fvisibility=hidden -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -MT d3dadapter9_la-getproc.lo -MD -MP -MF .deps/d3dadapter9_la-getproc.Tpo -c getproc.c -fPIC -DPIC -o .libs/d3dadapter9_la-getproc.o getproc.c: In function ‘D3DAdapter9GetProc’: getproc.c:38:1: internal compiler error: in emit_move_insn, at expr.c:3609 D3DAdapter9GetProc( const char *name ) ^ 0x7014c2 emit_move_insn(rtx_def*, rtx_def*) /build/gcc-multilib/src/gcc-4.9-20141210/gcc/expr.c:3608 0x647d64 expand_value_return /build/gcc-multilib/src/gcc-4.9-20141210/gcc/cfgexpand.c:3055 0x64e3b6 expand_return /build/gcc-multilib/src/gcc-4.9-20141210/gcc/cfgexpand.c:3127 0x64e3b6 expand_gimple_stmt_1 /build/gcc-multilib/src/gcc-4.9-20141210/gcc/cfgexpand.c:3200 0x64e3b6 expand_gimple_stmt /build/gcc-multilib/src/gcc-4.9-20141210/gcc/cfgexpand.c:3322 0x64eefb expand_gimple_basic_block /build/gcc-multilib/src/gcc-4.9-20141210/gcc/cfgexpand.c:5162 0x6511b6 gimple_expand_cfg /build/gcc-multilib/src/gcc-4.9-20141210/gcc/cfgexpand.c:5741 0x6511b6 execute /build/gcc-multilib/src/gcc-4.9-20141210/gcc/cfgexpand.c:5961 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See https://bugs.archlinux.org/ for instructions. Using 20141210 snapshot version of GCC: gcc version 4.9.2 20141210 (prerelease) (GCC)
[Bug middle-end/64409] ICE building Mesa 10.4.0 for x32 ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64409 --- Comment #1 from Steven Noonan steven at uplinklabs dot net --- Just built and tried using the 20141224 snapshot. Same issue: getproc.c: In function ‘D3DAdapter9GetProc’: getproc.c:38:1: internal compiler error: in emit_move_insn, at expr.c:3609 D3DAdapter9GetProc( const char *name ) ^ 0x7014e2 emit_move_insn(rtx_def*, rtx_def*) /build/gcc-multilib/src/gcc-4.9-20141224/gcc/expr.c:3608 0x647d84 expand_value_return /build/gcc-multilib/src/gcc-4.9-20141224/gcc/cfgexpand.c:3055 0x64e3d6 expand_return /build/gcc-multilib/src/gcc-4.9-20141224/gcc/cfgexpand.c:3127 0x64e3d6 expand_gimple_stmt_1 /build/gcc-multilib/src/gcc-4.9-20141224/gcc/cfgexpand.c:3200 0x64e3d6 expand_gimple_stmt /build/gcc-multilib/src/gcc-4.9-20141224/gcc/cfgexpand.c:3322 0x64ef1b expand_gimple_basic_block /build/gcc-multilib/src/gcc-4.9-20141224/gcc/cfgexpand.c:5162 0x6511d6 gimple_expand_cfg /build/gcc-multilib/src/gcc-4.9-20141224/gcc/cfgexpand.c:5741 0x6511d6 execute /build/gcc-multilib/src/gcc-4.9-20141224/gcc/cfgexpand.c:5961 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See https://bugs.archlinux.org/ for instructions.
[Bug driver/60233] AVX instructions emitted with -march=native on host without AVX support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233 --- Comment #12 from Steven Noonan steven at uplinklabs dot net --- Thanks for the fast resolution, Jakub!
[Bug driver/60233] New: AVX instructions emitted with -march=native on host without AVX support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233
Bug ID: 60233
Summary: AVX instructions emitted with -march=native on host
without AVX support
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: steven at uplinklabs dot net
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Running GCC in a paravirtual Xen guest on an Ivy Bridge host. The PV guest does
not have AVX support, and -march=native seems to detect this correctly:
$ gcc -O2 -march=native -E -v - /dev/null 21 | grep cc1
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/cc1 -E -quiet -v -
-march=core-avx-i -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm
-mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx
-mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mrdrnd -mf16c
-mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt
--param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=25600 -mtune=core-avx-i -O2
Note in particular the -mno-avx and -mno-xsave.
However, GCC is still emitting AVX instructions:
$ cat vadd8.c
typedef float v8f __attribute__ ((vector_size(32), aligned(1)));
void vadd8f(v8f *o, v8f *a, v8f *b)
{
*o = *a + *b;
}
$ echo | gcc -dM -E - -march=native | grep AVX
#define __AVX__ 1
$ gcc -O2 -march=native -c vadd8.c
$ objdump -S vadd8.o
vadd8.o: file format elf64-x86-64
Disassembly of section .text:
vadd8f:
0: c5 f8 10 0e vmovups (%rsi),%xmm1
4: c5 f8 10 02 vmovups (%rdx),%xmm0
8: c4 e3 75 18 4e 10 01vinsertf128 $0x1,0x10(%rsi),%ymm1,%ymm1
f: c4 e3 7d 18 42 10 01vinsertf128 $0x1,0x10(%rdx),%ymm0,%ymm0
16: c5 f4 58 c0 vaddps %ymm0,%ymm1,%ymm0
1a: c5 f8 11 07 vmovups %xmm0,(%rdi)
1e: c4 e3 7d 19 47 10 01vextractf128 $0x1,%ymm0,0x10(%rdi)
25: c5 f8 77vzeroupper
28: c3 retq
I'm guessing that the -march=core-avx-i it decided on is overriding the
-mno-avx flag, but this seems to be a regression to me.
Version information:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.8-20140206/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --disable-cloog-version-check --enable-lto
--enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu
--disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.8.2 20140206 (prerelease) (GCC)
[Bug driver/60233] AVX instructions emitted with -march=native on host without AVX support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233 --- Comment #2 from Steven Noonan steven at uplinklabs dot net --- Created attachment 32147 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32147action=edit /proc/cpuinfo
[Bug driver/60233] AVX instructions emitted with -march=native on host without AVX support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233 --- Comment #3 from Steven Noonan steven at uplinklabs dot net --- Created attachment 32148 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32148action=edit CPUID dump Adding both /proc/cpuinfo and a dump from a userspace utility using the CPUID instruction (since /proc/cpuinfo is assembled with information obtained via PV CPUID hypercall).
