https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #25 from Aaron Sawdey ---
Created attachment 116201
--> https://bugs.kde.org/attachment.cgi?id=116201&action=edit
strcmp test case, ppc64le gpr version
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #26 from Aaron Sawdey ---
Created attachment 116202
--> https://bugs.kde.org/attachment.cgi?id=116202&action=edit
strcmp test case, ppc64le p8 vsx version
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #27 from Aaron Sawdey ---
Created attachment 116203
--> https://bugs.kde.org/attachment.cgi?id=116203&action=edit
strcmp test case, ppc64le p9 vsx version
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #28 from Aaron Sawdey ---
I've just attached asm generated by current gcc trunk for this test case:
#include
int main ()
{
char str1[15];
char str2[15];
strcpy(str1, "abcdef");
strcpy(str2, "ABCDEF"
https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #31 from Aaron Sawdey ---
I tested this on a target that does support 32-bit (power8 BE) and it looked
good. Various strcmp/memcmp expansion tests do not see errors from valgrind.
There were no additional regtest fails between unpatched and
https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #34 from Aaron Sawdey ---
Carl, yes I ran regtest on power8 BE (which supports 32 and 64 bit abi) with
and without the patch and didn't see any differences.
Mark, it's on my list to back port the gcc code gen change to gcc8.
https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #17 from Aaron Sawdey ---
Julian,
The analysis is ok. The code that follows on either branch looks for a zero
byte in the process of producing the final result.
What happens after the subf./beq is that a cmpb with 0 is done to check that
https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #19 from Aaron Sawdey ---
Sorry if that was unclear. Yes, the branch on uninitialized data is intended
and is caught and fixed by the cmpb with 0 that happens on both paths.
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #22 from Aaron Sawdey ---
It is always hardwired to avoid 4k boundary crossings.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=386945
Aaron Sawdey changed:
What|Removed |Added
CC||acsaw...@linux.vnet.ibm.com
--- Comment #13
https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #37 from Aaron Sawdey ---
The fix is in gcc 9 trunk. I'm working on the gcc 8 back port now so it's
definitely not in 8.2, hopefully will be in 8.3 when that comes out.
--
You are receiving this mail because:
You are watchi
https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #38 from Aaron Sawdey ---
The fix for this is checked in to gcc-8-branch svn revision 266578. I believe
this will show up in gcc 8.3.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #42 from Aaron Sawdey ---
I think you're on the right track with ldbrx. The only difference between the
code that gcc is generating and what is in glibc is ldbrx vs ld, here is what
is in glibc trunk:
/* For short string up
https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #55 from Aaron Sawdey ---
Mark,
No alignment constraints on ldbrx, not having to check the alignment is what
makes this whole thing work. If I had to do runtime alignment checks it would
be too much code to generate inline.
--
You are
14 matches
Mail list logo
