Re: Strange executable text files in the repository
Jakub Jelinek writes: > While working on Fedora gcc 9 rpm, I've noticed a couple of messages: > *** WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/libphobos/libdruntime/core/sys/posix/sys/ioccom.d > is executable but has empty or no shebang, > *** WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/libphobos/libdruntime/core/sys/posix/sys/ttycom.d > is executable but has empty or no shebang, > *** WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/gcc/ada/set_targ.ads is > executable but has empty or no shebang, removing executable bit > *** WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/gcc/ada/set_targ.adb is > executable but has empty or no shebang, removing executable bit > *** WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc > is executable but has empty or no shebang, removing executable bit > > None of these files look like executable, any objections against (found > through > find [^o]* -type f -a -executable | xargs grep -L '^#!' > and removed from the list some ELF/Mach-O executables in the libgo (which > maybe shouldn't be executable anyway, we don't want people to run it when > they don't really know what it contains))? Do the libgo and/or > libphobos changes need to go through upstream first? The libgo changes don't need to go through upstream. Oddly the container/list files are not marked executable in upstream anyhow. I don't know why they are marked executable in the GCC sources. Thanks. Ian > I've checked libsanitizer upstream and sanitizer_common_interceptors_ioctl.inc > isn't executable there. > > svn propdel svn:executable \ > contrib/reghunt/examples/reg-watch.awk \ > gcc/testsuite/gcc.target/csky/fnmul-1.c \ > gcc/testsuite/gcc.target/csky/fnmul-3.c \ > gcc/testsuite/gcc.target/csky/fnmul-2.c \ > gcc/testsuite/gcc.target/csky/fnmul-4.c \ > gcc/testsuite/gcc.target/arc/loop-1.c \ > gcc/testsuite/gcc.target/arc/sdata-5.c \ > gcc/testsuite/gcc.target/arc/tdelegitimize_addr.c \ > gcc/testsuite/gcc.target/arc/pr9001195952.c \ > gcc/testsuite/gcc.target/arc/bitfield.c \ > gcc/testsuite/gcc.target/arc/tumaddsidi4.c \ > gcc/testsuite/gcc.dg/format/sys_format.c \ > gcc/ada/set_targ.ads \ > gcc/ada/set_targ.adb \ > libgo/go/container/list/list.go \ > libgo/go/container/list/list_test.go \ > libphobos/libdruntime/core/sys/posix/sys/ioccom.d \ > libphobos/libdruntime/core/sys/posix/sys/ttycom.d \ > libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc > > Jakub
gcc-8-20190111 is now available
Snapshot gcc-8-20190111 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190111/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 267858 You'll find: gcc-8-20190111.tar.xzComplete GCC SHA256=b9cdfc65ee9cf5054a9d45496c70830a58bcf30b551629ad052a55779ccdbd65 SHA1=09eb5c1d56d78b02b8b41b92516aefc0e0446e92 Diffs from 8-20190104 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 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.
Re: Strange executable text files in the repository
> While working on Fedora gcc 9 rpm, I've noticed a couple of messages: > *** WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/libphobos/libdruntime/core/sys/po > six/sys/ioccom.d is executable but has empty or no shebang, *** WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/libphobos/libdruntime/core/sys/po > six/sys/ttycom.d is executable but has empty or no shebang, *** WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/gcc/ada/set_targ.ads is > executable but has empty or no shebang, removing executable bit *** > WARNING: ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/gcc/ada/set_targ.adb is > executable but has empty or no shebang, removing executable bit *** > WARNING: > ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/libsanitizer/sanitizer_common/san > itizer_common_interceptors_ioctl.inc is executable but has empty or no > shebang, removing executable bit Typically (not for the sanitizer) because the files were created on Windows. > None of these files look like executable, any objections against (found > through > find [^o]* -type f -a -executable | xargs grep -L '^#!' > and removed from the list some ELF/Mach-O executables in the libgo (which > maybe shouldn't be executable anyway, we don't want people to run it when > they don't really know what it contains))? Do the libgo and/or > libphobos changes need to go through upstream first? > I've checked libsanitizer upstream and > sanitizer_common_interceptors_ioctl.inc isn't executable there. No objections for the couple of Ada files. -- Eric Botcazou
Strange executable text files in the repository
Hi! While working on Fedora gcc 9 rpm, I've noticed a couple of messages: *** WARNING: ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/libphobos/libdruntime/core/sys/posix/sys/ioccom.d is executable but has empty or no shebang, *** WARNING: ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/libphobos/libdruntime/core/sys/posix/sys/ttycom.d is executable but has empty or no shebang, *** WARNING: ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/gcc/ada/set_targ.ads is executable but has empty or no shebang, removing executable bit *** WARNING: ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/gcc/ada/set_targ.adb is executable but has empty or no shebang, removing executable bit *** WARNING: ./usr/src/debug/gcc-9.0.0-0.1.fc29.x86_64/libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc is executable but has empty or no shebang, removing executable bit None of these files look like executable, any objections against (found through find [^o]* -type f -a -executable | xargs grep -L '^#!' and removed from the list some ELF/Mach-O executables in the libgo (which maybe shouldn't be executable anyway, we don't want people to run it when they don't really know what it contains))? Do the libgo and/or libphobos changes need to go through upstream first? I've checked libsanitizer upstream and sanitizer_common_interceptors_ioctl.inc isn't executable there. svn propdel svn:executable \ contrib/reghunt/examples/reg-watch.awk \ gcc/testsuite/gcc.target/csky/fnmul-1.c \ gcc/testsuite/gcc.target/csky/fnmul-3.c \ gcc/testsuite/gcc.target/csky/fnmul-2.c \ gcc/testsuite/gcc.target/csky/fnmul-4.c \ gcc/testsuite/gcc.target/arc/loop-1.c \ gcc/testsuite/gcc.target/arc/sdata-5.c \ gcc/testsuite/gcc.target/arc/tdelegitimize_addr.c \ gcc/testsuite/gcc.target/arc/pr9001195952.c \ gcc/testsuite/gcc.target/arc/bitfield.c \ gcc/testsuite/gcc.target/arc/tumaddsidi4.c \ gcc/testsuite/gcc.dg/format/sys_format.c \ gcc/ada/set_targ.ads \ gcc/ada/set_targ.adb \ libgo/go/container/list/list.go \ libgo/go/container/list/list_test.go \ libphobos/libdruntime/core/sys/posix/sys/ioccom.d \ libphobos/libdruntime/core/sys/posix/sys/ttycom.d \ libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc Jakub
ISL tiling question (gcc.dg/graphite/interchange-3.c)
Someone here was asking about GCC, ISL, and tiling and we looked at the test gcc.dg/graphite/interchange-3.c on Aarch64. When this test is run the graphite pass output file contains the string 'not tiled' and since the dg-final scan-tree-dump is just looking for the string 'tiled', it matches and the test passes. Is this intentional? It seems like if we wanted to check that it was not tiled we sould grep for 'not tiled', not just 'tiled'. If we want grep to see that it is tiled, then the check for tiling happening is wrong. Steve Ellcey sell...@marvell.com
Re: How to control GCC builtin functions optimization
On 1/11/19 7:09 PM, Cao jin wrote: > Hi Martin, >> >> and possibly for: >> -mmemcpy-strategy >> >> and >> -mstringop-strategy=alg >> > > And yes, -mmemcpy-strategy worked as I expected. typo. It is -mstringop-strategy=byte_loop -- Sincerely, Cao jin
Re: How to control GCC builtin functions optimization
Hi Martin, On 1/11/19 5:22 PM, Martin Liška wrote: > On 1/11/19 4:03 AM, Cao jin wrote: >> Now the questions is: from code-reading, it is kind of non-intuitive, is >> there any explicit way to control the optimization behavior accurately? > > Hi. > > Please take a look here: > https://gcc.gnu.org/onlinedocs/gcc.pdf Yes, I already have it and spent some time on it. It just a little bit difficult for GCC newbie to find the answer accurately(I searched some of the used flags). > > you are searching for: > -mmemcpy > -mno-memcpy > Force (do not force) the use of memcpy for non-trivial block moves. The > default > is ‘-mno-memcpy’, which allows GCC to inline most constant-sized copies I tried -mmemcpy, it seems these two are not for x86. > > and possibly for: > -mmemcpy-strategy > > and > -mstringop-strategy=alg > And yes, -mmemcpy-strategy worked as I expected. Thanks very much! -- Sincerely, Cao jin
Status of 9.0.0 20190110 (experimental) [trunk revision 267818] (GCC) testsuite on x86_64-w64-mingw32
There was a bug which prevented building libgfortran. Now after the issue is fixed, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331, I have posted new testresults. https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg01052.html Compared to rev. 265163 we have the following changes: acats tests: 15 new unexpected failures g++ tests: 155 additional unexpected failures gcc tests: 63 additional unexpected failures gfortran tests: 22 additional unexpected failures gnat tests: 1 additional unexpected successes obj-c++ tests: 5 additional unexpected failures objc tests: no difference libatomic: no difference libgomp: 71 additional unexpected failures libstdc++ tests: 5 additional unexpected failures You may find the complete logs at https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W I hope this helps. Rainer signature.asc Description: OpenPGP digital signature
Re: How to control GCC builtin functions optimization
On 1/11/19 4:03 AM, Cao jin wrote: > Now the questions is: from code-reading, it is kind of non-intuitive, is > there any explicit way to control the optimization behavior accurately? Hi. Please take a look here: https://gcc.gnu.org/onlinedocs/gcc.pdf you are searching for: -mmemcpy -mno-memcpy Force (do not force) the use of memcpy for non-trivial block moves. The default is ‘-mno-memcpy’, which allows GCC to inline most constant-sized copies and possibly for: -mmemcpy-strategy and -mstringop-strategy=alg Martin
