Open Quuxplusone opened 7 years ago
Bugzilla Link | PR31625 |
Status | NEW |
Importance | P normal |
Reported by | hstong@ca.ibm.com |
Reported on | 2017-01-12 22:25:41 -0800 |
Last modified on | 2019-01-29 08:08:25 -0800 |
Version | trunk |
Hardware | PC Linux |
CC | erich.keane@intel.com, llvm-bugs@lists.llvm.org, neeilans@live.com, richard-llvm@metafoo.co.uk |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
This still exists in trunk today. I believe the problem in part is that IR
CodeGen doesn't differentiate between an initalized and uninitialized variable.
See: https://godbolt.org/z/vnhOMG
Note that:
@i_uninit = dso_local global i32 0, align 4, !dbg !0
@i_init_zero = dso_local global i32 0, align 4, !dbg !6
BOTH are i32 0, despite one being initialized and one not.
CodeGenModule.cpp (CodeGenModule::EmitGlobalVarDefinition) seems to do this
intentionally (see the else if(!InitExpr) condition, ~3493).
The comment claims that this is intentional. It seems to me that we could
replace the Init = line in that with llvm::UndefValue::get(D->getType()-
>getTypePtr());, however I'm not sure of the full consequences of that.
Additionally, some LLVM work would need to be done to correctly handle the bss
based on its init status.
Does anyone familiar with this code have guidance that they can give? The test
failures of the above suggested changes (to get the Clang done) is a pretty
massive list, but I'm OK doing them if we believe this is the right thing.
Based on my reading of:
http://eel.is/c++draft/dcl.init#10 and http://eel.is/c++draft/basic.stc.static
I think my version above is illegal, right? We presumably need some way to
identify which variables are "initialized in text" vs "initialized by rule" in
this case.
(In reply to Erich Keane from comment #2)
> Based on my reading of:
> http://eel.is/c++draft/dcl.init#10 and
> http://eel.is/c++draft/basic.stc.static
>
> I think my version above is illegal, right? We presumably need some way to
> identify which variables are "initialized in text" vs "initialized by rule"
> in this case.
Yes, zero-initialization produces defined values that can be inspected.
As for the semantics, the "initialized by rule" portion seems to specifically
be the zero-initialization that is performed by [basic.start.static] in the
absence of constant initialization. An object that needs dynamic initialization
goes into BSS (if all bytes should be zero as the result of zero-
initialization).
All other constant initialization (including zero-initializing as part of value-
initialization) is not considered for BSS when -fno-zero-initialized-in-bss is
in effect.
Alright, thanks for the confirmation.
I'll discuss with my LLVM folks how we can communicate the difference between "initialized in text" vs "initialized by rule". At the moment, I don't see a way to do so in IR.