[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886 A. Wilcox (awilfox) changed: What|Removed |Added CC||awilfox at adelielinux dot org --- Comment #25 from A. Wilcox (awilfox) --- (In reply to rsand...@gcc.gnu.org from comment #21) > But it was a mistake made by the GCC developers. Once something > is documented publicly, we shouldn't just remove it without > warning unless there's no realistic alternative. And it sounds > from what Jakub says like it's simple to keep this working. Thank you for being the voice of reason :) There is no reason to break a public interface when it is a one-liner to fix. At the *very* least, it would allow more time for discussion with musl and LLVM developers and other interested parties. (In reply to Segher Boessenkool from comment #23) > I will not add back all constraints I removed. Nobody here has asked for all constraints to be re-added. Only one, which was publicly documented for years, and used in real code. > The point is that we will never get to a good state if we cannot fix > up any historical mistakes. GCC typically announces deprecations for publicly-documented interfaces being removed versions ahead of time, and I'm surprised that wasn't followed here. Then a discussion could have taken place on if the deprecated interfaces were still needed, ways to refactor to make it less of a maintenance burden in the meantime, ways to move forward without breaking existing code, and so on. It is disturbing to me that "fixing up historical mistakes" appears to mean that GCC developers can just yank out public interfaces with no notice. I do not think this is what the community wants in a system compiler. > supports old POWER, never mind that no one ever uses that any more. I'm still using 970s daily. IBM's ppc64 kernel CI got a "new" G5 last year. ZTE (Chinese telecom) uses POWER6. Older POWER is definitely still used.
[Bug driver/89587] New: gcc's rs6000 configuration unconditionally sets MULTIARCH_DIRNAME, even when multiarch is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89587 Bug ID: 89587 Summary: gcc's rs6000 configuration unconditionally sets MULTIARCH_DIRNAME, even when multiarch is disabled Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: awilfox at adelielinux dot org Target Milestone: --- Host: powerpc-linux-* Target: powerpc-linux-* Simple reproduce is to build GCC to target powerpc-*-linux-*; powerpc-unknown-linux-gnu and powerpc-foxkit-linux-musl both exhibit this behaviour. The config/rs6000/t-linux file unconditionally sets MULTIARCH_DIRNAME, even when ./configure is passed --disable-multiarch. This results in, for instance: $ gcc -print-multiarch powerpc-linux-musl No other architecture's config file does this, other than powerpcspe, which is already deprecated.
[Bug middle-end/84823] [6 Regression] x86 LRA hang on valid code (no ICE) with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84823 A. Wilcox (awilfox) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from A. Wilcox (awilfox) --- I have no idea. We can't move to GCC 7.x due to regressions on other platforms, and 8.2.0 chewed more memory than our builders have available. (I should not be seeing oom_killer on a system with 72 GB RAM and -j32, but there it was anyway.) I suppose this can be closed as WONTFIX, if the 6 branch will not be seeing any further updates. I can reopen it if we manage to find a newer GCC release that meets our requirements and this errant behaviour still occurs.
[Bug rtl-optimization/87096] New: "Optimised" snprintf is not POSIX conformant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87096
Bug ID: 87096
Summary: "Optimised" snprintf is not POSIX conformant
Product: gcc
Version: 6.4.0
URL: http://pubs.opengroup.org/onlinepubs/9699919799/functi
ons/snprintf.html
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: awilfox at adelielinux dot org
Target Milestone: ---
POSIX Issue 7, 2018 edition (see URL)
The snprintf() function shall fail if:
[EOVERFLOW]
The value of n is greater than {INT_MAX}.
This behaviour may or may not be ISO C compatible: C99 WG14 and C11
specifically state that intending the printf family of functions to return
larger than INT_MAX is undefined behaviour: J.2. I am unclear on the status of
this behaviour with regards to C89. It is definitely required by POSIX.
The following line of C, which is the minimum reproduction case:
snprintf(buf, (size_t)INT_MAX + 1, "");
returns 0 when compiled with GCC unless -fno-builtin is passed.
[Bug middle-end/84823] [6 Regression] x86 LRA hang on valid code (no ICE) with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84823 --- Comment #5 from A. Wilcox (awilfox) --- Created attachment 44483 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44483=edit more preprocessed source that fails % gcc -DHAVE_CONFIG_H -I. -DLOCALEDIR=\"/usr/share/locale\" "-DRRD_DEFAULT_FONT=\"DejaVu Sans Mono,Bitstream Vera Sans Mono,monospace,Courier\"" -DNUMVERS=1.6999 -O2 -ggdb -march=pentium-mmx -mtune=pentium-m -fno-omit-frame-pointer -fno-guess-branch-probability -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/uuid -I/usr/include/harfbuzz -I/usr/include/libxml2 -O2 -ggdb -march=pentium-mmx -mtune=pentium-m -fno-omit-frame-pointer -fno-guess-branch-probability -g -g -D_GNU_SOURCE -fno-strict-aliasing -Wall -std=gnu99 -pedantic -Wundef -Wshadow -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wold-style-definition -W -fPIC -DPIC -I.. -O2 -ggdb -march=pentium-mmx -mtune=pentium-m -fno-omit-frame-pointer -fno-guess-branch-probability -g -g -D_GNU_SOURCE -fno-strict-aliasing -Wall -std=gnu99 -pedantic -Wundef -Wshadow -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wold-style-definition -W -fPIC -DPIC -MT librrd_la-rrd_resize.lo -MD -MP -MF .deps/librrd_la-rrd_resize.Tpo -c rrd_resize.c -fPIC -DPIC -o .libs/librrd_la-rrd_resize.o -fchecking -Q -save-temps Execution times (seconds) phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (100%) wall 433 kB (98%) ggc TOTAL : 0.00 0.00 0.01 441 kB Extra diagnostic checks enabled; compiler may run slowly. realpath __bswap16 __bswap32 __bswap64 __fortify_FD_CLR __fortify_FD_SET confstr getcwd getdomainname getgroups gethostname getlogin_r pread read readlink readlinkat ttyname_r write bcopy bzero memcpy memmove memset stpcpy stpncpy strcat strcpy strncat strncpy mempcpy strlcat strlcpy fgets fread fwrite vsnprintf vsprintf snprintf sprintf __isspace __FLOAT_BITS __DOUBLE_BITS __islessf __isless __islessl __islessequalf __islessequal __islessequall __islessgreaterf __islessgreater __islessgreaterl __isgreaterf __isgreater __isgreaterl __isgreaterequalf __isgreaterequal __isgreaterequall rrd_resize Analyzing compilation unit Performing interprocedural optimizations <*free_lang_data> Assembling functions: rrd_resize (It is at this point that gcc locks up.)
[Bug middle-end/84823] [6 Regression] x86 LRA hang on valid code (no ICE) with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84823 --- Comment #4 from A. Wilcox (awilfox) --- Even with -fno-guess-branch-probability (which is what we have put on our x86 builders so they run at all), rrdtool-1.7.0's rrd_resize.c has managed to make the same lock happen yet again. The only option that fixed it this time was -fno-tree-ter. I will go ahead and upload the .i of the run with just -fno-guess-branch-probability, in case that helps.
[Bug middle-end/84823] [6 Regression] x86 LRA hang on valid code (no ICE) with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84823 --- Comment #3 from A. Wilcox (awilfox) --- Tried disabling every single optimisation that was enabled by default in sequence, yielding the following results: % for i in $(cat gcc-options); do timeout 10 gcc -I.. -I.. -O2 -ggdb -march=pentium-mmx -mtune=pentium-m -fno-omit-frame-pointer -DHAVE_CONFIG_H -O2 -ggdb -march=pentium-mmx -mtune=pentium-m -fno-omit-frame-pointer -g -g -ggdb3 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -MT ecc-mul-a-test.o -MD -MP -MF ecc-mul-a-test.o.d -c ecc-mul-a-test.c $i && printf "$i fixed it\n"; done -fno-guess-branch-probability fixed it -fno-inline fixed it -fno-tree-ter fixed it I don't know if this helps any or not.
[Bug middle-end/84823] [6 Regression] x86 LRA hang on valid code (no ICE) with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84823 A. Wilcox (awilfox) changed: What|Removed |Added Known to fail||6.4.0 --- Comment #2 from A. Wilcox (awilfox) --- We applied the fix from PR78911 (rev 246059: https://code.foxkit.us/adelie/packages/blob/master/system/gcc/lra-pentium.patch is what we applied). We were running through a mass rebuild and just 52 minutes in, we've already tripped over this bug again, compiling the test suite for nettle-3.4: awilcox on ciall [pts/2 Sun 29 3:40] testsuite: gcc -I.. -I.. -O2 -ggdb -march=pentium-mmx -mtune=pentium-m -fno-omit-frame-pointer -DHAVE_CONFIG_H -O2 -ggdb -march=pentium-mmx -mtune=pentium-m -fno-omit-frame-pointer -g -g -ggdb3 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -MT ecc-mul-a-test.o -MD -MP -MF ecc-mul-a-test.o.d -c ecc-mul-a-test.c -fchecking -Q -save-temps Execution times (seconds) phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (100%) wall 549 kB (98%) ggc TOTAL : 0.00 0.00 0.01 558 kB Extra diagnostic checks enabled; compiler may run slowly. realpath fgets fread fwrite vsnprintf vsprintf snprintf sprintf bcopy bzero memcpy memmove memset stpcpy stpncpy strcat strcpy strncat strncpy strlcat strlcpy __gmpz_abs __gmpz_fits_uint_p __gmpz_fits_ulong_p __gmpz_fits_ushort_p __gmpz_get_ui __gmpz_getlimbn __gmpz_neg __gmpz_perfect_square_p __gmpz_popcount __gmpz_set_q __gmpz_size __gmpq_abs __gmpq_neg __gmpn_add __gmpn_add_1 __gmpn_cmp __gmpn_zero_p __gmpn_sub __gmpn_sub_1 __gmpn_neg test_main Analyzing compilation unit Performing interprocedural optimizations <*free_lang_data> Assembling functions: test_main Attaching to process 20502 Reading symbols from /usr/libexec/gcc/i586-foxkit-linux-musl/6.4.0/cc1...(no debugging symbols found)...done. Reading symbols from /usr/lib/libisl.so.15...(no debugging symbols found)...done. Reading symbols from /usr/lib/libmpc.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libmpfr.so.4...(no debugging symbols found)...done. Reading symbols from /usr/lib/libgmp.so.10...(no debugging symbols found)...done. Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done. Reading symbols from /lib/ld-musl-i386.so.1...Reading symbols from /usr/lib/debug//lib/ld-musl-i386.so.1.debug...done. done. 0x084faee6 in lra_assign() () (gdb) bt #0 0x084faee6 in lra_assign() () #1 0x084f67f6 in lra(_IO_FILE*) () #2 0x084b1f97 in ?? () #3 0x08584ab4 in execute_one_pass(opt_pass*) () #4 0x08585068 in ?? () #5 0x08585078 in ?? () #6 0x085850da in execute_pass_list(function*, opt_pass*) () #7 0x082ebfe4 in cgraph_node::expand() () #8 0x082ed656 in ?? () #9 0x082ef189 in symbol_table::finalize_compilation_unit() () #10 0x086404fc in ?? () #11 0x081bd7f4 in toplev::main(int, char**) () #12 0x081bf8c8 in main ()
[Bug middle-end/84823] New: [6 Regression?] x86 LRA hang on valid code (no ICE) with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84823 Bug ID: 84823 Summary: [6 Regression?] x86 LRA hang on valid code (no ICE) with -fno-omit-frame-pointer Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: awilfox at adelielinux dot org Target Milestone: --- Created attachment 43626 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43626=edit preprocessed source that fails Environment: Adélie Linux 1.0-alpha5 Intel(R) Pentium(R) 4 CPU 2.40GHz [15/2/9; HT enabled] gcc (Adelie 6.4.0) 6.4.0 musl libc 1.1.19 Scenario: Compiling WINE 3.0 for the x86 architecture of Adélie on our builder. Target arch is Pentium MMX. Actual result: cc1 hung for almost 16 hours while compiling ntdll/server.c. Trying again with -fchecking -Q made no difference; three hours later, no ICE was generated. Output was: __FLOAT_BITS __DOUBLE_BITS __islessf __isless __islessl __islessequalf __islessequal __islessequall __islessgreaterf __islessgreater __islessgreaterl __isgreaterf __isgreater __isgreaterl __isgreaterequalf __isgreaterequal __isgreaterequall __bswap16 __bswap32 __bswap64 __fortify_FD_CLR __fortify_FD_SET bcopy bzero memcpy memmove memset stpcpy stpncpy strcat strcpy strncat strncpy mempcpy strlcat strlcpy realpath confstr getcwd getdomainname getgroups gethostname getlogin_r pread read readlink readlinkat ttyname_r write memcpy_unaligned interlocked_cmpxchg interlocked_cmpxchg_ptr interlocked_xchg interlocked_xchg_ptr interlocked_xchg_add interlocked_cmpxchg64 __isspace fgets fread fwrite vsnprintf vsprintf snprintf sprintf recv recvfrom send sendto NtCurrentTeb RtlSecureZeroMemory HRESULT_FROM_WIN32 lstrcpynW lstrcpynA lstrlenW lstrlenA lstrcpyW lstrcpyA lstrcatW lstrcatA InterlockedCompareExchangePointer InterlockedExchangePointer GetLastError GetCurrentProcessId GetCurrentThreadId SetLastError GetProcessHeap wine_ldt_set_base wine_ldt_set_limit wine_ldt_get_base wine_ldt_get_limit wine_ldt_set_flags wine_ldt_get_flags wine_ldt_is_empty wine_get_cs wine_get_ds wine_get_es wine_get_fs wine_get_gs wine_get_ss wine_set_fs wine_set_gs DbgBreakPoint DbgUserBreakPoint RtlCheckBit RtlUshortByteSwap RtlUlongByteSwap RemoveHeadList RemoveTailList get_vm86_teb_info wine_server_call_err wine_server_reply_size wine_server_add_data wine_server_set_reply wine_server_obj_handle wine_server_user_handle wine_server_ptr_handle wine_server_client_ptr wine_server_get_ptr wine_dbgstr_a wine_dbgstr_w wine_dbgstr_guid wine_dbgstr_point wine_dbgstr_rect wine_dbgstr_longlong debugstr_an debugstr_wn debugstr_guid debugstr_a debugstr_w __CPU_AND_S __CPU_OR_S __CPU_XOR_S ntdll_get_thread_data interlocked_xchg64 fatal_error fatal_perror server_protocol_error server_protocol_perror send_request read_reply_data wait_reply server_call_unlocked wine_server_call server_enter_uninterrupted_section server_leave_uninterrupted_section wait_select_reply invoke_apc server_select server_queue_process_apc wine_server_send_fd receive_fd handle_to_index add_fd_to_cache get_cached_fd server_remove_fd_from_cache server_get_unix_fd wine_server_fd_to_handle wine_server_handle_to_fd wine_server_release_fd server_pipe start_server setup_config_dir server_connect_error server_connect get_unix_tid server_init_process server_init_process_done server_init_thread Analyzing compilation unit Performing interprocedural optimizations <*free_lang_data> Assembling functions: server_protocol_error server_protocol_perror read_reply_data wait_select_reply invoke_apc receive_fd add_fd_to_cache fatal_perror fatal_error start_server server_connect server_call_unlocked wine_server_call server_enter_uninterrupted_section server_leave_uninterrupted_section server_select server_queue_process_apc wine_server_send_fd server_remove_fd_from_cache server_get_unix_fd Expected result: Compilation of ntdll/server.c translation unit. CFLAGS in use at the time (incl. WINE package defaults and Adélie overrides): gcc -c -o server.o server.c -I. -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wn-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -O2 -march=pentium-mmx -mtune=pentium-m -fno-omit-frame-pointer -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 If -fno-omit-frame-pointer is removed, compilation succeeds. If -O2 is replaced with -O0, compilation succeeds. It feels like a rehash of 55396 but that was solved back in the 4.x days. I will note that when we built WINE 2.x last year with GCC 5.3.0 this issue did not occur, and -fno-omit-frame-pointer was active th
[Bug bootstrap/78553] New: GCC 5.3.0 and 5.4.0 segfault during bootstrap when --enable-vtable-verify is enabled on PowerPC musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78553
Bug ID: 78553
Summary: GCC 5.3.0 and 5.4.0 segfault during bootstrap when
--enable-vtable-verify is enabled on PowerPC musl
Product: gcc
Version: 5.4.0
URL: https://bugs.gentoo.org/show_bug.cgi?id=588664
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: awilfox at adelielinux dot org
Target Milestone: ---
Target: powerpc-linux-musl
Created attachment 40170
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40170=edit
Each crash seen during make -j4 of GCC 5.4.0
I have been able to confirm that passing --enable-vtable-verify to ./configure
causes these GCC versions to segfault during the build of libstdc++-v3 on
PowerPC targets:
5.3.0, no patches
5.3.0, Gentoo patches
5.3.0, musl-cross-make patches
5.4.0, no patches
5.4.0, Adélie patches
5.4.0, Gentoo patches
5.4.0, musl-cross-make patches
In file included from
/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/gcc-5.4.0/libstdc++-v3/src/c++98/complex_io.cc:25:0:
/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/include/complex:
In function ‘std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::complex<_Tp>&)
[with _Tp = long double; _CharT = wchar_t; _Traits =
std::char_traits]’:
/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/include/complex:526:5:
internal compiler error: Segmentation fault
operator<<(basic_ostream<_CharT, _Traits>& __os, const complex<_Tp>& __x)
^
Disabling --enable-vtable-verify allows the build to complete successfully.
This happens to me on PowerPC and PowerPC64 glibc hosts
(powerpc{,64}-linux-gnu), but appears to also occur on x86_64-linux-gnu targets
per the Gentoo bug in the URL field.
Backtrace follows from my PowerPC64 system. I no longer have the .ii file but
I can recreate it if it is needed (it takes about 40 minutes to get to the
failure point).
Starting program:
/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/gcc/xgcc
-shared-libgcc
-B/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/./gcc
-nostdinc++
-L/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/src
-L/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/src/.libs
-L/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/libsupc++/.libs
-B/usr/powerpc-foxkit-linux-musl/bin/ -B/usr/powerpc-foxkit-linux-musl/lib/
-isystem /usr/powerpc-foxkit-linux-musl/include -isystem
/usr/powerpc-foxkit-linux-musl/sys-include
-I/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/gcc-5.4.0/libstdc++-v3/../libgcc
-I/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/include/powerpc-foxkit-linux-musl
-I/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/powerpc-foxkit-linux-musl/libstdc++-v3/include
-I/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/gcc-5.4.0/libstdc++-v3/libsupc++
-D_GLIBCXX_SHARED -fno-implicit-templates -fvtable-verify=std
-Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=complex_io.lo -g -O2
-D_GNU_SOURCE -c
/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/gcc-5.4.0/libstdc++-v3/src/c++98/complex_io.cc
-fPIC -DPIC -D_GLIBCXX_SHARED -o complex_io.o
[New process 11748]
process 11748 is executing new program:
/var/tmp/portage/cross-powerpc-foxkit-linux-musl/gcc-5.4.0/work/build/gcc/cc1plus
Thread 2.1 "cc1plus" received signal SIGSEGV, Segmentation fault.
[Switching to process 11748]
0x1040f2d4 in .symtab_node::ultimate_alias_target(availability*) ()
(gdb) bt
#0 0x1040f2d4 in .symtab_node::ultimate_alias_target(availability*) ()
#1 0x1063adbc in .cgraph_node::ultimate_alias_target(availability*) ()
#2 0x110ed540 in .call_ABI_of_interest(tree_node*) ()
#3 0x110ed8f4 in .init_cumulative_args(rs6000_args*, tree_node*,
rtx_def*, int, int, int, tree_node*, machine_mode) ()
#4 0x105c239c in .expand_call(tree_node*, rtx_def*, int) ()
#5 0x1079ea20 in .expand_expr_real_1(tree_node*, rtx_def*,
machine_mode, expand_modifier, rtx_def**, bool) ()
#6 0x107949a4 in .expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool) ()
#7 0x1078c0e0 in .store_expr_with_bo
[Bug tree-optimization/71980] [5] libraw on x86_64-linux-musl causes ICE in vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71980 A. Wilcox (awilfox) changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from A. Wilcox (awilfox) --- I can confirm that libraw compiles with -O4 as it so desires using 5.4.0 + the patch mentioned in bug 71702 on the same target as reported in the bug description. *** This bug has been marked as a duplicate of bug 71702 ***
[Bug tree-optimization/71702] dr_group_sort_cmp violates transitivity required for qsort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71702 A. Wilcox (awilfox) changed: What|Removed |Added CC||awilfox at adelielinux dot org --- Comment #6 from A. Wilcox (awilfox) --- *** Bug 71980 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/71980] New: [5] libraw on x86_64-linux-musl causes ICE in vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71980 Bug ID: 71980 Summary: [5] libraw on x86_64-linux-musl causes ICE in vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596 Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: awilfox at adelielinux dot org Target Milestone: --- Hello. We are starting a new musl libc-based Linux distribution targeting desktops called Adélie Linux; our target is therefore x86_64-foxkit-linux-musl. We use the Gentoo and musl patchsets for GCC. I have also cherry-picked the fix for #71505 and applied it as an additional patch, since it seemed to have a very similar issue. Still, we are seeing the following output when attempting to build libraw-0.16.2: [ 42%] Building CXX object CMakeFiles/raw_r.dir/internal/demosaic_packs.cpp.o /usr/bin/x86_64-foxkit-linux-musl-g++ -DUSE_JPEG -DUSE_JPEG8 -DUSE_LCMS2 -Draw_r_EXPORTS -DNDEBUG -O2 -ggdb -march=nocona -mtune=core2 -fno-omit-frame-pointer -mfpmath=sse -fPIC -I/usr/src/media-libs/libraw-0.16.2/work/LibRaw-0.16.2-.default -I/usr/src/media-libs/libraw-0.16.2/work/LibRaw-0.16.2-w -fPIC -O4 -o CMakeFiles/raw_r.dir/internal/demosaic_packs.cpp.o -c /usr/src/media-libs/libraw-0.16.2/work/LibRaw-0.16.2/internal/demosaic_packs.cpp /usr/src/media-libs/libraw-0.16.2/work/LibRaw-0.16.2/internal/./dcb_demosaicing.c: In member function ‘void LibRaw::dcb_nyquist()’: /usr/src/media-libs/libraw-0.16.2/work/LibRaw-0.16.2/internal/demosaic_packs.cpp:26:15: internal compiler error: in vect_analyze_data_ref_accesses, at tree-vect-data-refs.c:2596 #define CLASS LibRaw:: ^ /usr/src/media-libs/libraw-0.16.2/work/LibRaw-0.16.2/internal/./dcb_demosaicing.c:231:6: note: in expansion of macro ‘CLASS’ void CLASS dcb_nyquist() ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://bts.adelielinux.org/> for instructions. CMakeFiles/raw.dir/build.make:110: recipe for target 'CMakeFiles/raw.dir/internal/demosaic_packs.cpp.o' failed make[2]: *** [CMakeFiles/raw.dir/internal/demosaic_packs.cpp.o] Error 1 This also occurs on a vanilla 5.4.0, i.e. without any distro patches applied. I do realise that upstream really should not be using -O4. Adding "-fno-tree-loop-vectorize -fno-tree-slp-vectorize" allowed the build to continue. But since this is likely a bug anyway, I have filed it here. ciall ~ # gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-foxkit-linux-musl/gcc-bin/5.4.0/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-foxkit-linux-musl/5.4.0/lto-wrapper Target: x86_64-foxkit-linux-musl Configured with: /var/tmp/portage/sys-devel/gcc-5.4.0-r1/work/gcc-5.4.0/configure --host=x86_64-foxkit-linux-musl --build=x86_64-foxkit-linux-musl --prefix=/usr --bindir=/usr/x86_64-foxkit-linux-musl/gcc-bin/5.4.0 --includedir=/usr/lib/gcc/x86_64-foxkit-linux-musl/5.4.0/include --datadir=/usr/share/gcc-data/x86_64-foxkit-linux-musl/5.4.0 --mandir=/usr/share/gcc-data/x86_64-foxkit-linux-musl/5.4.0/man --infodir=/usr/share/gcc-data/x86_64-foxkit-linux-musl/5.4.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-foxkit-linux-musl/5.4.0/include/g++-v5 --with-python-dir=/share/gcc-data/x86_64-foxkit-linux-musl/5.4.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=http://bts.adelielinux.org/ --with-pkgversion='Adélie 5.4.0-r1 p1.0, pie-0.6.5' --enable-libstdcxx-time --enable-shared --enable-threads=posix --disable-multilib --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --enable-libssp --disable-libcilkrts --disable-libmpx --disable-vtable-verify --disable-libvtv --enable-lto --without-isl --disable-libsanitizer Thread model: posix gcc version 5.4.0 (Adélie 5.4.0-r1 p1.0, pie-0.6.5)
