[Bug middle-end/80283] [5/6/7/8 Regression] bad SIMD register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283 shatz at dsit dot co.il changed: What|Removed |Added CC||shatz at dsit dot co.il --- Comment #16 from shatz at dsit dot co.il --- I still think that effect of tree-ter is accidental and relatively unimportant. Very similar problems with SIMD register allocation could easily happen without tree-ter, as demonstrated by 3 out of 4 cases of bad register allocation presented in this thread. It seems to me that the problem shall be handled in the back-end rather than middle-end (not sure that I got your terminology about various "ends" right).
[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255 --- Comment #22 from shatz at dsit dot co.il --- (In reply to Jakub Jelinek from comment #21) > It can't be changed in those manuals, ever, both 6.1 and 5.3 releases have > already been released, their documentation, including online docs, is what > has been released at that point. It sucks. The software can't be changed after release, for obvious reasons, but docs are not software. If it's impossible to change the policy about not fixing mistakes in docs, then, may be, it is possible to add documentation errata?
[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255 --- Comment #20 from shatz at dsit dot co.il --- (In reply to Marek Polacek from comment #19) > Markus recently committed a patch (r235580) that points out that this > attribute should only be used for debugging. 3 weeks after the patch I see no changes in official gcc-6.1.0 and gcc-5.3.0 manuals. Was it rejected by higher authority or the process is just slow?
[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255
--- Comment #18 from shatz at dsit dot co.il ---
(In reply to Manuel López-Ibáñez from comment #15)
> (In reply to shatz from comment #14)
> > It is not documented that __attribute__((optimize(""))) works reliably when
>
> Unfortunately, you should not expect the optimize attribute to work
> reliably: https://gcc.gnu.org/wiki/FAQ#optimize_attribute_broken
Regular users like me don't read this page and probable can't be realistically
expected to read it.
So, if the situation is really as bad as mentioned there, it should be
mentioned in the places that users do read.
Like these:
https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Function-Attributes.html#Function-Attributes
https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes
[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255
--- Comment #14 from shatz at dsit dot co.il ---
(In reply to Marek Polacek from comment #13)
> So what exactly is not documented?
>
> And I disagree that a warning isn't necessary just because something is
> documented -- that applies for almost any warning.
It is not documented that __attribute__((optimize(""))) works reliably when it
is present in the source before the function body, but is ignored (always?
occasionally?) when it specified after function body.
[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255 --- Comment #12 from shatz at dsit dot co.il --- (In reply to Marek Polacek from comment #11) > I added the warning, so closing as fixed. Warning is nice, but IMHO it is far more important to document the behavior in online documentation, including docs for older versions. In fact, if there will be a proper documentation in place, a warning is not so necessary.
[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255
--- Comment #7 from shatz at dsit dot co.il ---
(In reply to Richard Biener from comment #1)
> Confirmed. The issue seems to be that you add the optimize attribute after
> the function definition.
>
> This causes .original to be already
>
> ;; Function foo1 (null)
> ;; enabled by -tree-original
>
>
> {
> double s = h + 1.0e+0;
>
> double s = h + 1.0e+0;
> return ((h - s) + l) + 1.0e+0;
> }
>
> which is probably an artifact of fully delayed folding.
>
> The optimize attribute is still applied in the end but too late.
>
> Workaround is to put
>
> double foo1(double h, double l)
> __attribute__((optimize("no-associative-math")));
>
> before the definition.
Thank you for the tip.
[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255
--- Comment #8 from shatz at dsit dot co.il ---
Now a bit of philosophy.
Bugs aside, I should say that use of function attribute optimize() does not
look to me as an ideal solution for forcing ISO rules.
>From theoretical point of view, when we are specifying -Ofast or -ffast-math we
are no longer coding in C, but in programming language that looks like C, but
semantically is more close to Fortran. In this new language a specific grouping
of FP arithmetic ops is by default undefined. So, in this new language, we need
a construct that makes it defined again. Something like built-in function
__iso_order().
So, my test case will look like:
double foo1(double h, double l)
{
double s = __iso_order(h + 1.0);
return __iso_order(__iso_order(1.0 - s) + h) + l;
}
It has two advantages
1) Makes an intention of programmer more pronounced, which is always a good
thing
2) provides finer level of control than the whole function.
Because typically when I care about grouping of ops I only care about few
specific statements and don't care about the rest which tends to be a majority
even in a specific function.
[Bug c/70255] New: change of the order of summation of floating point numbers despite no-associative-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70255 Bug ID: 70255 Summary: change of the order of summation of floating point numbers despite no-associative-math Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: shatz at dsit dot co.il Target Milestone: --- Created attachment 37989 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37989=edit minimal test case of change of the order of summation Under certain very specific combination of factor gcc optimizer disregards order of summation specified in the source code despite "no-associative-math" option specified by means of function attribute. The bug does not happen when -fno-associative-math option specified on the command line. In the file, attached below there are 3 very similar versions of the function foo(). Only variant foo1() shows the bug. Here is a asm code generated for foo1(): foo1: .seh_endprologue vmovsd .LC0(%rip), %xmm2 vaddsd %xmm2, %xmm0, %xmm3 vsubsd %xmm3, %xmm0, %xmm0 vaddsd %xmm1, %xmm0, %xmm1 ; order of summation changed vaddsd %xmm2, %xmm1, %xmm0 ret .seh_endproc Here is an output of gcc -v: Using built-in specs. COLLECT_GCC=D:\bin\msys64\mingw64\bin\gcc.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-5.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --with-gxx-include-dir=/mingw64/include/c++/5.2.0 --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev4, Built by MSYS2 project' --with-bugurl=http://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld Thread model: posix gcc version 5.2.0 (Rev4, Built by MSYS2 project) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-Ofast' '-Wall' '-mavx' '-mtune=generic' '-march=x86-64' D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/cc1.exe -E -quiet -v -iprefix D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/ -D_REENTRANT foo.c -mavx -mtune=generic -march=x86-64 -Wall -Ofast -fpch-preprocess -o foo.i ignoring duplicate directory "D:/bin/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.2.0/include" ignoring nonexistent directory "C:/building/msys64/mingw64/include" ignoring nonexistent directory "/mingw64/include" ignoring duplicate directory "D:/bin/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.2.0/include-fixed" ignoring duplicate directory "D:/bin/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/include" ignoring nonexistent directory "C:/building/msys64/mingw64/x86_64-w64-mingw32/include" #include "..." search starts here: #include <...> search starts here: D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/include D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../include D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/include-fixed D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-Ofast' '-Wall' '-mavx' '-mtune=generic' '-march=x86-64' D:/bin/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/cc1.exe -fpreprocessed foo.i -quiet -dumpbase foo.c -mavx -mtune=generic -march=x86-64 -auxbase foo -Ofast -Wall -version -o foo.s GNU C11 (Rev4, Built by MSYS2 project) version 5.2.0 (x86_64-w64-mingw32) compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.3, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C11 (Rev4, Built by MSYS2 project) version 5.2.0 (x86_64-w64-mingw32) compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.3, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 6d1a96b0d4d4a024cf53bcf4b7004358 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-Ofast' '-Wall' '-mavx' '-mtune=generic' '-march=x86-64' D:/bin/msys64/min
