Ticket #501 (Fixed)Fri Nov 27 15:44:33 UTC 2020
cc 5.85: Designated initialisers incorrectly initialise anonymous unions
| Reported by: | Jeffrey Lee (213) | Severity: | Major |
| Part: | RISC OS: C/C++ toolchain | Release: | |
| Milestone: | Status | Fixed |
Details by Jeffrey Lee (213):
Using designated initialisers to initialise a struct containing anonyomous unions results in the values being written to the wrong location. The equivalent code using named unions appears to work OK (see attached code).
*cc two.c
Norcroft RISC OS ARM C vsn 5.85 [22 Oct 2020]
*two
00000000 00000005
00000005 00000000
Note: attempting to initialise the .y or .b members of v results in an internal compiler error.
Changelog:
Modified by Jeffrey Lee (213) Fri, November 27 2020 - 15:45:08 GMT
- Attachment added: two
Modified by Crispian Daniels (10122) Sat, September 14 2024 - 10:51:06 GMT
- Attachment added: three
I noticed that I had run into a problem with anonymous structs in a union, not anonymous unions in a struct, after I had run some variations on the attachment named two. The assembly language output may be of interest (see attachment).
The variations are as follows:
threeA : the same as two
threeB : threeA without named unions
threeC : simple assignment instead of initialisers, x incremented by a subroutine, printf omitted
threeD : threeC omitting the named unions
threeE : threeC with structs in a union substituted for unions in a struct
threeF : threeE omitting the named structs
These are my thoughts on the assembly language output:
threeA : the words in v’s initializer constant are in reverse order
threeB : the words are still in reverse order after the STMDB
threeC : this looks correct
threeD : this also looks correct
threeE : the anonymous struct increment is 8 bytes too low, the rest looks correct
threeF : the increment is again 8 bytes too low
The output from threeF is cut short by an ‘Internal inconsistency’ error as seen in Ticket #500.
Modified by Crispian Daniels (10122) Sat, September 14 2024 - 10:54:46 GMT
Attachment three is a zip file created by !SparkFS.
Modified by Sprow (202) Wed, September 18 2024 - 21:42:57 GMT
- Attachment added: four.zip
Noseying in your ‘three’ ZIP file attachment, a few comments:
- What version of SparkFS did you use? Looks like you have the version that doesn’t stamp small files correctly (they all came out as type ‘Data’ here)
- Tests A/B work OK with cc 5.93, I note from the disassemblies provided you had an older version 5.89, worth updating for the latest fixes
- Tests C/D still OK (same binary produced)
- Tests E/F look like a different issue to the one about initialisers reported here – better to open a new ticket, or report it to ROOL
Attached are the output files from cc 5.93 for comparison.
Modified by Crispian Daniels (10122) Thu, September 19 2024 - 06:43:43 GMT
I used DDE30d and SparkFS 1.46 from NutPi Release 8, 23 Feb 2022. The stamps appear to have changed in transit – SparkFS shows ‘Data’ in the downloaded file but ‘Text’ and ‘Makefile’ in the ZIP file I prepared. I noticed ‘Attachment’ four has ‘.zip’ at the end of the filename – I can try including that in the filename of my next upload.
I installed DDE31e in RPCEmu and agree that tests A/B work OK with cc 5.93.
Yes, tests E/F are a different issue.
Modified by Sprow (202) Thu, September 19 2024 - 17:51:12 GMT
- Status changed from Open to Fixed
I used DDE30d and SparkFS 1.46
SparkFS 1.46 is new enough to have the fix for not stamping files correctly, so it’s not that. I notice (inspecting the ZIP in a hex editor) that none of the files have the ‘ARC0’ marker where the RISC OS meta data is stored, as though it was written using a PC utility. Nevermind, it was only a passing observation.
Glad to hear your DDE31e confirms A/B (and C/D) are OK. I’ll close this ticket in that case, and leave you to create a new one for E/F or to email a report to ROOL whichever is easiest for you.
