http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
jphartm...@gmail.com changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
--- Comment #14 from jphartmann at gmail dot com
2011-08-02 14:45:24 UTC ---
Hello, Jakub.
Thanks for helping me regain sanity.
So was I let astray by trying to set up a separate root, which I had
to populate with all kinds of stuff. And I als
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
--- Comment #12 from Jakub Jelinek 2011-08-02
14:12:45 UTC ---
Just ../configure --target s390x-linux, I don't even have s390x binutils here,
so I can just compile into assembly (all that I need for compiler bugfixing).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
--- Comment #11 from jphartmann at gmail dot com
2011-08-02 14:04:29 UTC ---
With the slr, bc 5,x is the correct mask, or course. So it must be something
else.
As I understand it s390 and s390x are exactly the same except the default -m31.
But
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
--- Comment #10 from Jakub Jelinek 2011-08-02
13:36:53 UTC ---
I think the testcase from your exec charset for Linux would map to:
struct oper { char *digits; char sign; };
struct oper oper0 = {"\xf9\xf0\xf0\xf0\xf0\xf0\xf0\xf0\xf0", 'N'};
struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
--- Comment #9 from jphartmann at gmail dot com
2011-08-02 13:18:47 UTC ---
That is good to know. However, this problem is with -fexec-charset=IBM-1047.
You cannot run the output of that on the ASCII z/Linux.
Can I trouble you to send me you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
--- Comment #7 from jphartmann at gmail dot com
2011-08-02 10:18:28 UTC ---
The stripped-down test case gives this (expected) output on linux:
9 vs 4 is 1
4 vs 9 is -1
And this (faulty) output on VM:
9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
--- Comment #6 from jphartmann at gmail dot com
2011-08-02 10:16:17 UTC ---
Created attachment 24889
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24889
Stripped-down test case.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
--- Comment #5 from jphartmann at gmail dot com
2011-08-02 09:59:44 UTC ---
Because the unoptimised code has a je at that place. And putting anything
after the assignment generates correct code. And debug code after the loop
shows that it falls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
--- Comment #4 from Jakub Jelinek 2011-08-02
09:28:32 UTC ---
Why do you think so?
slr; jnhe is what you get for e.g.
void bar (void);
int foo (int x, int y)
{
int d = x - y;
if (d == 0)
bar ();
return d;
}
slr %r12,%r3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
--- Comment #3 from jphartmann at gmail dot com
2011-08-02 08:37:44 UTC ---
Adding a dummy assignment to a global value that the optimiser cannot figure to
be useless fixes the problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
--- Comment #2 from jphartmann at gmail dot com
2011-08-02 08:26:37 UTC ---
Linux bigserv 2.6.34.8-68.fc13.x86_64 #1 SMP Thu Feb 17 15:03:58 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
gcc -fexec-charset=IBM-1047 -Wno-format -D__ZVM__ -D__CMS__ -U _
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49942
--- Comment #1 from jphartmann at gmail dot com
2011-08-02 08:22:43 UTC ---
Created attachment 24888
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24888
The compiler output
Line 3664 (.LVL333:) contains jnhe. It should have been jne, or t
15 matches
Mail list logo
