builder: make sure -fshort-enums is used consistently

The main change is in building the libraries, where -fshort-enums was
passed on RISC-V while other C files weren't compiled with this setting.

Note: the test already passed before this change, but it seems like a
good idea to explicitly test for enum size consistency.
There is also not a particular reason not to pass -fshort-enums on
RISC-V. Perhaps it's better to do it there too (on baremetal targets
that don't have to worry about binary compatibility).
This commit is contained in:
Ayke van Laethem
2020-04-05 18:19:26 +02:00
committed by Ayke
parent 8333c171f4
commit 639ec1e6ee
7 changed files with 13 additions and 2 deletions
+2
View File
@@ -20,6 +20,8 @@ int globalUnionSize = sizeof(globalUnion);
option_t globalOption = optionG;
bitfield_t globalBitfield = {244, 15, 1, 2, 47, 5};
int smallEnumWidth = sizeof(option2_t);
int fortytwo() {
return 42;
}
+3
View File
@@ -111,6 +111,9 @@ func main() {
println("option 2A:", C.option2A)
println("option 3A:", C.option3A)
// Check that enums are considered the same width in C and CGo.
println("enum width matches:", unsafe.Sizeof(C.option2_t(0)) == uintptr(C.smallEnumWidth))
// libc: test whether C functions work at all.
buf1 := []byte("foobar\x00")
buf2 := make([]byte, len(buf1))
+2
View File
@@ -134,6 +134,8 @@ extern int globalUnionSize;
extern option_t globalOption;
extern bitfield_t globalBitfield;
extern int smallEnumWidth;
// test duplicate definitions
int add(int a, int b);
extern int global;
+1
View File
@@ -55,4 +55,5 @@ option F: 11
option G: 12
option 2A: 20
option 3A: 21
enum width matches: true
copied string: foobar