gcc 10.5: libsanitizer: fsanitize=leak option Issue
Hello, I upgrade the gcc in my setup from 10.2 to 10.5 to the latest commit. After that I build an application with the -fsanitize=leak option. The execution of the application stops immediatly after start with the following error: CHECK failed: ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:53 ((!lsan_init_is_running)) != (0) (0, 0) I did some research and found following Issue discussion on Github: https://github.com/magma/magma/issues/15279 There is as well a solution describe to overwrite __lsan_init() call with an own, empty, implementation. This is not feasible for me, because I need to check the applicaitons with the fsanitizer=leak. There is as well a bug ticket of the error at the ubuntu launch pad: https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/2038386 The solutions to upgrade to gcc 11 or downgrade to gcc 10.2 are not feasible for me. I did as well research on the commits from gcc to find a solution, but could not find a patch, that points directly to that Issue. In the bug ticket from Ubuntu they say that the: "dlopen- specific allocator was reimplemented". Does anyone had experience with that Issue and knows a solution? Thanks in advance BR Michael
Re: GCC testing on FreeBSD
Hi Lorenzo, > I totally agree with you: upstreaming patches is important! It is not > only for the upstream project itself, but for the target as well: having > patches sitting in a ports collection also requires more maintainance, > they require to be kept up to date with the upstream progresses. indeed: e.g. some mechanical changes that affect your port can be dealt with easily when the developer in question finds the code in tree. Otherwise, this is only noticed during your next merge, possibly months later. > Unfortunately, it is not always possible to upstream a patch. Sometimes, > patches are too specific to a target to be suitable for upstream. Those are called hacks ;-) True: the code needs to be general to avoid the codebase slowly becoming unmaintainable. Maintainers keep the general code structure in mind, which may create more work for the submitter to develop a cleaner implementation. However, this ensures that the hack isn't broken subsequently and the code is more understandable to everyone. > For example, smaller projects might be interested in supporting only > very popular platforms and would not accept (or could not accept) > the complexity of supporting a less known target. > Hopefully this is not the case for GCC. I don't think so: the primary question is if the code is actively tested and maintained. And even so, we do have several ports in tree that have seen barely any maintenance in a long time. If they become a burden, this may lead to them being obsoleted and removed. > Other times, developers do try to upstream a patch, but fail. This > happened to myself in GCC too, when I was unable to get any > attention to a patch I submitted, and could not do any better > than keep the patch into the FreeBSD ports collection: > https://gcc.gnu.org/pipermail/jit/2023q3/001642.html > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491#c5 It happens to all of us. It usually helps to include the maintainers in question in the Cc: I've often also had better success by pinging not in the patch submission thread (where the pings can become lost in the noise), but by posting a separate message to gcc-patches with subject and URL to the latest version and perhaps a short indication who's required to review the patch, also Cc'ing the relevant maintainers. > If you are able to help with this upstreaming, I would appreciate > it a lot. Thanks. Probably not much: for one I'm pretty busy with my own Solaris work, and I've also stopped testing on FreeBSD even with the issues I've found and developed workarounds for. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [RISC-V] Support for trapping math in RISC-V
On Wed, 24 Apr 2024, Krishna Narayanan via Gcc wrote: > Hi all, > Is the RISC-V community planning to add support for trapping math in RISC-V > in the near future!? > This LLVM thread > https://discourse.llvm.org/t/trapping-math-for-risc-v/72168/7 suggests a > software emulation of traps, is the GNU team also on similar lines to this > implementation or has some different views. That strategy sounds both very slow and not even complete (it doesn't cover the case of exact underflow, which doesn't raise the exception flag, but should signal the exception when trapping is enabled). Traps are not part of standard C. I'm not aware of any implementations of the TS 18661-5 interfaces to alternate exception handling either. -- Joseph S. Myers josmy...@redhat.com
Question about information from -fdump-rtl-sched2 on M1 Max
The question: How to interpret scheduling info with the compiler listed below.
Specifically, a tight loop that was reported to be scheduled in 23 cycles (as I
understand it) actually executes in a little over 2 cycles per loop, as I
interpret two separate experiments.
Am I misinterpreting something here?
Thanks.
Brad
The compiler:
[MacBook-Pro:~/programs/gambit/gambit-feeley] lucier% gcc-13 -v
Using built-in specs.
COLLECT_GCC=gcc-13
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/13.2.0/bin/../libexec/gcc/aarch64-apple-darwin23/13/lto-wrapper
Target: aarch64-apple-darwin23
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc
--libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls
--enable-checking=release --with-gcc-major-version-only
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-13
--with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr
--with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl
--with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 13.2.0'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--with-system-zlib --build=aarch64-apple-darwin23
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk
--with-ld=/Library/Developer/CommandLineTools/usr/bin/ld-classic
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Homebrew GCC 13.2.0)
(so perhaps not the standard gcc).
The command line (cut down a bit) is
gcc-13 -save-temps -fverbose-asm -fdump-rtl-sched2 -O1
-fexpensive-optimizations -fno-gcse -Wno-unused -Wno-write-strings
-Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math
-fno-math-errno -fschedule-insns2 -foptimize-sibling-calls -fomit-frame-pointer
-fipa-ra -fmove-loop-invariants -march=native -fPIC -fno-common
-I"../include" -c -o _num.o -I. _num.c -D___LIBRARY
The scheduling report for the loop is
;; ==
;; -- basic block 10 from 39 to 70 -- after reload
;; ==
;;0--> b 0: i 39 x4=x2+x7
:cortex_a53_slot_any
;;0--> b 0: i 46 x1=zxn([sxn(x2)*0x4+x8])
:(cortex_a53_slot_any+cortex_a53_ls_agen),cortex_a53_load
;;3--> b 0: i 45 x9=zxn([sxn(x4)*0x4+x3])
:(cortex_a53_slot_any+cortex_a53_ls_agen),cortex_a53_load
;;7--> b 0: i 47 x1=zxn(x6)*zxn(x1)+x9
:(cortex_a53_slot_any+cortex_a53_imul)
;;9--> b 0: i 48 x1=x1+x5
:cortex_a53_slot_any
;;9--> b 0: i 53 x5=x12+x2
:cortex_a53_slot_any
;; 10--> b 0: i 50 [sxn(x4)*0x4+x3]=x1
:(cortex_a53_slot_any+cortex_a53_ls_agen),cortex_a53_store
;; 10--> b 0: i 57 x4=x2+0x1
:cortex_a53_slot_any
;; 11--> b 0: i 67 x2=x2+0x2
:cortex_a53_slot_any
;; 12--> b 0: i 60 x9=zxn([sxn(x5)*0x4+x3])
:(cortex_a53_slot_any+cortex_a53_ls_agen),cortex_a53_load
;; 13--> b 0: i 61 x4=zxn([sxn(x4)*0x4+x8])
:(cortex_a53_slot_any+cortex_a53_ls_agen),cortex_a53_load
;; 17--> b 0: i 62 x4=zxn(x6)*zxn(x4)+x9
:(cortex_a53_slot_any+cortex_a53_imul)
;; 20--> b 0: i 63 x1=x1 0>>0x20+x4
:cortex_a53_slot_any
;; 20--> b 0: i 65 [sxn(x5)*0x4+x3]=x1
:(cortex_a53_slot_any+cortex_a53_ls_agen),cortex_a53_store
;; 22--> b 0: i 66 x5=x1 0>>0x20
:cortex_a53_slot_any
;; 22--> b 0: i 69 cc=cmp(x11,x2)
:cortex_a53_slot_any
;; 23--> b 0: i 70 pc={(cc>0)?L68:pc}
:(cortex_a53_slot_any+cortex_a53_branch)
;; Ready list (final):
;; total time = 23
;; new head = 39
;; new tail = 70
Re: Question about information from -fdump-rtl-sched2 on M1 Max
That should be 4 cycles per loop, sorry. > On Apr 29, 2024, at 7:24 PM, Lucier, Bradley J wrote: > > Specifically, a tight loop that was reported to be scheduled in 23 cycles (as > I understand it) actually executes in a little over 2 cycles per loop
Re: Question about information from -fdump-rtl-sched2 on M1 Max
On Mon, Apr 29, 2024 at 4:26 PM Lucier, Bradley J via Gcc
wrote:
>
> The question: How to interpret scheduling info with the compiler listed below.
>
> Specifically, a tight loop that was reported to be scheduled in 23 cycles (as
> I understand it) actually executes in a little over 2 cycles per loop, as I
> interpret two separate experiments.
>
> Am I misinterpreting something here?
Yes, the schedule mode in use here is the cortex-a53 one ...
as evidenced by "cortex_a53_slot_" in the dump.
Most aarch64 cores don't have a schedule model associated with it.
Especially when it comes cores that don't have not been upstream
directly from the company that produces them.
The default scheduling model is cortex-a53 anyways. And you didn't use
-mtune= nor -mcpu=; only -march=native which just changes the arch
features and not the tuning or scheduler model.
Thanks,
Andrew Pinski
>
> Thanks.
>
> Brad
>
> The compiler:
>
> [MacBook-Pro:~/programs/gambit/gambit-feeley] lucier% gcc-13 -v
> Using built-in specs.
> COLLECT_GCC=gcc-13
> COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/13.2.0/bin/../libexec/gcc/aarch64-apple-darwin23/13/lto-wrapper
> Target: aarch64-apple-darwin23
> Configured with: ../configure --prefix=/opt/homebrew/opt/gcc
> --libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls
> --enable-checking=release --with-gcc-major-version-only
> --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-13
> --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr
> --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl
> --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 13.2.0'
> --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
> --with-system-zlib --build=aarch64-apple-darwin23
> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk
> --with-ld=/Library/Developer/CommandLineTools/usr/bin/ld-classic
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 13.2.0 (Homebrew GCC 13.2.0)
>
> (so perhaps not the standard gcc).
>
> The command line (cut down a bit) is
>
> gcc-13 -save-temps -fverbose-asm -fdump-rtl-sched2 -O1
> -fexpensive-optimizations -fno-gcse -Wno-unused -Wno-write-strings
> -Wdisabled-optimization -fwrapv -fno-strict-aliasing -fno-trapping-math
> -fno-math-errno -fschedule-insns2 -foptimize-sibling-calls
> -fomit-frame-pointer -fipa-ra -fmove-loop-invariants -march=native -fPIC
> -fno-common -I"../include" -c -o _num.o -I. _num.c -D___LIBRARY
>
> The scheduling report for the loop is
>
> ;; ==
> ;; -- basic block 10 from 39 to 70 -- after reload
> ;; ==
>
> ;;0--> b 0: i 39 x4=x2+x7
> :cortex_a53_slot_any
> ;;0--> b 0: i 46 x1=zxn([sxn(x2)*0x4+x8])
> :(cortex_a53_slot_any+cortex_a53_ls_agen),cortex_a53_load
> ;;3--> b 0: i 45 x9=zxn([sxn(x4)*0x4+x3])
> :(cortex_a53_slot_any+cortex_a53_ls_agen),cortex_a53_load
> ;;7--> b 0: i 47 x1=zxn(x6)*zxn(x1)+x9
> :(cortex_a53_slot_any+cortex_a53_imul)
> ;;9--> b 0: i 48 x1=x1+x5
> :cortex_a53_slot_any
> ;;9--> b 0: i 53 x5=x12+x2
> :cortex_a53_slot_any
> ;; 10--> b 0: i 50 [sxn(x4)*0x4+x3]=x1
> :(cortex_a53_slot_any+cortex_a53_ls_agen),cortex_a53_store
> ;; 10--> b 0: i 57 x4=x2+0x1
> :cortex_a53_slot_any
> ;; 11--> b 0: i 67 x2=x2+0x2
> :cortex_a53_slot_any
> ;; 12--> b 0: i 60 x9=zxn([sxn(x5)*0x4+x3])
> :(cortex_a53_slot_any+cortex_a53_ls_agen),cortex_a53_load
> ;; 13--> b 0: i 61 x4=zxn([sxn(x4)*0x4+x8])
> :(cortex_a53_slot_any+cortex_a53_ls_agen),cortex_a53_load
> ;; 17--> b 0: i 62 x4=zxn(x6)*zxn(x4)+x9
> :(cortex_a53_slot_any+cortex_a53_imul)
> ;; 20--> b 0: i 63 x1=x1 0>>0x20+x4
> :cortex_a53_slot_any
> ;; 20--> b 0: i 65 [sxn(x5)*0x4+x3]=x1
> :(cortex_a53_slot_any+cortex_a53_ls_agen),cortex_a53_store
> ;; 22--> b 0: i 66 x5=x1 0>>0x20
> :cortex_a53_slot_any
> ;; 22--> b 0: i 69 cc=cmp(x11,x2)
> :cortex_a53_slot_any
> ;; 23--> b 0: i 70 pc={(cc>0)?L68:pc}
> :(cortex_a53_slot_any+cortex_a53_branch)
> ;; Ready list (final):
> ;; total time = 23
> ;; new head = 39
> ;; new tail = 70
>
How to format code in GCC style?
Hi I'm trying to format my code in GCC style. But I don't know how to finish it. I try `indent` and `check_GNU_style.sh` in the `contrib` directory. But none of them seem to work well. So I wondered is there any official tools to do that? Thanks Hanke Zhang
