In SDCC 4.5.1 (15267 for us) it was possible to pass 8 bit types to va_args without promotion by explicitly casting them. That does not appear to work in SDCC 4.6.2 (16705 for us).
Is this change by design (and so library changes should be made on our end) or is something that should be looked into as a bug?
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This was an intentional change in SDCC 4.5.15 (see also section 1.5 of the manual, which list such breaking changes).
For sm83 (and a few other ports), the benefits of the old behaviour (saving a byte of stack space) were small, and not considered worth the drawbacks (standard non-compliance in --std-sdccXX mode, incompatibility of code compiled with --std-sdccXX vs. --std-cXX, 8-bit pushes often having slightly larger code size).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, I missed it when reading that section before posting. I think it was a little hard to parse the sentence as indicating a change where some ports no longer support the behavior, but I get it now.
• In 4.5.15, the omission of integer promotions on explicitly cast variable arguments only happens for the mcs51, ds390, mos6502, mos65c02, pic14 and pic16 ports.
(moved reply to the correct part of the thread)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In SDCC 4.5.1 (15267 for us) it was possible to pass 8 bit types to va_args without promotion by explicitly casting them. That does not appear to work in SDCC 4.6.2 (16705 for us).
Is this change by design (and so library changes should be made on our end) or is something that should be looked into as a bug?
Thanks!
This was an intentional change in SDCC 4.5.15 (see also section 1.5 of the manual, which list such breaking changes).
For sm83 (and a few other ports), the benefits of the old behaviour (saving a byte of stack space) were small, and not considered worth the drawbacks (standard non-compliance in --std-sdccXX mode, incompatibility of code compiled with --std-sdccXX vs. --std-cXX, 8-bit pushes often having slightly larger code size).
Thanks, I missed it when reading that section before posting. I think it was a little hard to parse the sentence as indicating a change where some ports no longer support the behavior, but I get it now.
(moved reply to the correct part of the thread)
Last edit: bbbbbr 2 days ago