gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013 --- Comment #5 from Andrey --- Sorry, my fault, spanhttps://eel.is/c++draft/views.span#span.overview-4. It looks strange for me, but of course, it's not a topic for this tracker.
[Bug target/102991] [12 regression] gcc.dg/vect/vect-simd-17.c fails after r12-4757
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102991 --- Comment #3 from luoxhu at gcc dot gnu.org --- (In reply to Kewen Lin from comment #2) > (In reply to luoxhu from comment #1) > > Couldn't reproduce on rain6p1 (P10): > > > > It's weird, I can reproduce this on rain6p1. > > FAIL: gcc.dg/vect/vect-simd-17.c execution test > FAIL: gcc.dg/vect/vect-simd-17.c -flto -ffat-lto-objects execution test > > >--->---=== gcc Summary === > > # of expected passes>--->---2 > # of unexpected failures>---2 > > Probably due to you still specified --with-cpu=power9 instead of > --with-cpu=power10 in gcc configuration? Thanks, confirmed. --with-cpu=power9 doesn't fail on both P9 and P10 with the patch. It aborts at vect-simd-17.c of line 274.
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 --- Comment #45 from Eric Gallager --- (In reply to Martin Liška from comment #0) > [...] > Then I built GCC with -j1 and used following parser to generate reports: > https://github.com/marxin/script-misc/blob/master/parse-make-log.py The new URL for that script is now this, btw: https://github.com/marxin/script-misc/blob/master/legacy/parse-make-log.py
[Bug debug/102955] [12 Regression] ICE with #pragma optimize "0" or attribute optimize and -g -gtoggle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102955 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #11 from Martin Liška --- Mine, thanks for the reduction.
[Bug other/102657] libcody makefile is missing a mostlyclean target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102657 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:7a71ea4df7e97a640e6747d6787a1885eb3bbc40 commit r12-4817-g7a71ea4df7e97a640e6747d6787a1885eb3bbc40 Author: Martin Liska Date: Mon Oct 25 16:32:55 2021 +0200 libcody: add mostlyclean Makefile target PR other/102657 libcody/ChangeLog: * Makefile.in: Add mostlyclean Makefile target.
[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Summary|[12 Regression] ice in |[12 Regression] ice in |vect_normalize_conj_loc, at |vect_normalize_conj_loc, at |tree-vect-slp-patterns.c:72 |tree-vect-slp-patterns.c:72 |2 |2 since ||r12-4785-ged3de62ac949c92ad ||41ef6de7cc926fbb2a510ce Blocks||26163 --- Comment #3 from Martin Liška --- Btw. it affects quite some SPEC benchmarks. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #4 from TC --- I don't think this needs an extra constraint, just reordering the existing ones to check not-a-span (14.3, "remove_cvref_t is not a specialization of span") first. But this is very much undefined anyway.
[Bug c++/102990] ICE in tsubst_copy_and_build with coroutines and concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Keywords|needs-reduction | --- Comment #2 from Andrew Pinski --- Still reducing it, down to 2.2M file
[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016 --- Comment #12 from Han Boetes --- Wow, thanks, let's see if I can manage that.
[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
--- Comment #11 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #10)
> I looked and I see openbsd has a patch which adds fname_as_string to one of
> the generic parts of GCC which is causing this.
> apinski@xeond:~/src/openbsd-ports/lang/gcc/11/patches$ git grep
> fname_as_string
> patch-gcc_ada_adaint_c:+fname_as_string(int pretty_p
> __attribute__((__unused__)))
> patch-gcc_d_d-lang_cc:+fname_as_string(int pretty_p
> __attribute__((__unused__)))
> patch-gcc_fortran_f95-lang_c:+fname_as_string(int pretty_p
> __attribute__((__unused__)))
> patch-gcc_go_go-lang_c:+fname_as_string(int pretty_p
> __attribute__((__unused__)))
> patch-gcc_lto_lto-common_c:+fname_as_string(int pretty_p
> __attribute__((__unused__)))
> patch-gcc_targhooks_c:+ if (NULL == (tmp_name = fname_as_string (0))) {
Basically you need to do a similar patch to the jit sources as was done for
Ada, D, go, and lto front-ends.
[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED |RESOLVED
--- Comment #10 from Andrew Pinski ---
I looked and I see openbsd has a patch which adds fname_as_string to one of the
generic parts of GCC which is causing this.
apinski@xeond:~/src/openbsd-ports/lang/gcc/11/patches$ git grep fname_as_string
patch-gcc_ada_adaint_c:+fname_as_string(int pretty_p
__attribute__((__unused__)))
patch-gcc_d_d-lang_cc:+fname_as_string(int pretty_p
__attribute__((__unused__)))
patch-gcc_fortran_f95-lang_c:+fname_as_string(int pretty_p
__attribute__((__unused__)))
patch-gcc_go_go-lang_c:+fname_as_string(int pretty_p
__attribute__((__unused__)))
patch-gcc_lto_lto-common_c:+fname_as_string(int pretty_p
__attribute__((__unused__)))
patch-gcc_targhooks_c:+ if (NULL == (tmp_name = fname_as_string (0))) {
[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016 --- Comment #9 from Andrew Pinski --- Do you have any patches that gets applied to the gcc sources from say openbsd?
[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016 --- Comment #8 from Han Boetes --- Well that's unexpected… /usr/local/lib % ag -a fname_as_string Binary file libgccjit.so.0.0.1 matches. gcc/x86_64-unknown-openbsd7.0/11.2.0/plugin/include/c-family/c-common.h extern const char *fname_as_string (int); % nm /usr/local/lib/libgccjit.so.0.0.1 W _ITM_RU1 W _ITM_RU8 W _ITM_addUserCommitAction W _ITM_memcpyRnWt W _ITM_memcpyRtWn W _Jv_RegisterClasses U _Z15fname_as_stringi W _ZGTtdlPv W _ZGTtnam U __cxa_atexit W __cxa_finalize W __cxa_pure_virtual U __errno U __gmp_version U __gmpz_add U __gmpz_add_ui U __gmpz_clear U __gmpz_cmp U __gmpz_com U __gmpz_export U __gmpz_fdiv_q U __gmpz_import U __gmpz_init U __gmpz_init_set U __gmpz_out_str U __gmpz_set U __gmpz_set_ui U __gmpz_sizeinbase U __gmpz_sub U __gmpz_sub_ui U __gmpz_swap U __isthreaded U __sF U __srget U __stack_smash_handler U __swbuf U _ctype_ U _exit W _thread_atfork U _tolower_tab_ U abort U access U asctime U atoi U bsearch U calloc U close U closedir U deflate U deflateEnd U deflateInit_ U dl_iterate_phdr U dlclose U dlerror U dlopen U dlsym U dup2 U environ U execv U execvp U exit U fchmod U fclose U fcntl U fdopen U feof U ferror U fflush U fgetc U fgets U fileno U fopen U fprintf U fputc U fputs U fread U free U freopen U fseek U fstat U ftell U fwrite 00918140 T gcc_jit_block_add_assignment 00918350 T gcc_jit_block_add_assignment_op 00918880 T gcc_jit_block_add_comment 00917f80 T gcc_jit_block_add_eval 0091ad30 T gcc_jit_block_add_extended_asm 00915360 T gcc_jit_block_as_object 009185a0 T gcc_jit_block_end_with_conditional 0091ae80 T gcc_jit_block_end_with_extended_asm_goto 00918a20 T gcc_jit_block_end_with_jump 00918c00 T gcc_jit_block_end_with_return 0091bd20 T gcc_jit_block_end_with_switch 00918e00 T gcc_jit_block_end_with_void_return 009153b0 T gcc_jit_block_get_function 00918ff0 T gcc_jit_case_as_object 009134b0 T gcc_jit_context_acquire 00919510 T gcc_jit_context_add_command_line_option 00919630 T gcc_jit_context_add_driver_option 0091b480 T gcc_jit_context_add_top_level_asm 00919840 T gcc_jit_context_compile 00919960 T gcc_jit_context_compile_to_file 00919d30 T gcc_jit_context_dump_reproducer_to_file 00919ac0 T gcc_jit_context_dump_to_file 00919750 T gcc_jit_context_enable_dump 00914ec0 T gcc_jit_context_get_builtin_function 00919e50 T gcc_jit_context_get_first_error 00913980 T gcc_jit_context_get_int_type 00919f10 T gcc_jit_context_get_last_error 0091a330 T gcc_jit_context_get_timer 009138a0 T gcc_jit_context_get_type 00917370 T gcc_jit_context_new_array_access 00913b30 T gcc_jit_context_new_array_type 00916600 T gcc_jit_context_new_binary_op 00913e30 T gcc_jit_context_new_bitfield 00916a80 T gcc_jit_context_new_call 00916d60 T gcc_jit_context_new_call_through_ptr 0091b5c0 T gcc_jit_context_new_case 00917110 T gcc_jit_context_new_cast 009135e0 T gcc_jit_context_new_child_context 009168b0 T gcc_jit_context_new_comparison 00913c80 T gcc_jit_context_new_field 00914bd0 T gcc_jit_context_new_function 009147c0 T gcc_jit_context_new_function_ptr_type 009153f0 T gcc_jit_context_new_global 00913710 T gcc_jit_context_new_location 00914280 T gcc_jit_context_new_opaque_struct 009149a0 T gcc_jit_context_new_param 00915ec0 T gcc_jit_context_new_rvalue_from_double 009158f0 T gcc_jit_context_new_rvalue_from_int 00915a80 T gcc_jit_context_new_rvalue_from_long 00916050 T gcc_jit_context_new_rvalue_from_ptr 0091a990 T gcc_jit_context_new_rvalue_from_vector 00916310 T gcc_jit_context_new_string_literal 00914090 T gcc_jit_context_new_struct_type 00916400 T gcc_jit_context_new_unary_op 009145d0 T gcc_jit_context_new_union_type 009161e0 T gcc_jit_context_null 00915d60 T gcc_jit_context_one 009134f0 T gcc_jit_context_release 009193a0 T gcc_jit_context_set_bool_allow_unreachable_blocks 009192e0 T gcc_jit_context_set_bool_option 00919450 T gcc_jit_context_set_bool_use_external_driver 00919220 T gcc_jit_context_set_int_option 00919c00 T gcc_jit_context_set_logfile 00919160 T gcc_jit_context_set_str_option 0091a2e0 T gcc_jit_context_set_timer 00915c10 T gcc_jit_context_zero 0091b350 T gcc_jit_extended_asm_add_clobber 0091b230 T gcc_jit_extended_asm_add_input_operand 0091b0f0 T gcc_jit_extended_asm_add_output_operand 0091b040 T gcc_jit_
[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016 --- Comment #7 from Andrew Pinski --- Can you post the output of "nm /usr/local/lib/libgccjit.so.0.0.1"?
[Bug d/102837] [12 regression] Many 32-bit gdc tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Iain Buclaw --- Fix committed.
[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016 --- Comment #6 from Han Boetes --- So this is what I did: % export LD_DEBUG=yes % /usr/pkgmk/work/emacs/src/emacs/lisp % ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -l comp -f batch-byte+native- compile international/titdic-cnv.el > output 2>&1 And here is the output: ld.so loading: 'bootstrap-emacs' exe load offset: 0x60f1c0be000 flags ../src/bootstrap-emacs = 0x800 head ../src/bootstrap-emacs obj ../src/bootstrap-emacs has ../src/bootstrap-emacs as head examining: '../src/bootstrap-emacs' loading: libgmp.so.11.0 required by ../src/bootstrap-emacs flags /usr/local/lib/libgmp.so.11.0 = 0x0 obj /usr/local/lib/libgmp.so.11.0 has ../src/bootstrap-emacs as head loading: libpthread.so.26.1 required by ../src/bootstrap-emacs flags /usr/lib/libpthread.so.26.1 = 0x8 obj /usr/lib/libpthread.so.26.1 has ../src/bootstrap-emacs as head loading: libxml2.so.17.0 required by ../src/bootstrap-emacs flags /usr/local/lib/libxml2.so.17.0 = 0x0 obj /usr/local/lib/libxml2.so.17.0 has ../src/bootstrap-emacs as head loading: libc.so.96.1 required by ../src/bootstrap-emacs flags /usr/lib/libc.so.96.1 = 0x21 obj /usr/lib/libc.so.96.1 has ../src/bootstrap-emacs as head loading: libgccjit.so.0 required by ../src/bootstrap-emacs flags /usr/local/lib/libgccjit.so.0.0.1 = 0x0 obj /usr/local/lib/libgccjit.so.0.0.1 has ../src/bootstrap-emacs as head loading: libcurses.so.14.0 required by ../src/bootstrap-emacs flags /usr/lib/libcurses.so.14.0 = 0x0 obj /usr/lib/libcurses.so.14.0 has ../src/bootstrap-emacs as head loading: liblcms2.so.1.4 required by ../src/bootstrap-emacs flags /usr/local/lib/liblcms2.so.1.4 = 0x0 obj /usr/local/lib/liblcms2.so.1.4 has ../src/bootstrap-emacs as head loading: libexecinfo.so.3.0 required by ../src/bootstrap-emacs flags /usr/lib/libexecinfo.so.3.0 = 0x0 obj /usr/lib/libexecinfo.so.3.0 has ../src/bootstrap-emacs as head loading: libdbus-1.so.11.2 required by ../src/bootstrap-emacs flags /usr/local/lib/libdbus-1.so.11.2 = 0x0 obj /usr/local/lib/libdbus-1.so.11.2 has ../src/bootstrap-emacs as head loading: libossaudio.so.4.0 required by ../src/bootstrap-emacs flags /usr/lib/libossaudio.so.4.0 = 0x0 obj /usr/lib/libossaudio.so.4.0 has ../src/bootstrap-emacs as head loading: libjansson.so.4.1 required by ../src/bootstrap-emacs flags /usr/local/lib/libjansson.so.4.1 = 0x0 obj /usr/local/lib/libjansson.so.4.1 has ../src/bootstrap-emacs as head loading: libm.so.10.1 required by ../src/bootstrap-emacs flags /usr/lib/libm.so.10.1 = 0x0 obj /usr/lib/libm.so.10.1 has ../src/bootstrap-emacs as head loading: libz.so.6.0 required by ../src/bootstrap-emacs flags /usr/lib/libz.so.6.0 = 0x0 obj /usr/lib/libz.so.6.0 has ../src/bootstrap-emacs as head loading: libgnutls.so.47.1 required by ../src/bootstrap-emacs flags /usr/local/lib/libgnutls.so.47.1 = 0x0 obj /usr/local/lib/libgnutls.so.47.1 has ../src/bootstrap-emacs as head linking dep /usr/lib/libossaudio.so.4.0 as child of ../src/bootstrap-emacs linking dep /usr/local/lib/libdbus-1.so.11.2 as child of ../src/bootstrap-emacs linking dep /usr/lib/libexecinfo.so.3.0 as child of ../src/bootstrap-emacs linking dep /usr/local/lib/libxml2.so.17.0 as child of ../src/bootstrap-emacs linking dep /usr/lib/libcurses.so.14.0 as child of ../src/bootstrap-emacs linking dep /usr/local/lib/libgnutls.so.47.1 as child of ../src/bootstrap-emacs objname /usr/lib/libpthread.so.26.1 is nodelete linking dep /usr/lib/libpthread.so.26.1 as child of ../src/bootstrap-emacs linking dep /usr/local/lib/liblcms2.so.1.4 as child of ../src/bootstrap-emacs linking dep /usr/lib/libm.so.10.1 as child of ../src/bootstrap-emacs linking dep /usr/lib/libz.so.6.0 as child of ../src/bootstrap-emacs linking dep /usr/local/lib/libjansson.so.4.1 as child of ../src/bootstrap-emacs linking dep /usr/local/lib/libgmp.so.11.0 as child of ../src/bootstrap-emacs linking dep /usr/local/lib/libgccjit.so.0.0.1 as child of ../src/bootstrap-emacs linking dep /usr/lib/libc.so.96.1 as child of ../src/bootstrap-emacs examining: '/usr/lib/libossaudio.so.4.0' examining: '/usr/local/lib/libdbus-1.so.11.2' loading: libexecinfo.so.3.0 required by /usr/local/lib/libdbus-1.so.11.2 loading: libpthread.so.26.1 required by /usr/local/lib/libdbus-1.so.11.2 linking dep /usr/lib/libpthread.so.26.1 as child of /usr/local/lib/libdbus-1.so.11.2 linking dep /usr/lib/libexecinfo.so.3.0 as child of /usr/local/lib/libdbus-1.so.11.2 examining: '/usr/lib/libexecinfo.so.3.0' examining: '/usr/local/lib/libxml2.so.17.0' loading: libm.so.10.1 required by /usr/local/lib/libxml2.so.17.0 loading: libiconv.so.7.0 required by /usr/local/lib/libxml2.so.17.0 flags /usr/local/lib/libiconv.so.7.0 = 0x0 obj /usr/local/lib/libiconv.so.7.0 has ../src/bootstrap-emacs as head loading: libpthread.so.26.1 required by /usr/local/lib/libxml2.so.17.0 loading: liblzma.so.2.1 required by /usr/local/lib/libxml2.so.17.0 flags /usr/local/lib/liblzma.so
[Bug fortran/102715] [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8184 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102715 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-October/056904.html
[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016 --- Comment #5 from David Malcolm --- (In reply to David Malcolm from comment #4) > Hopefully that will give a hint as to where that symbol is coming from. ...or, rather, where the *usage* of that symbol is coming from.
[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016 --- Comment #4 from David Malcolm --- I'm not sure how best to debug this. $ echo _Z15fname_as_stringi | c++filt fname_as_string(int) and indeed, that seems to be just for the C/C++ frontends, not for libgccjit. Some ideas: Given: bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi' ld.so: bootstrap-emacs: lazy binding failed! ...it appears to be an issue with dynamic linkage. You could try turning up the verbosity of the dynamic linker; if it's glibc you could try setting LD_DEBUG=all in the environment, which I believe is the most verbose option (see "man ld.so" for other options, if that's overkill). Hopefully that will give a hint as to where that symbol is coming from. If that doesn't help, is there a way to figure out what the command line is at the point of failure, and what it's trying to do?
[Bug d/102959] gdc.dg/torture/pr96435.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102959 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Buclaw --- Fix committed.
[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016 --- Comment #3 from Han Boetes --- I've just grepped the Emacs code for 'fname_as_string' and it isn't in there either.
[Bug c/102939] Ridiculously long compilation times on (admittedly itself ridiculous) pointer declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #3 from Hans-Peter Nilsson --- (In reply to Gabriel Ravier from comment #0) ... > #define PTR4 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 > #define PTR5 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 > #define PTR6 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 > > int PTR4 q3_var = 0; ... Is the use of PTR4 instead of PTR6 or PTR5, intended to provoke comments such as this one, or are there untold additional related observations?
[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016 --- Comment #2 from Andrew Pinski --- gcc/ChangeLog-2001: (fname_as_string): Likewise. gcc/ChangeLog-2001: (fname_as_string): New function from remnants of gcc/ChangeLog-2003: * c-common.c (fname_as_string): Use lang_hooks.decl_printable_name gcc/ChangeLog-2004: * c-common.c (fname_as_string): Free namep if we are returning gcc/ChangeLog-2004: * c-common.c (fname_as_string): Fix xcalloc to xmalloc. gcc/ChangeLog-2004: fname_as_string. gcc/ChangeLog-2004: fname_as_string. gcc/ChangeLog-2004: * c-common.c (fname_as_string): Translate if necessary. gcc/ChangeLog-2004: * c-common.c (fname_as_string, c_common_truthvalue_conversion, gcc/ChangeLog-2007: * c-common.c (fname_as_string): Update. gcc/ChangeLog-2007: * c-common.c (fname_as_string, c_type_hash): Constify. gcc/ChangeLog-2008: (fname_as_string): Match updated cpp_interpret_string prototype. gcc/c-family/ChangeLog: * c-common.c (fname_as_string): Use cxx_printable_name for gcc/c-family/c-common.c:fname_as_string (int pretty_p) gcc/c-family/c-common.h:extern const char *fname_as_string (int); gcc/c/c-decl.c: const char *name = fname_as_string (type_dep); gcc/cp/ChangeLog-2004: fname_as_string. gcc/cp/decl.c:name = fname_as_string (type_dep); There should be no reference to fname_as_string in libgccjit at all ...
[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016 --- Comment #1 from Andrew Pinski --- fname_as_string is only defined in the C/C++ front-ends ... c-family/ChangeLog: * c-common.c (fname_as_string): Use cxx_printable_name for c-family/c-common.c:fname_as_string (int pretty_p) c-family/c-common.h:extern const char *fname_as_string (int); c/c-decl.c: const char *name = fname_as_string (type_dep); cp/ChangeLog-2004: fname_as_string. cp/decl.c:name = fname_as_string (type_dep);
[Bug jit/103016] New: libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016 Bug ID: 103016 Summary: libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi' Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: hboetes at gmail dot com Target Milestone: --- I already reported this bug to the Emacs bug list and Eli Zaretskii, the Emacs maintainer, insisted it was an issue with GCC. Please bear with me, since this is not a normal bug-report. Whilst compiling Emacs with the --with-native-compilation, which uses libgccjit, I ran into the following issue: gmake[2]: Entering directory '/usr/obj/work/emacs/src/emacs/lisp' ELC+ELN international/titdic-cnv.elc bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi' ld.so: bootstrap-emacs: lazy binding failed! Killed gmake[2]: *** [Makefile:316: international/titdic-cnv.elc] Error 137 gmake[2]: Leaving directory '/usr/obj/work/emacs/src/emacs/lisp' gmake[1]: *** [Makefile:835: ../lisp/loaddefs.el] Error 2 gmake[1]: Leaving directory '/usr/obj/work/emacs/src/emacs/src' gmake: *** [Makefile:450: src] Error 2 Since OpenBSD ports & packages does not yet include libgccjit I modified the port (instructions to build a package) to include the required options as per https://gcc.gnu.org/onlinedocs/gcc-11.2.0/jit/internals/index.html, bootstrapped GCC and, got a package with libgccjit. % egcc --version egcc (GCC) 11.2.0 The OpenBSD version is: 7.0-amd64 How can I help debugging this problem? Thanks, Han
[Bug tree-optimization/102943] [12 Regression] VRP threader compile-time hog with 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943 --- Comment #7 from Jan Hubicka --- this is compile time plot https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=227.270.8 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=289.270.8 (-O2 and -Ofast with lto) Things has improved but build times are still a lot worse than before.
[Bug target/103008] poor inlined builtin_fmod on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-10-31
Ever confirmed|0 |1
--- Comment #6 from Uroš Bizjak ---
Please see PR29852. The only way to avoid the libcall in 2006 was to inline the
x87 version also for SSE math. Nowadays a (generic) arithmetic sequence can be
provided and x87 fmod builtins can be enabled for x87 math only with:
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index e733a40fc90..ed818232ae7 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -17378,6 +17378,8 @@
(use (match_operand:MODEF 1 "general_operand"))
(use (match_operand:MODEF 2 "general_operand"))]
"TARGET_USE_FANCY_MATH_387
+ && (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
+ || TARGET_MIX_SSE_I387)
&& flag_finite_math_only"
{
rtx (*gen_truncxf) (rtx, rtx);
[Bug fortran/101337] gfortran doesn't diagnose all operands with constraint violations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337 Bernhard Reutner-Fischer changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-October ||/582983.html CC||aldot at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-31 --- Comment #2 from Bernhard Reutner-Fischer --- confirmed
[Bug d/102837] [12 regression] Many 32-bit gdc tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837 --- Comment #6 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:d41092ec52f46d2f4b08fff8d1519e50354331b0 commit r12-4813-gd41092ec52f46d2f4b08fff8d1519e50354331b0 Author: Iain Buclaw Date: Sun Oct 31 18:07:16 2021 +0100 d: Fix regressing test failures on ix86-solaris2.11 The _Unwind_Exception struct had its alignment adjusted to 16-bytes, however malloc() on Solaris X86 is not guaranteed to allocate memory aligned to 16-bytes as well. PR d/102837 libphobos/ChangeLog: * libdruntime/gcc/deh.d (ExceptionHeader.free): Use memset to reset contents of internal EH storage.
[Bug d/102959] gdc.dg/torture/pr96435.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102959 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:1b5f73858412731bb2e821bdf0fc85d6cc012d33 commit r12-4812-g1b5f73858412731bb2e821bdf0fc85d6cc012d33 Author: Iain Buclaw Date: Sun Oct 31 16:49:33 2021 +0100 d: Fix pr96435.d failing on SPARC and HPPA The value used to initialize the integer field in the union didn't account for BigEndian targets running this code. PR d/102959 gcc/testsuite/ChangeLog: * gdc.dg/torture/pr96435.d: Adjust for BigEndian.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013 --- Comment #3 from Jonathan Wakely --- And libstdc++ has exactly the constraints required by the C++ draft. I suggest reporting this as an LWG defect.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013 --- Comment #2 from Jonathan Wakely --- According to the standard, span is undefined behaviour, see the last bullet of [res.on.functions].
[Bug fortran/100991] [OpenMP] firstprivate for optional arguments is mishandled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100991 Bernhard Reutner-Fischer changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||aldot at gcc dot gnu.org Last reconfirmed||2021-10-31
[Bug fortran/100972] Missing error with "implicit none (external)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100972 Bernhard Reutner-Fischer changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||patch Last reconfirmed||2021-10-31 CC||aldot at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-October ||/582979.html --- Comment #2 from Bernhard Reutner-Fischer --- Confirmed
[Bug fortran/99884] Double spaces in warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99884 Bernhard Reutner-Fischer changed: What|Removed |Added Keywords||patch Ever confirmed|0 |1 Last reconfirmed||2021-10-31 CC||aldot at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-October ||/582974.html Status|UNCONFIRMED |NEW --- Comment #1 from Bernhard Reutner-Fischer --- Confirmed.
[Bug target/103015] [pentium4][solaris] Segmentation fault loading pointer to TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103015 --- Comment #3 from Iain Buclaw --- (In reply to Andrew Pinski from comment #2) > Are you using Solaris's ld or as? Or what version of binutils are you using? > Yes it does matter here. Configured gcc --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as ld version: Solaris Link Editors: 5.11-1.3159 as version: GNU Binutils: 2.30
[Bug ada/103014] [11/12 Regression] gnat1 segfaults in tree_could_trap_p when C double parameter, -O2 -gnatn -gnatVa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103014 Andrew Pinski changed: What|Removed |Added Summary|gnat1 segfaults in |[11/12 Regression] gnat1 |tree_could_trap_p when C|segfaults in |double parameter, -O2 |tree_could_trap_p when C |-gnatn -gnatVa |double parameter, -O2 ||-gnatn -gnatVa Target Milestone|--- |11.3 Keywords||ice-on-valid-code
[Bug target/103015] [pentium4][solaris] Segmentation fault loading pointer to TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103015 --- Comment #2 from Andrew Pinski --- Are you using Solaris's ld or as? Or what version of binutils are you using? Yes it does matter here.
[Bug c++/102975] Local alias diagnosed as unused when used in failing constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102975 --- Comment #4 from Johel Ernesto Guerrero Peña --- I'm fine with closing this as RESOLVED INVALID or something along those lines.
[Bug c++/102975] Local alias diagnosed as unused when used in failing constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102975
--- Comment #3 from Patrick Palka ---
(In reply to Patrick Palka from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Hmm, this is interesting:
> > template concept Never = false;
> > template concept C = Never;
> > void f() {
> > struct X {
> >// using type = int;
> > };
> > static_assert(not C);
> > }
> >
> > is able to compile. I don't know enough about C++ concepts to say if this is
> > valid or not but it looks like the type is really unused in the above case
> > ...
> > This is different from "constexpr bool" which requires the type to be
> > defined ...
>
> Yeah, when evaluating a concept-id such as C (which is done by
> substituting {X} into the normal form of C), the normalization process
> (https://eel.is/c++draft/temp.constr.normal) ignores arguments to unused
> template parameters.
>
> So since 'Never' doesn't use its template parameter, during normalization of
> C we discard the template argument 'typename T::type' passed to Never. The
> normal form of C ends up being 'false (with empty parameter mapping)' which
> is trivially satisfied for all T.
... trivially _unsatisfied_ rather
[Bug c++/102975] Local alias diagnosed as unused when used in failing constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102975
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #2 from Patrick Palka ---
(In reply to Andrew Pinski from comment #1)
> Hmm, this is interesting:
> template concept Never = false;
> template concept C = Never;
> void f() {
> struct X {
>// using type = int;
> };
> static_assert(not C);
> }
>
> is able to compile. I don't know enough about C++ concepts to say if this is
> valid or not but it looks like the type is really unused in the above case
> ...
> This is different from "constexpr bool" which requires the type to be
> defined ...
Yeah, when evaluating a concept-id such as C (which is done by substituting
{X} into the normal form of C), the normalization process
(https://eel.is/c++draft/temp.constr.normal) ignores arguments to unused
template parameters.
So since 'Never' doesn't use its template parameter, during normalization of C
we discard the template argument 'typename T::type' passed to Never. The
normal form of C ends up being 'false (with empty parameter mapping)' which is
trivially satisfied for all T. So it seems to me the warning is correct since
evaluating C doesn't actually use X::type, and the alias is never otherwise
used.
(If this discarding unused template parameters of a concept is undesirable, one
can define the concept in question in a way that trivially uses its template
parameter, e.g.:
template concept Never = requires { typename T; } && false;)
[Bug c/103015] [i386][solaris] Segmentation fault loading pointer to TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103015 --- Comment #1 from Iain Buclaw --- The specific CPU config options of -m32 are: -mcpu=generic -march=pentium4 -mtune=generic
[Bug c/103015] New: [i386][solaris] Segmentation fault loading pointer to TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103015
Bug ID: 103015
Summary: [i386][solaris] Segmentation fault loading pointer to
TLS
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Translation of D test gdc.test/runnable/testv.d that segfaults when compiled
with -O2, and linking libraries in dynamically.
---
// Compiled with -m32 -O2
int printf(const char*, ...);
_Thread_local int a1[2] = {5,6};
_Thread_local int a2[3] = {5,6,7};
_Thread_local int a3[4] = {5,6,7,8};
int sum3(int* xx, int length)
{
int s = 0;
for (int i = 0; i < length; i++)
{
int x = xx[i];
s += x;
}
return s;
}
int main()
{
printf("%d\n", sum3(a3, sizeof(a3) / sizeof(a3[0])));
return 0;
}
---
---
Dump of assembler code for function main:
0x08050c60 <+0>: lea0x4(%esp),%ecx
0x08050c64 <+4>: and$0xfff0,%esp
0x08050c67 <+7>: pushl -0x4(%ecx)
0x08050c6a <+10>:push %ebp
0x08050c6b <+11>:mov%esp,%ebp
0x08050c6d <+13>:push %ecx
0x08050c6e <+14>:sub$0xc,%esp
0x08050c71 <+17>:mov%gs:0x0,%eax
0x08050c77 <+23>:lea-0x4(%esp),%esp
=> 0x08050c7b <+27>:movdqa -0x28(%eax),%xmm0
0x08050c83 <+35>:movdqa %xmm0,%xmm1
0x08050c87 <+39>:psrldq $0x8,%xmm1
0x08050c8c <+44>:paddd %xmm1,%xmm0
0x08050c90 <+48>:movdqa %xmm0,%xmm1
0x08050c94 <+52>:psrldq $0x4,%xmm1
0x08050c99 <+57>:paddd %xmm1,%xmm0
0x08050c9d <+61>:movd %xmm0,(%esp)
0x08050ca2 <+66>:push $0x80509f8
0x08050ca7 <+71>:call 0x8050a4c
0x08050cac <+76>:mov-0x4(%ebp),%ecx
0x08050caf <+79>:add$0x10,%esp
0x08050cb2 <+82>:xor%eax,%eax
0x08050cb4 <+84>:leave
0x08050cb5 <+85>:lea-0x4(%ecx),%esp
0x08050cb8 <+88>:ret
End of assembler dump.
---
[Bug ada/103014] New: gnat1 segfaults in tree_could_trap_p when C double parameter, -O2 -gnatn -gnatVa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103014
Bug ID: 103014
Summary: gnat1 segfaults in tree_could_trap_p when C double
parameter, -O2 -gnatn -gnatVa
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: nicolas at debian dot org
Target Milestone: ---
Hello.
The following valid Ada sources crash 'gcc-11 -O2 -gnatn -gnatVa' as shown
below.
All goes well with gcc-10, with -O1, without inlining or without validity
checks.
The tests have been performed on Debian/x86_64-linux-gnu, with gcc-11/11.2.0-10
and gcc-10/10.3.12.
cat > p.ads < p.adb < {heap 2040k} {heap 2040k}
{heap 2040k} {heap 2040k} {heap 2936k}
{heap 2936k} {heap 2936k}Streaming LTO
{heap 2936k} {heap 2936k} {heap 2936k}
{heap 2936k} {heap 2936k} {heap 2936k} {heap
2936k} {heap 2936k} {heap 2936k} {heap 2936k}
{heap 2936k} {heap 2936k} {heap 2936k}
{heap 2936k}Assembling functions:
{heap 2936k} P.P3
Program received signal SIGSEGV, Segmentation fault.
0x0119a4f6 in tree_could_trap_p(tree_node*) ()
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013 --- Comment #1 from Andrey --- Sorry, the first link to godbolt in the starter message is wrong, it should be https://gcc.godbolt.org/z/jWeqs6cM4.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013 Bug ID: 103013 Summary: Underconstrained constructor span(_Range&&) Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: andrey.davydov at jetbrains dot com Target Milestone: --- During calculation of type trait `is_move_constructible` span constructor from `_Range &&` is checked and concept `contiguous_range>` instantiated. It requires T to be complete type (https://gcc.godbolt.org/z/fYWa3KdTs). It means that `optional>` couldn't be instantiated (https://gcc.godbolt.org/z/1PWdE4YK3). This issue could be solved if make the constructor span(_Range&&) more constrained, something like this: template requires (!__is_same(_Range, span)) && ... span(_Range&& __range);
[Bug c++/103012] ICE with #pragma GCC optimize followed by long line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103012 --- Comment #2 from Andrew Pinski --- Someone else has to reduce the testcase and such. I found this while trying to reduce PR 102990.
[Bug c++/103012] ICE with #pragma GCC optimize followed by long line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103012 --- Comment #1 from Andrew Pinski --- Created attachment 51714 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51714&action=edit testcase
[Bug c++/103012] New: ICE with #pragma GCC optimize followed by long line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103012
Bug ID: 103012
Summary: ICE with #pragma GCC optimize followed by long line
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
t0.cc:1:26: internal compiler error: in linemap_add, at libcpp/line-map.c:502
1 | #pragma GCC optimize("Og")
| ^
0x2094272 linemap_add(line_maps*, lc_reason, unsigned int, char const*,
unsigned int)
/home/apinski/src/upstream-gcc/gcc/libcpp/line-map.c:502
0x2094486 linemap_line_start(line_maps*, unsigned int, unsigned int)
/home/apinski/src/upstream-gcc/gcc/libcpp/line-map.c:827
0x2094798 linemap_position_for_column(line_maps*, unsigned int)
/home/apinski/src/upstream-gcc/gcc/libcpp/line-map.c:898
0x208fd00 _cpp_lex_direct
/home/apinski/src/upstream-gcc/gcc/libcpp/lex.c:2994
0x2091670 _cpp_lex_token
/home/apinski/src/upstream-gcc/gcc/libcpp/lex.c:2810
0x207fddf lex_macro_node
/home/apinski/src/upstream-gcc/gcc/libcpp/directives.c:601
0x20805a2 do_define
/home/apinski/src/upstream-gcc/gcc/libcpp/directives.c:639
0x20836ef run_directive
/home/apinski/src/upstream-gcc/gcc/libcpp/directives.c:589
0x20837a7 cpp_define(cpp_reader*, char const*)
/home/apinski/src/upstream-gcc/gcc/libcpp/directives.c:2511
0x20837fb cpp_define_unused(cpp_reader*, char const*)
/home/apinski/src/upstream-gcc/gcc/libcpp/directives.c:2520
0xc7a234 c_cpp_builtins_optimize_pragma(cpp_reader*, tree_node*, tree_node*)
/home/apinski/src/upstream-gcc/gcc/gcc/c-family/c-cppbuiltin.c:600
0xc9c8e3 handle_pragma_optimize
/home/apinski/src/upstream-gcc/gcc/gcc/c-family/c-pragma.c:997
0xb35c40 cp_parser_pragma
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:47773
0xb6cbfb cp_parser_toplevel_declaration
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:14852
0xb6cbfb cp_parser_toplevel_declaration
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:14843
0xb6cbfb cp_parser_translation_unit
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:4987
0xb6cbfb c_parse_file()
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:47832
0xc9a5ed c_common_parse_file()
/home/apinski/src/upstream-gcc/gcc/gcc/c-family/c-opts.c:1237
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/102990] ICE in tsubst_copy_and_build, à cp/pt.c:19856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990 --- Comment #1 from Andrew Pinski --- Reducing.
[Bug d/102959] gdc.dg/torture/pr96435.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102959
--- Comment #1 from Iain Buclaw ---
(In reply to Rainer Orth from comment #0)
> (gdb) p array
> $2 = {16, 678}
> (gdb) p u
> $3 = {i = 0, b = false}
> (gdb) n
> 9 u.i = 0xDEADBEEF;
> (gdb) n
> 10assert(array[u.b] == 678);
> (gdb) p u
> $4 = {i = -559038737, b = 222}
> (gdb) p/x u.i
> $7 = 0xdeadbeef
OK, so the test didn't account for endianess. Will adjust the value or add a
version condition for BigEndian to assert the value is the other index.
[Bug libbacktrace/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011 --- Comment #3 from cqwrteur --- compilation succeeded when comment out process.h. HAVE_PROCESS_H does not make sense tbh. Actually #if __has_include() can replace all headers. Are you trying to support old versions' compilers by not using __has_include guard? but it is still weird, shouldn't that be pex-win32.h??
[Bug libbacktrace/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011 --- Comment #2 from cqwrteur --- Probably because of this that breaks compilation https://github.com/gcc-mirror/gcc/commit/c3e80a16af287e804b87b8015307085399755cd4#diff-6499efb534d0a9459d3af89fe12f0ee024636b275addb16130c9dbe6c5c3dda9
