[Bug lto/105364] lto-wrapper generates URLs escape sequences despite -fdiagnostic-urls=never
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105364 --- Comment #5 from wavexx at thregr dot org --- Verified today on debian unstable which just updated the gcc12 snapshot. Thx for the quick fix to all.
[Bug plugins/105364] New: lto-wrapper generates URLs escape sequences despite -fdiagnostic-urls=never
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105364 Bug ID: 105364 Summary: lto-wrapper generates URLs escape sequences despite -fdiagnostic-urls=never Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: wavexx at thregr dot org Target Milestone: --- Warnings generated by lto-wrapper do not seem to check the current terminal settings (TERM=dumb doesn't do anything useful) and/or even respect -fdiagnostics-urls=never provided while linking: gcc -Wl,--as-needed -fdiagnostics-urls=never -fPIE -pie -fuse-ld=mold -flto -o spectrwm spectrwm.o linux.o -lX11-xcb -lX11 -lxcb-icccm -lxcb-keysyms -lxcb-randr -lxcb-util -lxcb -lxcb-xinput -lxcb-xtest -lXcursor -lXft lto-wrapper: warning: using serial compilation of 3 LTRANS jobs lto-wrapper: note: see the ]8;;https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto‘-flto’ option documentation]8;; for more information (note the inline escape ESC ] 8) % gcc --version gcc (Debian 12-20220319-1) 12.0.1 20220319 (experimental) [master r12-7719-g8ca61ad148f]
[Bug driver/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 --- Comment #19 from wavexx at thregr dot org --- I don't follow gcc development too closely. I expected this bug to be closed when the relevant patch was applied automatically, but I could test if this still apllied. Which gcc release is sufficient to test with all the patches applied? Is gcc 10.2.1 enough?
[Bug driver/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 --- Comment #17 from wavexx at thregr dot org --- I wish this would be given a nudge, considering the patch. This has been pushed to new releases since 2016 :( It's not a show-stopper, but it does cause unexpected behavior which is quite hard to track down and to fix as well in build systems unless you're accounting for it from the start.
[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 --- Comment #4 from wavexx at thregr dot org --- Since I couldn't find documentation for it either, doesn't -march=haswell by itself imply all associated ISA features? If so, why -march=native expands to all individual features explicitly?
[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 --- Comment #2 from wavexx at thregr dot org --- On 25/01/16 18:38, redi at gcc dot gnu.org wrote: > Why would either you or the makefile add something like -march=opteron on a > haswell host? > > Surely the makefile should only add option that make sense, and you should > only > override them with options that make sense. I generally use -march=native for most of my in-house projects. However, on very few binaries part of a larger project I actually target some older ISAs so I simply append -march=[x] as an exception with the usual CFLAGS += I could also (as I'm currently doing) splice -march out of CFLAGS and/or override CFLAGS in the required rules, so it's not a huge deal (as outlined in the original discussion), but even if documented, I would find the current behavior unexpected. I would have expected -march=native to simply expand to -march=haswell so that I could override it normally as I do for almost everything else.
[Bug target/69471] New: "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 Bug ID: 69471 Summary: "-march=native" unintentionally breaks further -march/-mtune flags Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: wavexx at thregr dot org Target Milestone: --- On a haswell host, the following: gcc -march=native -march=opteron or gcc -march=opteron -march=native both emit code which is illegal for the opteron ISA. Specifying -march=opteron alone works as intended. By running gcc -v I see: % g++ -MD -D_FILE_OFFSET_BITS=64 -O3 -march=native -pipe -fvisibility-inlines-hidden -O3 -pipe -march=opteron -mtune=generic -ggdb3 -std=gnu++11 -Wall -Wextra -Wpedantic -Wno-unused-parameter -c -o metasplit.o metasplit.cc -v Using built-in specs. COLLECT_GCC=g++ Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6-20160117-1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 6.0.0 20160117 (experimental) [trunk revision 232481] (Debian 6-20160117-1) COLLECT_GCC_OPTIONS='-MD' '-D' '_FILE_OFFSET_BITS=64' '-O3' '-march=native' '-pipe' '-fvisibility-inlines-hidden' '-O3' '-pipe' '-march=opteron' '-mtune=generic' '-ggdb3' '-std=gnu++11' '-Wall' '-Wextra' '-Wpedantic' '-Wno-unused-parameter' '-c' '-o' 'metasplit.o' '-v' '-shared-libgcc' /usr/lib/gcc/x86_64-linux-gnu/6/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -MD metasplit.d -MQ metasplit.o -dD -D_GNU_SOURCE -D _FILE_OFFSET_BITS=64 metasplit.cc -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-clwb -mno-pcommit -mno-mwaitx -mno-clzero -mno-pku -quiet -dumpbase metasplit.cc -march=opteron -mtune=generic -auxbase-strip metasplit.o -ggdb3 -O3 -O3 -Wall -Wextra -Wpedantic -Wno-unused-parameter -std=gnu++11 -version -fvisibility-inlines-hidden -o - | as -v --64 -o metasplit.o It becomes obvious why is that: -march=native gets expanded to all host-specific instructions, while the next -march=opteron doesn't reset them. Since I generally override the default flags in makefiles by appending exceptions where needed, I expect the regular behavior where the last flags overrides previous ones and thus found the current behavior unexpected. I originally discovered this problem in gcc 5.2, but it's still present in all further versions.
