[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875 Martin Husemann martin at netbsd dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Husemann martin at netbsd dot org --- fixed on trunk
[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875 --- Comment #5 from Jan-Benedict Glaw jbg...@lug-owl.de --- Created attachment 30872 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30872action=edit Updated patch including testcase.
[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875 --- Comment #6 from jbglaw at gcc dot gnu.org --- Author: jbglaw Date: Fri Sep 20 19:00:02 2013 New Revision: 202796 URL: http://gcc.gnu.org/viewcvs?rev=202796root=gccview=rev Log: Work around buggy gas not properly sign-extending a 64bit value on a 32bit host PR target/56875 2013-09-20 Martin Husemann mar...@netbsd.org Jan-Benedict Glaw jbg...@lug-owl.de gcc/ * config/vax/vax.c (vax_output_int_move): Use D format specifier. * config/vax/vax.md (ashldi3, unnamed): Ditto. gcc/testsuite/ * gcc.target/vax/vax.exp: New. * gcc.target/vax/pr56875.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/vax/ trunk/gcc/testsuite/gcc.target/vax/pr56875.c trunk/gcc/testsuite/gcc.target/vax/vax.exp Modified: trunk/gcc/ChangeLog trunk/gcc/config/vax/vax.c trunk/gcc/config/vax/vax.md trunk/gcc/testsuite/ChangeLog
[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875 --- Comment #3 from Martin Husemann martin at netbsd dot org --- Of course I do not mind fixing gas, but the whole point of the D formatting code is to work around this assembler bug, and while this might be mostly irrelevant nowadays, isn't gcc supposed to work with other assemblers (like the VMS one) as well? Gas seems to be bug-compatible here. Overall, especially since this change is trivial, wouldn't it be best/easiest to apply it anyway?
[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875 --- Comment #4 from Jan-Benedict Glaw jbg...@lug-owl.de --- You're quite right, Martin! It's a simple fix on the GCC side working around a buggy gas, and it would also work with a fixed gas. However, gas isn't too simple to fix, at least not with a well-architected fix.
[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875 --- Comment #1 from Jan-Benedict Glaw jbg...@lug-owl.de --- The `gas' bug seems to only show up on 32bit host platform. Creating a cross-gas on a amd64 systems seems to always result in correct VAX binary output, even for old 2.21 releases. (Will further check this.) I tend to not fix GCC in this regard. Its output is correct, though doing hex output instead of negative decimals would work-around gas's bug. However, I think we'd better fix gas and possibly add a version check to gcc?
[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875
--- Comment #2 from Jan-Benedict Glaw jbg...@lug-owl.de ---
This is gas's tc-vax.c:
3158 if ((is_absolute) (expP-X_op != O_big))
3159 {
3160 /* If nbytes 4, then we are scrod. We
3161 don't know if the high order bytes
3162 are to be 0xFF or 0x00. BSD4.2 RMS
3163 say use 0x00. OK --- but this
3164 assembler needs ANOTHER rewrite to
3165 cope properly with this bug. */
3166 md_number_to_chars (p + 1, this_add_number,
3167 min (sizeof (valueT),
3168(size_t) nbytes));
3169 if ((size_t) nbytes sizeof (valueT))
3170 memset (p + 1 + sizeof (valueT),
3171 '\0', nbytes - sizeof (valueT));
3172 }
[...]
This is for small values (ie. -1 fitting in a 32bit valueT) and it doesn't
properly sign-extend in this case. Taking into account the next couple lines
(not shown here), this part of the code needs to rethought.
A workaround would be to actually place an all-hex value (through GCC) here,
but that wouldn't fix gas for any hand-written assembler.
