[Bug testsuite/94763] New: UNRESOLVED scan assembler tests on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94763 Bug ID: 94763 Summary: UNRESOLVED scan assembler tests on arm-none-eabi Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vvinayag at arm dot com Target Milestone: --- Many tests are UNRESOLVED on arm-none-eabi. UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++14 scan-assembler _Z1fB3barB3fooi UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++14 scan-assembler _Z1gB3baz1AB3bar UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++17 scan-assembler _Z1fB3barB3fooi UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++17 scan-assembler _Z1gB3baz1AB3bar UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++2a scan-assembler _Z1fB3barB3fooi UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++2a scan-assembler _Z1gB3baz1AB3bar UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++98 scan-assembler _Z1fB3barB3fooi UNRESOLVED: g++.dg/abi/abi-tag1.C -std=gnu++98 scan-assembler _Z1gB3baz1AB3bar UNRESOLVED: g++.dg/abi/abi-tag10.C -std=c++14 scan-assembler _ZNK4hashI12basic_stringB5cxx11Ic11char_traitsIcE9allocatorIcEEEclES5_ UNRESOLVED: g++.dg/abi/abi-tag10.C -std=c++17 scan-assembler _ZNK4hashI12basic_stringB5cxx11Ic11char_traitsIcE9allocatorIcEEEclES5_ UNRESOLVED: g++.dg/abi/abi-tag10.C -std=c++2a scan-assembler _ZNK4hashI12basic_stringB5cxx11Ic11char_traitsIcE9allocatorIcEEEclES5_ UNRESOLVED: g++.dg/abi/abi-tag10.C -std=c++98 scan-assembler _ZNK4hashI12basic_stringB5cxx11Ic11char_traitsIcE9allocatorIcEEEclES5_ UNRESOLVED: g++.dg/abi/abi-tag11.C -std=c++14 scan-assembler _Z1fSbB3fooIwSt11char_traitsIwESaIwEES3_ UNRESOLVED: g++.dg/abi/abi-tag11.C -std=c++17 scan-assembler _Z1fSbB3fooIwSt11char_traitsIwESaIwEES3_ UNRESOLVED: g++.dg/abi/abi-tag11.C -std=c++2a scan-assembler _Z1fSbB3fooIwSt11char_traitsIwESaIwEES3_ UNRESOLVED: g++.dg/abi/abi-tag11.C -std=c++98 scan-assembler _Z1fSbB3fooIwSt11char_traitsIwESaIwEES3_ UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++14 scan-assembler _Z1aB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++14 scan-assembler _Z1fB5cxx11v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++14 scan-assembler _Z1fPN7__cxx111AE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++14 scan-assembler _Z1gIN7__cxx111AEET_v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++14 scan-assembler _Z1vIN7__cxx111AEE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++17 scan-assembler _Z1aB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++17 scan-assembler _Z1fB5cxx11v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++17 scan-assembler _Z1fPN7__cxx111AE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++17 scan-assembler _Z1gIN7__cxx111AEET_v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++17 scan-assembler _Z1vIN7__cxx111AEE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++2a scan-assembler _Z1aB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++2a scan-assembler _Z1fB5cxx11v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++2a scan-assembler _Z1fPN7__cxx111AE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++2a scan-assembler _Z1gIN7__cxx111AEET_v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++2a scan-assembler _Z1vIN7__cxx111AEE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++98 scan-assembler _Z1aB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++98 scan-assembler _Z1fB5cxx11v UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++98 scan-assembler _Z1fPN7__cxx111AE UNRESOLVED: g++.dg/abi/abi-tag14.C -std=gnu++98 scan-assembler _Z1gIN7__cxx111AEET_v UNRESOLVED: g++.dg/abi/abi-tag16.C -std=gnu++14 scan-assembler _ZGVZN1N1FEvE4NameB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag16.C -std=gnu++17 scan-assembler _ZGVZN1N1FEvE4NameB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag16.C -std=gnu++2a scan-assembler _ZGVZN1N1FEvE4NameB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag16.C -std=gnu++98 scan-assembler _ZGVZN1N1FEvE4NameB5cxx11 UNRESOLVED: g++.dg/abi/abi-tag16a.C -std=gnu++14 scan-assembler _ZGVZN1N1FEvE4Name UNRESOLVED: g++.dg/abi/abi-tag16a.C -std=gnu++17 scan-assembler _ZGVZN1N1FEvE4Name UNRESOLVED: g++.dg/abi/abi-tag16a.C -std=gnu++2a scan-assembler _ZGVZN1N1FEvE4Name UNRESOLVED: g++.dg/abi/abi-tag16a.C -std=gnu++98 scan-assembler _ZGVZN1N1FEvE4Name UNRESOLVED: g++.dg/abi/abi-tag17.C -std=c++14 scan-assembler _Z3fi1B6_X_tagv UNRESOLVED: g++.dg/abi/abi-tag17.C -std=c++17 scan-assembler _Z3fi1B6_X_tagv UNRESOLVED: g++.dg/abi/abi-tag17.C -std=c++2a scan-assembler _Z3fi1B6_X_tagv UNRESOLVED: g++.dg/abi/abi-tag17.C -std=c++98 scan-assembler _Z3fi1B6_X_tagv UNRESOLVED: g++.dg/template/friend56.C -std=c++14 scan-assembler _Z1fv UNRESOLVED: g++.dg/template/friend56.C -std=c++17 scan-assembler _Z1fv UNRESOLVED: g++.dg/template/friend56.C -std=c++2a scan-assembler _Z1fv UNRESOLVED: g++.dg/template/friend56.C -std=c++98 scan-assembler _Z1fv UNRESOLVED: g++.dg/template/linkage1.C -std=c++14 scan
[Bug testsuite/94763] UNRESOLVED scan assembler tests on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94763 --- Comment #2 from vvinayag at arm dot com --- (In reply to Christophe Lyon from comment #1) > How do you configure GCC, and what flags to you use to run the tests? > They work for me, on several configuration of arm-non-eabi-gcc as > cross-compiler. Sorry for the late reply. The tests appear to pass when I invoke them locally. They only failed as part of our buildbot run tests. It could be a glitch in our test system. But I was wondering whether there were any recent changes in the testsuites.
[Bug testsuite/94763] UNRESOLVED scan assembler tests on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94763 vvinayag at arm dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from vvinayag at arm dot com --- (In reply to Christophe Lyon from comment #3) > (In reply to vvinayag from comment #2) > > > Sorry for the late reply. > > The tests appear to pass when I invoke them locally. They only failed as > > part of our buildbot run tests. It could be a glitch in our test system. But > > I was wondering whether there were any recent changes in the testsuites. > > If you still have the .log file, you could check why the tests are > UNRESOLVED, there's probably an error message nearby. Thanks Christophe. I am going to close this as this is not present in the latest build. I will keep a lookout in case this happens again.
[Bug libfortran/95920] New: Implicit declaration of function 'feenableexcept' in fpu-target.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95920 Bug ID: 95920 Summary: Implicit declaration of function 'feenableexcept' in fpu-target.h Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: vvinayag at arm dot com Target Milestone: --- I am seeing these implicit declaration errors when building gcc for arm-none-eabi targets. In file src/gcc/libgfortran/runtime/fpu.c:29 : ./fpu-target.h: In function 'set_fpu_trap_exceptions': ./fpu-target.h:90:3: efedisableexceptrror: implicit declaration of function 'feenableexcept'; did you mean 'feraiseexcept'? [-Werror=implicit-function-declaration] 90 | feenableexcept (mode_set); | ^~ | feraiseexcept ./fpu-target.h:91:3: error: implicit declaration of function 'fedisableexcept'; did you mean 'feraiseexcept'? [-Werror=implicit-function-declaration] 91 | fedisableexcept (mode_clr); | ^~~ | feraiseexcept ./fpu-target.h: In function 'get_fpu_trap_exceptions': ./fpu-target.h:98:20: error: implicit declaration of function 'fegetexcept'; did you mean 'fetestexcept'? [-Werror=implicit-function-declaration] 98 | int exceptions = fegetexcept (); |^~~ |fetestexcept
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #10 from vvinayag at arm dot com --- (In reply to CVS Commits from comment #9) > The master branch has been updated by Ilya Leoshkevich : > > https://gcc.gnu.org/g:d59a576b8b5e12c3a56f0262912090e2921f5daa > > commit r11-1785-gd59a576b8b5e12c3a56f0262912090e2921f5daa > Author: Ilya Leoshkevich > Date: Mon Jun 29 20:36:03 2020 +0200 > > Redefine NULL to nullptr > > Bootstrap with musl libc fails with numerous "missing sentinel in > function call" errors. This is because musl defines NULL as 0L for C++, > but gcc requires sentinel value to be a pointer or __null. > > Jonathan Wakely says: > > To be really safe during stage 1, GCC should not use NULL as a > pointer sentinel in C++ code anyway. > > The bootstrap compiler could define it to 0 or 0u, neither of which > is guaranteed to be OK to pass as a varargs sentinel where a null > pointer is expected. Any of (void*)0 or (void*)NULL or nullptr > would be safe. > > While it is possible to fix this by replacing NULL sentinels with > nullptrs, such approach would generate backporting conflicts, therefore > simply redefine NULL to nullptr at the end of system.h, where it would > not confuse system headers. > > gcc/ChangeLog: > > 2020-06-30 Ilya Leoshkevich > > PR bootstrap/95700 > * system.h (NULL): Redefine to nullptr. I think this patch breaks arm native and aarch64 native builds when compiling gcc/gcc/genmodes.c. gcc/gcc/genmodes.c: In function 'const char* get_mode_class(mode_data*)': gcc/gcc/system.h:1273:14: error: 'nullptr' was not declared in this scope #define NULL nullptr ^ gcc/gcc/genmodes.c:1221:14: note: in expansion of macro 'NULL' return NULL; ^
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 --- Comment #13 from vvinayag at arm dot com --- (In reply to Ilya Leoshkevich from comment #12) > I managed to bootstrap and regtest upstream commit 6e41c27bf549 on gcc113 > farm machine. > > Two questions: > > - What is your system compiler version? For GCC 11, C++11 compiler is > required: https://gcc.gnu.org/install/prerequisites.html > > - What exactly is "native aarch64 build" - is it simply building the > compiler on aarch64, or something else? Sorry for the delayed response: - The system compiler is GCC 4.8.1 (which seems to have experimental support for c++11) - Yes, I meant to say we build the compiler on an aarch64-none-linux-gnu machine.
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 --- Comment #15 from vvinayag at arm dot com --- (In reply to Ilya Leoshkevich from comment #14) > gcc113 has 4.8.4, which is a bit newer. But in any case, according to > https://gcc.gnu.org/projects/cxx-status.html, gcc should support nullptr > since 4.6. > > Could you please post the failing compiler invocation command? > > In the meantime I will build gcc 4.8.1 on gcc113 and try to build master > with it. Hi Ilya Leoshkevich Thanks for your help. The failing compiler command is: g++ -c -DIN_GCC -DGENERATOR_FILE -I. -Ibuild -I/tmp/…/src/gcc/gcc -I/tmp/…/src/gcc/gcc/build -I/tmp/…/src/gcc/gcc/../include -I/tmp/…/src/gcc/gcc/../libcpp/include \ -o build/genmodes.o /tmp/…/src/gcc/gcc/genmodes.c
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 --- Comment #18 from vvinayag at arm dot com --- (In reply to Ilya Leoshkevich from comment #17) > Created attachment 48917 [details] > aarch64 native build fix > > Could you please try the attached patch? It fixed the issue for me, and > survived bootstrap/regtest on x86_64. Hi Ilya, I am testing this patch now. Will update when done. Also, I was a bit incorrect when I mentioned that this is for building the compiler on an aarch64-none-linux-gnu machine. The build machine is actually x86_64. BUILD: x86_64/linux HOST: aarch64-none-linux-gnu TARGET: aarch64-none-linux-gnu Sorry for the confusion.
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 --- Comment #19 from vvinayag at arm dot com --- Created attachment 48921 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48921&action=edit Add -std=c++11 to the aarch64 native build fix This patch adds CXX="$CXX -std=c++11" to the patch provided for the aarch64 native build fix.
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 --- Comment #20 from vvinayag at arm dot com --- (In reply to vvinayag from comment #18) > (In reply to Ilya Leoshkevich from comment #17) > > Created attachment 48917 [details] > > aarch64 native build fix > > > > Could you please try the attached patch? It fixed the issue for me, and > > survived bootstrap/regtest on x86_64. > > Hi Ilya, > > I am testing this patch now. Will update when done. > > Also, I was a bit incorrect when I mentioned that this is for building the > compiler on an aarch64-none-linux-gnu machine. The build machine is actually > x86_64. > BUILD: x86_64/linux > HOST: aarch64-none-linux-gnu > TARGET: aarch64-none-linux-gnu > Sorry for the confusion. The patch did not fix the issue for me, unfortunately, because CXX_FOR_BUILD is still set to 'g++'. But to make it work, I added the line: CXX="$CXX -std=c++11", as shown in the file I have attached. With this additional line in both configure and configure.ac, CXX_FOR_BUILD is set to 'g++ -std=c++11', and the build succeeded for me. However, I do not know whether that is the right solution.
[Bug rtl-optimization/97041] New: ICE during RTL pass: sched_fusion: in operator[], at vec.h:880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97041 Bug ID: 97041 Summary: ICE during RTL pass: sched_fusion: in operator[], at vec.h:880 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vvinayag at arm dot com Target Milestone: --- Internal Compiler Error when compiling glibc/stdio-common/vfprintf-internal.c. The build configuration is: BUILD: x86_64/linux HOST: x86_64/linux TARGET: aarch64-none-linux-gnu OR BUILD: aarch64-none-linux-gnu HOST: aarch64-none-linux-gnu TARGET: aarch64-none-linux-gnu during RTL pass: sched_fusion vfprintf-internal.c: In function ‘__vfprintf_internal’: vfprintf-internal.c:1693:1: internal compiler error: in operator[], at vec.h:880 1693 | } | ^ 0x8136a9 vec::operator[](unsigned int) /src/gcc/gcc/vec.h:880 0x8136a9 pre_and_rev_post_order_compute_fn(function*, int*, int*, bool) /src/gcc/gcc/cfganal.c:1036 0x813790 pre_and_rev_post_order_compute(int*, int*, bool) /src/gcc/gcc/cfganal.c:1050 0x7c27fe init_alias_analysis() /src/gcc/gcc/alias.c:3392 0x18a7416 sched_init() /src/gcc/gcc/haifa-sched.c:7326 0x18a8b50 haifa_sched_init() /src/gcc/gcc/haifa-sched.c:7363 0xcd56bd schedule_insns() /src/gcc/gcc/sched-rgn.c:3514 0xcd5f21 rest_of_handle_sched_fusion /src/gcc/gcc/sched-rgn.c:3757 0xcd5f21 execute /src/gcc/gcc/sched-rgn.c:3932 GCC SHA d9b054d56b052fb01c9a667c95f80c783f0cf0c7 from master
[Bug fortran/92643] ISO_Fortran_binding_15.f90 failure on i586-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92643 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #6 from vvinayag at arm dot com --- Is anyone continuing to investigate or work on a fix for this bug report?
[Bug libstdc++/96029] [8 Regression] Inconsistencies with associative/unordered containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96029 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #9 from vvinayag at arm dot com --- After commit [1] in gcc-10, the following internal compiler error is present: In file included from /build-aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/unordered_map:46, from /src/gcc/libstdc++-v3/include/precompiled/stdc++.h:117: /build-aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/bits/hashtable.h:1317:56: internal compiler error: in merge_exception_specifiers, at cp/typeck2.c:2566 1317 | std::is_nothrow_copy_constructible<_Equal>::value) |^ 0x9b85f8 merge_exception_specifiers(tree_node*, tree_node*) /src/gcc/gcc/cp/typeck2.c:2564 0x99ba1e merge_types(tree_node*, tree_node*) /src/gcc/gcc/cp/typeck.c:874 [1] commit 1c4e8a96cd695c03ff85299bf2392476feae99bb Author: François Dumont AuthorDate: Mon Jan 20 19:15:43 2020 +0100 Commit: Jonathan Wakely CommitDate: Thu Apr 8 17:28:31 2021 +0100 libstdc++: Fix unordered containers move constructors noexcept qualification The build/host/target setup is: Build: x86_64 (Linux) Host: : x86_64 (Linux) Target: arm-none-eabi / arm-none-linux-gnueabi / aarch64-none-elf / aarch64-none-linux-gnu
[Bug c/97447] New: During IPA pass: modref: ICE on gcc.dg/atomic/pr65345-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97447 Bug ID: 97447 Summary: During IPA pass: modref: ICE on gcc.dg/atomic/pr65345-4.c Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vvinayag at arm dot com Target Milestone: --- The test gcc.dg/atomic/pr65345-4.c causes ICE on arm-none-linux-gnueabihf and aarch64-none-linux-gnu. On aarch64-none-linux-gnu: spawn /obj/gcc/gcc/xgcc /src/gcc/gcc/testsuite/gcc.dg/atomic/pr65345-4.c -L/obj/gcc/aarch64-none-linux-gnu/./libatomic/.libs -latomic -fdiagnostics-plain-output -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -S -o pr65345-4.s during IPA pass: modref /src/gcc/gcc/testsuite/gcc.dg/atomic/pr65345-4.c:58:1: internal compiler error: tree code 'ssa_name' is not supported in LTO streams 0xba17d3 lto_write_tree /src/gcc/gcc/lto-streamer-out.c:554 0xba17d3 lto_output_tree_1 /src/gcc/gcc/lto-streamer-out.c:592 0xba9c6f DFS::DFS(output_block*, tree_node*, bool, bool, bool) /src/gcc/gcc/lto-streamer-out.c:892 0xbaaf4f lto_output_tree(output_block*, tree_node*, bool, bool) /src/gcc/gcc/lto-streamer-out.c:1853 0xba07af write_global_stream /src/gcc/gcc/lto-streamer-out.c:2846 0xbadb73 lto_output_decl_state_streams(output_block*, lto_out_decl_state*) /src/gcc/gcc/lto-streamer-out.c:2893 0xbadb73 produce_asm_for_decls() /src/gcc/gcc/lto-streamer-out.c:3287 0xc38cef write_lto /src/gcc/gcc/passes.c:2624 0xc38cef ipa_write_summaries_1 /src/gcc/gcc/passes.c:2685 0xc38cef ipa_write_summaries() /src/gcc/gcc/passes.c:2740 0x899f63 ipa_passes /src/gcc/gcc/cgraphunit.c:2690 0x899f63 symbol_table::compile() /src/gcc/gcc/cgraphunit.c:2777 0x89c59b symbol_table::compile() /src/gcc/gcc/cgraphunit.c:2757 0x89c59b symbol_table::finalize_compilation_unit() /src/gcc/gcc/cgraphunit.c:3022 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. compiler exited with status 1 Build:aarch64-none-linux-gnu Host:aarch64-none-linux-gnu Target:aarch64-none-linux-gnu
[Bug sanitizer/100379] cyclades.h is removed from linux kernel header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #2 from vvinayag at arm dot com --- I can confirm that the missing linux/cyclades.h is breaking cross builds: Build: x86_64 (Linux) Host: x86_64 (Linux) Target: arm-none-linux-gnueabihf / arm-none-linux-gnueabi / aarch64_be-none-linux-gnu / aarch64-none-linux-gnu
[Bug tree-optimization/106878] [11/12 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #13 from vvinayag at arm dot com --- Will this fix be backported to GCC 12 and GCC 11 ?
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #45 from vvinayag at arm dot com --- (In reply to Jonathan Wakely from comment #44) > *** Bug 103570 has been marked as a duplicate of this bug. *** Hi Jonathan, I see that you plan to fix this soon (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103570#c1), and thank you for that. Do you have a rough estimate of when we would see a fix for this? One of our releases depends on a fix for this issue. Kind regards Vasee
[Bug target/100757] [12 Regression] arm: ICE (unrecognizable insn) with MVE VPSELQ_S since r12-834-ga6eacbf10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100757 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #14 from vvinayag at arm dot com --- (In reply to Christophe Lyon from comment #12) > Yes, I've been working on it for a while, it's proving to be a bit tricky > when switching to HImode as suggested by Richard. I have something working, > now checking I haven't broken Neon. Hi Christophe, if you are working on this, just wondering whether we are close to getting a patch for this, thank you.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #29 from vvinayag at arm dot com --- Can we expect a patch for this upstream?
[Bug other/107620] New: Build errors when using sphinx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107620 Bug ID: 107620 Summary: Build errors when using sphinx Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: vvinayag at arm dot com Target Milestone: --- I am noticing errors with use of sphinx when building: Build machine: x86_64-none-linux-gnu Host: x86_64-none-linux-gnu Target: aarch64-none-elf or arm-none-eabi SPHINXBUILD= make[2]: Entering directory '/.../src/gcc/doc' b "html" -d /.../build-aarch64_be-none-elf/obj/gcc2/gcc/doc/fortran/html/doctrees -j auto -q /.../src/gcc/gcc/fortran/doc/gfortran "/.../build-aarch64_be-none-elf/obj/gcc2/gcc/doc/fortran/html/html" /bin/sh: b: command not found make[2]: [Makefile:96: html] Error 127 (ignored) make[2]: Leaving directory '/.../src/gcc/doc' test -z "/.../build-aarch64_be-none-elf/install/share/doc/" || /bin/sh /.../src/gcc/gcc/../mkinstalldirs "/.../build-aarch64_be-none-elf/install/share/doc/" /usr/bin/install -C -m 644 '/.../src/gcc/gcc/doc/fortran/html/html/index.html' '/.../build-aarch64_be-none-elf/install/share/doc//index.html' /usr/bin/install: cannot stat ‘/.../src/gcc/gcc/doc/fortran/html/html/index.html’: No such file or directory Is the above error due to not installing sphinx 5.3.0? I assumed installing sphinx 5.3.0 would help, but after installing sphinx 5.3.0, I get a different error: Extension error: Could not import extension gcc_sphinx (exception: No module named 'gcc_sphinx') Makefile:84: recipe for target 'info' failed
[Bug other/107620] Build errors when using sphinx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107620 --- Comment #2 from vvinayag at arm dot com --- (In reply to Martin Liška from comment #1) > Confirmed. Btw. what revision do you build and what command do you use? Could you please clarify what you are referring to, for the revision and command?
[Bug testsuite/99731] g++.dg/modules/alias-1_a.H: error: failed to read compiled module: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99731 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #3 from vvinayag at arm dot com --- (In reply to H.J. Lu from comment #2) > (In reply to Nathan Sidwell from comment #1) > > How repeatable is this? > > Close to 100%. Is there an update on these failures? I have also seen these failures and have not understood the cause.
[Bug tree-optimization/118194] [12/13/14/15 regression] spurious warning with -Wmaybe-uninitialized with mlock since r11-959-gb825a22890740f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118194 --- Comment #8 from vvinayag at arm dot com --- (In reply to Sam James from comment #6) > (In reply to vvinayag from comment #5) > > (In reply to Sam James from comment #4) > > > (In reply to Xi Ruoyao from comment #1) > > > > I suppose Glibc should add __attribute__((access(1, none))) for mlock. > > > > > > commit 013106ae677af9836614ace1a01d25b63fa555a7 (HEAD -> master, > > > origin/master, origin/HEAD) > > > Author: Xi Ruoyao > > > Date: Thu Dec 26 12:51:18 2024 +0800 > > > > > > mlock, mlock2, munlock: Tell the compiler we don't dereference the > > > pointer > > > > > > Since https://gcc.gnu.org/r11-959, the compiler emits > > > -Wmaybe-uninitialized if a const pointer to an uninitialized buffer is > > > passed. Tell the compiler we don't dereference the pointer to remove > > > the false alarm. > > > > > > Link: https://gcc.gnu.org/PR118194 > > > Signed-off-by: Xi Ruoyao > > > Reviewed-by: Sam James > > > > > > After this commit, there is a build failure : > > > > ../sysdeps/unix/sysv/linux/bits/mman-shared.h:60:5: error: attribute > > ‘access’ invalid mode ‘__none__’; expected one of ‘read_only’, ‘read_write’, > > or ‘write_only’ > >60 | __attr_access ((__none__, 1)); > > | ^ > > Can you replace the line with: > __attr_access_none (1); > and let me know if it helps? Sorry for the delay. Yes, this fixed the build failure for me, when using commit e9be7701e6cd2b7be5454efaece3abc7ec9102ce
[Bug tree-optimization/118194] [12/13/14/15 regression] spurious warning with -Wmaybe-uninitialized with mlock since r11-959-gb825a22890740f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118194 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #5 from vvinayag at arm dot com --- (In reply to Sam James from comment #4) > (In reply to Xi Ruoyao from comment #1) > > I suppose Glibc should add __attribute__((access(1, none))) for mlock. > > commit 013106ae677af9836614ace1a01d25b63fa555a7 (HEAD -> master, > origin/master, origin/HEAD) > Author: Xi Ruoyao > Date: Thu Dec 26 12:51:18 2024 +0800 > > mlock, mlock2, munlock: Tell the compiler we don't dereference the > pointer > > Since https://gcc.gnu.org/r11-959, the compiler emits > -Wmaybe-uninitialized if a const pointer to an uninitialized buffer is > passed. Tell the compiler we don't dereference the pointer to remove > the false alarm. > > Link: https://gcc.gnu.org/PR118194 > Signed-off-by: Xi Ruoyao > Reviewed-by: Sam James After this commit, there is a build failure : ../sysdeps/unix/sysv/linux/bits/mman-shared.h:60:5: error: attribute ‘access’ invalid mode ‘__none__’; expected one of ‘read_only’, ‘read_write’, or ‘write_only’ 60 | __attr_access ((__none__, 1)); | ^ In file included from ../include/sys/mman.h:2, from ../sysdeps/generic/ldsodefs.h:34, from ../sysdeps/aarch64/ldsodefs.h:47, from ../sysdeps/gnu/ldsodefs.h:46, from ../sysdeps/unix/sysv/linux/ldsodefs.h:25, from :2: ../misc/sys/mman.h:104:5: error: attribute ‘access’ invalid mode ‘__none__’; expected one of ‘read_only’, ‘read_write’, or ‘write_only’ 104 | __attr_access ((__none__, 1)); | ^ ../misc/sys/mman.h:108:5: error: attribute ‘access’ invalid mode ‘__none__’; expected one of ‘read_only’, ‘read_write’, or ‘write_only’ 108 | __attr_access ((__none__, 1)); | ^ I am trying to build for aarch64-none-linux-gnu target on an aarch64-none-linux-gnu machine. The gcc version on the build machine is 7.5.0.
[Bug tree-optimization/114052] [12 Regression] Wrong code at -O2 for well-defined infinite loop since r8-5245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #22 from vvinayag at arm dot com ---
(In reply to rguent...@suse.de from comment #19)
> On Thu, 6 Mar 2025, vvinayag at arm dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
> >
> > vvinayag at arm dot com changed:
> >
> >What|Removed |Added
> >
> > CC| |vvinayag at arm dot com
> >
> > --- Comment #18 from vvinayag at arm dot com ---
> > (In reply to GCC Commits from comment #17)
> > > The releases/gcc-14 branch has been updated by Richard Biener
> > > :
> > >
> > > https://gcc.gnu.org/g:c886bd9ab21429a11bea393b5a6e7438a1d924ef
> > >
> > > commit r14-11329-gc886bd9ab21429a11bea393b5a6e7438a1d924ef
> > > Author: Richard Biener
> > > Date: Wed Jan 29 13:25:14 2025 +0100
> > >
> > > tree-optimization/114052 - consider infinite sub-loops when lowering
> > > iter bound
> > >
> > > When we walk stmts to find always executed stmts with UB in the last
> > > iteration to be able to reduce the iteration count by one we fail
> > > to consider infinite subloops in the last iteration that would make
> > > such stmt not execute. The following adds this.
> > >
> > > PR tree-optimization/114052
> > > * tree-ssa-loop-niter.cc (maybe_lower_iteration_bound): Check
> > > for infinite subloops we might not exit.
> > >
> > > * gcc.dg/pr114052-1.c: New testcase.
> >
> >
> > For bare-metal targets (aarch64-none-elf, arm-none-eabi),
> > gcc.dg/pr114052-1.c
> > seems to be UNSUPPORTED in trunk.
> > However, when using releases/gcc-14, gcc.dg/pr114052-1.c FAILs with this
> > message:
> >
> > pr114052-1.c:(.text.startup+0x24): undefined reference to `sigaction'
> > collect2: error: ld returned 1 exit status
> > compiler exited with status 1
> > FAIL: gcc.dg/pr114052-1.c (test for excess errors)
> > Excess errors:
> > pr114052-1.c:(.text.startup+0x24): undefined reference to `sigaction'
> >
> >
> > I am not sure whether this is related, but when I had a look to see what's
> > different between the patches in trunk and gcc-14:
> > The patch in trunk has an additional requirement on alarm:
> > /* { dg-require-effective-target alarm } */
>
> Yep, that doesn't exist on the branch.
Is this new testcase (gcc.dg/pr114052-1.c) meant to be unsupported on gcc-13
and gcc-14, like it is unsupported on trunk?
[Bug tree-optimization/114052] [12 Regression] Wrong code at -O2 for well-defined infinite loop since r8-5245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #24 from vvinayag at arm dot com ---
(In reply to rguent...@suse.de from comment #23)
> On Fri, 11 Apr 2025, vvinayag at arm dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
> >
> > --- Comment #22 from vvinayag at arm dot com ---
> > (In reply to rguent...@suse.de from comment #19)
> > > On Thu, 6 Mar 2025, vvinayag at arm dot com wrote:
> > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
> > > >
> > > > vvinayag at arm dot com changed:
> > > >
> > > >What|Removed |Added
> > > > --------------------
> > > > CC||vvinayag at arm dot com
> > > >
> > > > --- Comment #18 from vvinayag at arm dot com ---
> > > > (In reply to GCC Commits from comment #17)
> > > > > The releases/gcc-14 branch has been updated by Richard Biener
> > > > > :
> > > > >
> > > > > https://gcc.gnu.org/g:c886bd9ab21429a11bea393b5a6e7438a1d924ef
> > > > >
> > > > > commit r14-11329-gc886bd9ab21429a11bea393b5a6e7438a1d924ef
> > > > > Author: Richard Biener
> > > > > Date: Wed Jan 29 13:25:14 2025 +0100
> > > > >
> > > > > tree-optimization/114052 - consider infinite sub-loops when
> > > > > lowering
> > > > > iter bound
> > > > >
> > > > > When we walk stmts to find always executed stmts with UB in the
> > > > > last
> > > > > iteration to be able to reduce the iteration count by one we fail
> > > > > to consider infinite subloops in the last iteration that would
> > > > > make
> > > > > such stmt not execute. The following adds this.
> > > > >
> > > > > PR tree-optimization/114052
> > > > > * tree-ssa-loop-niter.cc (maybe_lower_iteration_bound):
> > > > > Check
> > > > > for infinite subloops we might not exit.
> > > > >
> > > > > * gcc.dg/pr114052-1.c: New testcase.
> > > >
> > > >
> > > > For bare-metal targets (aarch64-none-elf, arm-none-eabi),
> > > > gcc.dg/pr114052-1.c
> > > > seems to be UNSUPPORTED in trunk.
> > > > However, when using releases/gcc-14, gcc.dg/pr114052-1.c FAILs with this
> > > > message:
> > > >
> > > > pr114052-1.c:(.text.startup+0x24): undefined reference to `sigaction'
> > > > collect2: error: ld returned 1 exit status
> > > > compiler exited with status 1
> > > > FAIL: gcc.dg/pr114052-1.c (test for excess errors)
> > > > Excess errors:
> > > > pr114052-1.c:(.text.startup+0x24): undefined reference to `sigaction'
> > > >
> > > >
> > > > I am not sure whether this is related, but when I had a look to see
> > > > what's
> > > > different between the patches in trunk and gcc-14:
> > > > The patch in trunk has an additional requirement on alarm:
> > > > /* { dg-require-effective-target alarm } */
> > >
> > > Yep, that doesn't exist on the branch.
> >
> > Is this new testcase (gcc.dg/pr114052-1.c) meant to be unsupported on
> > gcc-13
> > and gcc-14, like it is unsupported on trunk?
>
> On a target w/o 'alarm'? Yes.
gcc.dg/pr114052-1.c tests are failing in gcc-13 and gcc-14.
Is it the case that the testcase in gcc-13 and gcc-14 is missing the
requirement on alarm:
/* { dg-require-effective-target alarm } */
[Bug testsuite/118597] [15 Regression] gcc.dg/vect/vect-fncall-mask.c fails since r15-6945-gea1deefe54ea1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118597 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #6 from vvinayag at arm dot com --- (In reply to Thiago Jung Bauermann from comment #1) > Our CI bisected it to commit r15-6945-gea1deefe54ea1c . > > https://linaro.atlassian.net/browse/GNU-1503 > > It also detected that spec2k6 433.milc with -Os increased in size by 4% from > 98540 to 102636 bytes. These regressions in vect-fncall-mask.c are also present in the gcc-14 branch. However, they seem to be passing in trunk now.
[Bug testsuite/118597] [15 Regression] gcc.dg/vect/vect-fncall-mask.c fails since r15-6945-gea1deefe54ea1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118597 --- Comment #7 from vvinayag at arm dot com --- These regressions in vect-fncall-mask.c are also present in gcc-14. However they seem to be passing in trunk now.
[Bug tree-optimization/114052] [12/13 Regression] Wrong code at -O2 for well-defined infinite loop since r8-5245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
vvinayag at arm dot com changed:
What|Removed |Added
CC||vvinayag at arm dot com
--- Comment #18 from vvinayag at arm dot com ---
(In reply to GCC Commits from comment #17)
> The releases/gcc-14 branch has been updated by Richard Biener
> :
>
> https://gcc.gnu.org/g:c886bd9ab21429a11bea393b5a6e7438a1d924ef
>
> commit r14-11329-gc886bd9ab21429a11bea393b5a6e7438a1d924ef
> Author: Richard Biener
> Date: Wed Jan 29 13:25:14 2025 +0100
>
> tree-optimization/114052 - consider infinite sub-loops when lowering
> iter bound
>
> When we walk stmts to find always executed stmts with UB in the last
> iteration to be able to reduce the iteration count by one we fail
> to consider infinite subloops in the last iteration that would make
> such stmt not execute. The following adds this.
>
> PR tree-optimization/114052
> * tree-ssa-loop-niter.cc (maybe_lower_iteration_bound): Check
> for infinite subloops we might not exit.
>
> * gcc.dg/pr114052-1.c: New testcase.
For bare-metal targets (aarch64-none-elf, arm-none-eabi), gcc.dg/pr114052-1.c
seems to be UNSUPPORTED in trunk.
However, when using releases/gcc-14, gcc.dg/pr114052-1.c FAILs with this
message:
pr114052-1.c:(.text.startup+0x24): undefined reference to `sigaction'
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: gcc.dg/pr114052-1.c (test for excess errors)
Excess errors:
pr114052-1.c:(.text.startup+0x24): undefined reference to `sigaction'
I am not sure whether this is related, but when I had a look to see what's
different between the patches in trunk and gcc-14:
The patch in trunk has an additional requirement on alarm:
/* { dg-require-effective-target alarm } */
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gcc.dg/pr114052-1.c;h=98e93bf670da79c5b746131418aa15c5396995d0;hb=d1c7837d2d6e5a2997228681166ed8c814891881
