The "long" type size seems to be platform dependent, causing hash value
overflow on implementations where "long" is 4 bytes. This addresses the
scenario.
Change-Id: I4e3c0df457e35b139dcc496d832210ba2cb849ba
[ROCm/clr commit: 1f8ead914a]
Relates to https://reviews.llvm.org/D150427,
Each printf call populates buffer with following data
1. Control DWord - contains info regarding stream, format string constness and size of data frame
(see http://gerrit-git.amd.com/c/lightning/ec/device-libs/+/857722 for more info)
2. Hash of the format string (if constant) else the format string itself
3. Printf arguments (each aligned to 8 byte boundary)
Change-Id: I7e320deb343921b4b4cfaf08a2be2883e0bc1f65
[ROCm/clr commit: 7b6a8f1702]
Newer GCC's seem to require this.
Change-Id: I85926d4fa552b772f2eb9f8ede7863a546c47f54
Signed-off-by: Jeremy Newton <Jeremy.Newton@amd.com>
[ROCm/clr commit: 70bdb7a597]
This fixes an issue in hostcall when processing printf of a C string.
The calculation to round-up the string size to the next data chunk
didn't include the extra byte for the null terminating character.
Change-Id: I4cf0c250fa4fda253b0db15be461819ffce76d32
[ROCm/clr commit: 8341fd31d1]
The first qword in the printf messages is called the control
qword. If the LSB is set, then the output of the printf is now
redirected to stderr instead of stdout.
Change-Id: I391e04e6e8e0f231fda56f3a6e02703bf50e1924
[ROCm/clr commit: e0ac6b4fc5]
Luca Bruni
Victor Zhang
Danylo Lytovchenko
Vikram
Jeremy Newton
Satyanvesh Dittakavi
agunashe
Siu Chi Chan
Sameer Sahasrabuddhe
Aryan Salmanpour