Cco gnu compiler
I am currently studying assembly language by kip Irvine and have ordered Sam R teah yourself C++ in 24 hours.. My route will include the most updated Java edition afterwards. I also need to update my computer, whoh is no longer supported, which computer should I get to accommodate your compiler? Sincerely, liliam Revheim 18169 w Sundowner way, # 908 Canyon. Country - CA - 91387
[gcc-13.3.0] dlopen() crash issue
Hi Thomas, i recently meet below crash within dlopen() related to toolchain-aarch64_cortex-a53_gcc-13.3.0_musl\gcc-13.3.0 for openwrt. it seems it is caused by gcc bug related to MACRO ATOMIC_FDE_FAST_PATH (gdb) bt #0 0x007f8adfde4c in strlen (s=s@entry=0x7f7f853b72 ) at src/string/strlen.c:16 #1 0x007f8a79817c in get_cie_encoding (cie=cie@entry=0x7f7f853b69) at /local/mnt/workspace/sdx85_227/owrt/build_dir/toolchain-aarch64_cortex-a53_gcc-13.3.0_musl/gcc-13.3.0/libgcc/unwind-dw2-fde.c:352 #2 0x007f8a7982e0 in classify_object_over_fdes (ob=0x7f8988b0c8 , this_fde=0x7f89873b64, range=0x7f898ad360) at /local/mnt/workspace/sdx85_227/owrt/build_dir/toolchain-aarch64_cortex-a53_gcc-13.3.0_musl/gcc-13.3.0/libgcc/unwind-dw2-fde.c:747 #3 0x007f8a7997f0 in register_pc_range_for_object (begin=, ob=0x7f8988b0c8 ) at /local/mnt/workspace/sdx85_227/owrt/build_dir/toolchain-aarch64_cortex-a53_gcc-13.3.0_musl/gcc-13.3.0/libgcc/unwind-dw2-fde.c:118 #4 0x007f8ae0c130 in do_init_fini (queue=) at ldso/dynlink.c:1608 #5 0x007f8ae0e098 in dlopen (file=0x7f8a3f6530 "bttransport.so", mode=1) at ldso/dynlink.c:2221 #6 0x007f8a36744c in vnd_interface_open () at src/hci_layer_le.cc:239 there are no such issue for the same program built with below gcc-12.3.0 toolchain-aarch64_cortex-a53_gcc-12.3.0_musl\gcc-12.3.0 i am not sure if this is the good way to report gcc issue. (^^)
Re: [CAUTION - External Sender] Re: gcc relies on RISC-V vcompress instruction undefined behaviour
Hi Richard, > Please file a bugreport so this issue doesn't get lost. I was struggling to reproduce it on a recent toolchain, but I managed to take one of the gcc test cases and recreate it I think. I submitted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117383 Thanks, Anton
Re: [gcc-13.3.0] dlopen() crash issue
On Thu, 31 Oct 2024 at 12:12, quic_zijuhu via Gcc wrote: > > i am not sure if this is the good way to report gcc issue. (^^) Please see https://gcc.gnu.org/bugs (or the "Bugs" section of the sidebar on the https://gcc.gnu.org homepage).
Re: gcc relies on RISC-V vcompress instruction undefined behaviour
> Hi,
>
> I think gcc is relying on undefined behaviour with the vcompress instruction.
> Unfortunately my test case isn't reproducing on mainline, but gcc looks to
> use the fields between the last mask selected field and vl while setting
> tail agnostic.
>
> This thread explains how vcompress is different in that the tail starts after
> the last mask selected field:
>
> https://github.com/riscvarchive/riscv-v-spec/issues/796
>
> There was a bug in QEMU that I just fixed that prevented the all 1s tail
> agnostic option (rvv_ta_all_1s) from poisoning these bits:
>
> https://lists.nongnu.org/archive/html/qemu-riscv/2024-10/msg00561.html
>
> With that fix, I see problems until I modify the previous setvli from ta to
> tu. I think 9aabf81f40f0 ("RISC-V: Optimize permutation codegen with
> compress") is one place we need to set tail undisturbed, but my fail is
> from an earlier checkout so there must be another issue in the tree.
>
> I presume the fix is to force all these vcompress cases to set tail
> undisturbed.
>
> Thanks,
> Anton
Could you send your test case so we can have a look? Or directly file a bug
as Richi suggested.
--
Regards
Robin
Re: gcc relies on RISC-V vcompress instruction undefined behaviour
On Thu, Oct 31, 2024 at 3:55 AM Anton Blanchard via Gcc wrote:
>
> Hi,
>
> I think gcc is relying on undefined behaviour with the vcompress instruction.
> Unfortunately my test case isn't reproducing on mainline, but gcc looks to
> use the fields between the last mask selected field and vl while setting
> tail agnostic.
>
> This thread explains how vcompress is different in that the tail starts after
> the last mask selected field:
>
> https://github.com/riscvarchive/riscv-v-spec/issues/796
>
> There was a bug in QEMU that I just fixed that prevented the all 1s tail
> agnostic option (rvv_ta_all_1s) from poisoning these bits:
>
> https://lists.nongnu.org/archive/html/qemu-riscv/2024-10/msg00561.html
>
> With that fix, I see problems until I modify the previous setvli from ta to
> tu. I think 9aabf81f40f0 ("RISC-V: Optimize permutation codegen with
> compress") is one place we need to set tail undisturbed, but my fail is
> from an earlier checkout so there must be another issue in the tree.
>
> I presume the fix is to force all these vcompress cases to set tail
> undisturbed.
Or to zero, matching the masked behavior?
Please file a bugreport so this issue doesn't get lost.
Richard.
> Thanks,
> Anton
gcc-12-20241031 is now available
Snapshot gcc-12-20241031 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20241031/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 49971d35ef30c3f2cde2636f9e0c072ca016db8a You'll find: gcc-12-20241031.tar.xz Complete GCC SHA256=f4df5eb861fcbdfab44a23c139d8b1abb928ed819f07109c141106a11dfe6244 SHA1=a6185061b6b172b7e08fe3bb7c34aea7ed0956ae Diffs from 12-20241010 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
