[flang-commits] [flang] [FLANG][Lower] WIP Support for BOZ assigning into a variable (PR #96651)

[Mats Petersson via flang-commits]

Leporacanthicus wrote:

> > If lowering has the guarantee that the "evaluate::Boz" it sees in evaluate::Expr must be always converted to integers, this makes sense, but I wonder if semantic should not be rewriting the Boz here based on the context as it is done in other cases. @klausler, is there a reason the BOZ is not converted in this case? Is it safe to assume all leftover BOZ literal constants can be dealt as INTEGER(16)?
> 
> Semantics should report an error here, actually. A BOZ literal can't appear here.
> 
> (EDIT: To get ahead of a predicted response: yes, I'm aware that this context is allowed in F'2023. When we get around to supporting it, semantics will have to convert the BOZ literal to a typed constant, like it does everywhere else that a BOZ can appear.)

So there are real world use-cases (we can argue whether that's correct or not, but it's a fact that it exists - I believe gfortran has supported this as an extension for a while, but that's just a guess from my side). The example I have that set this change into action is:

https://github.com/OpenRadioss/OpenRadioss/blob/main/engine/source/interfaces/int22/i22datainit.F#L725

 It is one of the last puzzle pieces to make that application compile with this compiler. 
 
I'm happy to implement it through a different route, like rewriting it in semantics, but I may need a bit of a hint as to how that should be done. I basically just took the "we're hitting a TODO here, so I'll find a way to make it not stop compiling".
 
The INTEGER(16) hard-coded is a bit excessive, I think we can figure out "how many bits are present", but I wanted to get feedback before I spend too much time on "the wrong solution". And it does sound like there may be a different, more right way. 

https://github.com/llvm/llvm-project/pull/96651