This is an archive of the discontinued LLVM Phabricator instance.

[flang] Distinguish intrinsic from non-intrinsic modules
ClosedPublic

Authored by klausler on Jan 31 2022, 10:13 AM.

Details

Summary

For "USE, INTRINSIC", search only for intrinsic modules;
for "USE, NON_INTRINSIC", do not recognize intrinsic modules.
Allow modules of both kinds with the same name to be used in
the same source file (but not in the same scoping unit, a
constraint of the standard that is now enforced).

The symbol table's scope tree now has a single instance of
a scope with a new kind, IntrinsicModules, whose children are
the USE'd intrinsic modules (explicit or not). This separate
"top-level" scope is a child of the single global scope and
it allows both intrinsic and non-intrinsic modules of the same
name to exist in the symbol table. Intrinsic modules' scopes'
symbols now have the INTRINSIC attribute set.

The search path directories need to make a distinction between
regular directories and the one(s) that point(s) to intrinsic
modules. I allow for multiple intrinsic module directories in
the second search path, although only one is needed today.

Diff Detail

Event Timeline

klausler created this revision.Jan 31 2022, 10:13 AM
klausler requested review of this revision.Jan 31 2022, 10:13 AM
klausler updated this revision to Diff 404595.Jan 31 2022, 10:16 AM

Rebase to current main branch.

PeteSteinfeld accepted this revision.Jan 31 2022, 10:27 AM

All builds, tests, and is formatted correctly and looks good.

This revision is now accepted and ready to land.Jan 31 2022, 10:27 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJan 31 2022, 1:31 PM

Hi, this change is failing to build on our bot: https://lab.llvm.org/buildbot/#/builders/160/builds/5706

/usr/include/c++/11/bits/char_traits.h:409:56: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ writing 15 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
  409 |         return static_cast<char_type*>(__builtin_memcpy(__s1, __s2, __n));
      |                                        ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~

Not sure how this lead to that but bisect points to it. FYI the "latest" gcc on the bot is gcc-11. I had some unrelated issues building with an older gcc so it may reproduce with any recent revision but not sure. (our clang based bots are fine)

Thanks, will revert or fix immediately.

It's clear how my patch would trigger recompilation of flang/tools/bbc/bbc.cpp but that warning looks bogus to me. I'm testing a patch to that flle that might avoid that call chain and dodge the warning.

Patch to work around bogus-looking GCC 11 warning in unmodified rebuilt code tests out with GCC 11 and has been applied.

That did the trick, thanks.