https://sourceware.org/bugzilla/show_bug.cgi?id=30865
--- Comment #1 from Nick Clifton <nickc at redhat dot com> --- (In reply to Fangrui Song from comment #0) > A side effect possibly from this commit is that 0x literals have different > behaviors from decimal literals and expressions. > > .text : { *(.text) } =0x90 # set the fill pattern to 0x90909090 > .text : { *(.text) } =0x90909090 # set the fill pattern to 0x90909090 > .text : { *(.text) } =144 # set the fill pattern to 0x00000090 > .text : { *(.text) } =0x90+0 # set the fill pattern to 0x00000090 > > This has been the case for ~20 years, so probably not worth changing, Agreed. > but I > felt obliged to point out this special behavior to warn users about 0x90 > 0x9090 0x909090 that are shorter than 4 bytes. So a documentation update is needed. In the course of investigating this I also discovered that the difference only applies to simple hexadecimal values specified with a 0x prefix. It does not apply to expressions involving hex numbers, eg 0x1 + 0x2, nor to hex values specified via a $ prefix, eg $9a, nor to hex values specified by a letter suffix, eg 9aH, nor to hex values specified with a magnitude, eg 0x9aK Anyway please take a look at the uploaded patch which updates the documentation and adds a new test case to make sure that the documented behaviour continues. -- You are receiving this mail because: You are on the CC list for the bug.