https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
--- Comment #11 from AJM <amelvill at umich dot edu> --- Thanks for all your suggestions, they're very helpful! >'-falign-commons' > By default, 'gfortran' enforces **proper** alignment of all variables > in a 'COMMON' block by padding them as needed... I am not sure what "proper" means in this context, proper for which language, which architecture? All of them? What's "proper" for AMD64 isn't proper for i386, and what's proper for Fortran might not be proper for C, right? What about byte endianness? > My guess would be that a common block > is simply considered to be a chunk of memory under > DWARF5. > It provides a base address and one needs to > know how to compute offsets into that chunk (including > dealing with any padding). My tests seem to show that this is the case so far too. It seems a bit weird to me because GCC is able to handle things like individual int "extern" variables in C, which would seem to have a very similar issue (memory stored in a different object file, in an ad-hoc manner with no prescribed structure or packing as an interface). The only thing that I can think of that's different is the fact that gfortran generates a .mod file, which I'm guessing (?) is some kind of binary interface definition (like a precompiled header?); I'm really not sure what it does, but there is no .mod file generated for "othermodule", only for somemodule (which matches the file name). At one point I was just wondering if all I needed to do was generate a .mod file for othermodule somehow (the common 'module'), but I noticed that the symbols were stored directly in the .o file, and I started to wonder if the .mod file served any purpose at all. > the Fortran processor (in this case gfortran) > and its companion C processor (gcc) have the same conventions regarding > layout of variables etc. I was hoping this was the case, thanks for confirming that. > Maybe, if you show the code above to whoever's in charge, that might > cause that person to reconsider :-) We've discussed it at great length, these sorts of things have to happen in stages I think. I have informed them of the risks and downsides of not doing this now (I have been detailed and clear in my findings, including possible portability / reliability problems and UB problems, additional time spent doing maintenance, and now also debugging issues). They have decided to accept the risks and inefficiencies. Given the circumstances a rewrite is not on the table; the decision is final and my job now is to support them as best I can. It's hard to allocate limited resources, there is no lack of work here. That's about all I can say on that I guess. This is not the first time I have entered a job with a codebase that had UB, in fact, I would say I have never NOT had a problem with UB at any place I've ever worked. Personally, I work hard not to introduce more, fix it when I can, and try and help coders avoid adding more.
