[Bug target/84033] powerpc64le -moptimize-swaps bad code with vec_vbpermq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84033 Breno Leitao changed: What|Removed |Added CC||brenohl at br dot ibm.com --- Comment #7 from Breno Leitao --- Hi Alan, I was not able to read the changelog and understand what are the exact versions that this bug is fixed. How can I read and get this information? I am asking this question because mongodb was hitting this issue[1], and the workaround was disabling optimization[2] during mongodb compilation. That said, we would like to re-enable the optimized compilation for mongodb[3], but we need this GCC fix on the distros first, so, I need to know which GCC version contains this fix and migrating to it prior to the re-enablement of the Mongodb optimization. I understand that this fix didn't make the GCC 8 first release, thus, there was a minor version update on GCC 6, 7 and 8 that contains this fix. Is my understanding correct? Thank you, Breno [1] https://jira.mongodb.org/browse/SERVER-33395 [2] https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/1758116 [3] https://bugs.launchpad.net/ubuntu/+source/mongodb/+bug/1758118
[Bug target/78386] [PPC] Optimization -O2 and higher cause math inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 Breno Leitao changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #12 from Breno Leitao --- Ack. Closing as 'Invalid'
[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543 Breno Leitao changed: What|Removed |Added CC||brenohl at br dot ibm.com --- Comment #5 from Breno Leitao --- I can reproduce this (or a very similar version of this) bug on my system. I am seeing this failure when compiling package yadifa-2.2.2 on Debian testing with (Debian 6.2.1-4) 6.2.1 20161119. If I use -O2 instead of -O3, I see no failure.
[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543 --- Comment #7 from Breno Leitao --- Created attachment 40182 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40182&action=edit gcc dump with pre processed file
[Bug libgcc/78576] New: [PPC] wrong long double to long int conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
Bug ID: 78576
Summary: [PPC] wrong long double to long int conversion
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: brenohl at br dot ibm.com
Target Milestone: ---
On ppc64le environment, I am facing an wrong conversion between long double and
long int.
This is my test case, which prints 27 instead of 26.
#include
#include
int main (){
long double a = 3;
long double b = 3;
long c = powl(a,b);
printf("%d\n", c);
}
It does not seem to be a rounding issue, since fesetround() is not affecting
the result.
I also changed the optimization levels, and it is not affecting the result.
[Bug libgcc/78576] [PPC] wrong long double to long int conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576 --- Comment #13 from Breno Leitao --- (In reply to Bill Schmidt from comment #11) > Breno, what is your environment? Which glibc is present? We found this problem originally on Debian[1], but we tested and reproduced it even on Big Endian distro. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845082
[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543 --- Comment #16 from Breno Leitao --- If it helps, the problem is reproducible on some other packages as well. Here is another example: https://nopaste.linux-dev.org/?1122124
[Bug c/78386] New: Powerpc64le: optimization -O2 and higher cause math inconsitency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 Bug ID: 78386 Summary: Powerpc64le: optimization -O2 and higher cause math inconsitency Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: brenohl at br dot ibm.com Target Milestone: --- When compiling fdlibm with O2 or higher, the math results are different. I just write a simple example, invoking jcos() and invoking it several times. If I use -O1 and -O2, the results are different. I dug further and found that the problem happens when using the optimization '-expensive-optimizations'. As for example: $ gcc -I. -g -static -O1 -fexpensive-optimizations .. -o opt_call $ gcc -I. -g -static -O1 .. -o call $ ./opt_call cosine total sum is: 0.33853897900538427 $ ./call cosine total sum is: 0.33853897900536206 I wrote a testcase to show this problem, please find it at https://github.com/leitao/fdlibm/tree/master/gcc_bug: In order to reproduce the problem, just run: $ git clone https://github.com/leitao/fdlibm.git $ cd fdlibm/gcc_bug $ make $ ./call $ ./opt_call If any other detail is required, I can dig further: Machine Information: $ gcc --version gcc (Debian 6.2.0-13) 6.2.0 20161109 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ uname -a Linux testing 4.7.0-1-powerpc64le #1 SMP Debian 4.7.8-1 (2016-10-19) ppc64le GNU/Linux
[Bug tree-optimization/78386] Powerpc64le: optimization -O2 and higher cause math inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 --- Comment #2 from Breno Leitao --- I did further tests with older versions, and the problem is also reproducible, so, this is not a regression. These are the versions I tested also: * gcc-5 (Debian 5.4.1-3) 5.4.1 20161019 * gcc-4 (Debian 4.9.4-2) 4.9.4
