agozillon wrote: > > As an aside, there is an argument that in either case whether Flang is > > incorrect or otherwise, you probably do not want common linkage to echo > > onto the entry globals as by definition they are not compatible, you could > > of course shrug that off and say it's a user error which is the other side > > of the coin. > > I can catch common linkage late, use weak for the entry, and we don't change > anything else. I think "common" linkage for "common" blocks is wrong, but I > have no interest to die on this hill. The names sound so alike, maybe that's > why they were picked, or maybe they really ensure zero initialized memory and > want common, not weak, linkage. >
Yeah, I haven't got a clue about how strict/unstrict the fortran specification currently is on this unfortunately, but Flang makes sure all globals and common blocks are zero initialized at the moment and they utilise common linkage for that. There is also an incredibly common set of flags most Fortran compilers support where you can specify that you wish specific variable types to be zero/default initialized. It's something Flang doesn't support at the moment but we are hoping to add to Flang in the near future as it's a fairly frequent request, as un-initialized variables are a big source of debug headaches in larger code bases where other prior Fortran compilers have just decided they'll zero initialize things by default or users have just forgotten about this lovely aspect of Fortran. But yeah weird edge case that we unfortunately need to support, so I appologies for that. > My suggestion is as follows: I'll do the common -> weak translation > @agozillon suggested above when we do the entry generation. I'll add a > compile time test for a common global. You add some common block compile time > and/or runtime test as follow up to ensure we actually test the common block > case, especially at runtime. (I'm honestly not versed well enough in fortran > to ensure I get the nekbone case right.) > > I'll update the PR today, I hope, and you can sign off on it. > > Sounds good? Thank you very much @jdoerfert and I am sorry for the bother. This sounds good to me, I'll aim to get a PR with the runtime tests up today and test alongside your new changeset and approve your PR if it's all looking good. I may need someone else to merge the test PR once approved though if the approvals are a little later (unless it's not time sensitive, then I can check in next week and merge) as I'll be unavailable due to preparing to travel/travelling for a few days. https://github.com/llvm/llvm-project/pull/200964 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
