Global structs with array members not being initialized.
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 624
- Forks
- 170
- PR merge metrics
- No merged PRs in 30d
Description
This issue is about static initializers for struct fields. I have a struct that contains an array. I have a global instance of the struct and I am attempting to initialize an array that is a member of that struct. The minimal example below illustrates the problem.
>$cat staticinit.c
typedef struct t_t{
int a[1];
} t;
t o1 = {.a = {1}};
int f(){
return o1.a[0];
}
When I build with cgeist, I see the following output:
>$ ../mlir-build/bin/cgeist -S --function=* ./staticinit.c -o staticinit.mlir
VarDecl 0x55e2a204b4b0 <./staticinit.c:5:1, col:17> col:3 used o1 't':'struct t_t' cinit
`-InitListExpr 0x55e2a204b6b8 <col:8, col:17> 't':'struct t_t'
`-InitListExpr 0x55e2a204b710 <col:14, col:16> 'int[1]'
`-IntegerLiteral 0x55e2a204b560 <col:15> 'int' 1
InitListExpr 0x55e2a204b6b8 't':'struct t_t'
`-InitListExpr 0x55e2a204b710 'int[1]'
`-IntegerLiteral 0x55e2a204b560 'int' 1
warning not initializing global: o1
And inspecting the resultant MLIR, I see that, indeed, my global o1 is being left uninitialized.
$ cat staticinit.mlir
module attributes {dlti.dl_spec = #dlti.dl_spec<#dlti.dl_entry<"dlti.endianness", "little">, #dlti.dl_entry<i64, dense<64> : vector<2xi32>>, #dlti.dl_entry<f80, dense<128> : vector<2xi32>>, #dlti.dl_entry<i1, dense<8> : vector<2xi32>>, #dlti.dl_entry<i8, dense<8> : vector<2xi32>>, #dlti.dl_entry<i16, dense<16> : vector<2xi32>>, #dlti.dl_entry<i32, dense<32> : vector<2xi32>>, #dlti.dl_entry<f16, dense<16> : vector<2xi32>>, #dlti.dl_entry<f64, dense<64> : vector<2xi32>>, #dlti.dl_entry<f128, dense<128> : vector<2xi32>>>, llvm.data_layout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128", llvm.target_triple = "x86_64-unknown-linux-gnu", "polygeist.target-cpu" = "x86-64", "polygeist.target-features" = "+cx8,+fxsr,+mmx,+sse,+sse2,+x87", "polygeist.tune-cpu" = "generic"} {
memref.global @o1 : memref<1x!llvm.struct<(array<1 x i32>)>> = uninitialized
func.func @f() -> i32 attributes {llvm.linkage = #llvm.linkage<external>} {
%0 = memref.get_global @o1 : memref<1x!llvm.struct<(array<1 x i32>)>>
%1 = "polygeist.memref2pointer"(%0) : (memref<1x!llvm.struct<(array<1 x i32>)>>) -> !llvm.ptr<struct<(array<1 x i32>)>>
%2 = llvm.getelementptr %1[0, 0] : (!llvm.ptr<struct<(array<1 x i32>)>>) -> !llvm.ptr<array<1 x i32>>
%3 = llvm.bitcast %2 : !llvm.ptr<array<1 x i32>> to !llvm.ptr<i32>
%4 = llvm.load %3 : !llvm.ptr<i32>
return %4 : i32
}
}
The important line in that output is this one:
memref.global @o1 : memref<1x!llvm.struct<(array<1 x i32>)>> = uninitialized
The behavior that I would expect here is that the global would be initialized. It seems like that warning should be a fail-stop condition. As it is, programs that produce that warning during compilation are miscompiled, with their globals left uninitialized.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the minimal staticinit.c example and run cgeist with the shown options to reproduce the warning and inspect staticinit.mlir. Trace how the InitListExpr for the array member is handled and verify that the generated memref.global contains the value 1 rather than being uninitialized; the misleading warning should no longer permit miscompilation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100