Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3 |
|
#
c1a750b8 |
| 15-Aug-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang] Make sure range is valid (#104281)
Attempt to solve #102495
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1 |
|
#
0ee0eeb4 |
| 23-Jul-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang] Enhance location information (#95862)
Add inclusion location information by using FusedLocation with
attribute.
More context here:
https://discourse.llvm.org/t/rfc-enhancing-location-in
[flang] Enhance location information (#95862)
Add inclusion location information by using FusedLocation with
attribute.
More context here:
https://discourse.llvm.org/t/rfc-enhancing-location-information/79650
show more ...
|
Revision tags: llvmorg-20-init |
|
#
5024a6ec |
| 11-Jul-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang][preprocessor] Support __TIMESTAMP__ (#98057)
Support the predefined macro __TIMESTAMP__ as interpreted by GCC. It
expands to a character literal with the time of last modification of the
t
[flang][preprocessor] Support __TIMESTAMP__ (#98057)
Support the predefined macro __TIMESTAMP__ as interpreted by GCC. It
expands to a character literal with the time of last modification of the
top-level source file in asctime(3) format, e.g. "Tue Jul 4 10:18:05
1776".
show more ...
|
Revision tags: llvmorg-18.1.8 |
|
#
86bee819 |
| 13-Jun-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang][preprocessor] Fixed-form continuation across preprocessing di… (#95332)
…rective
Implement fixed-form line continuation when the continuation line is the
result of text produced by an #i
[flang][preprocessor] Fixed-form continuation across preprocessing di… (#95332)
…rective
Implement fixed-form line continuation when the continuation line is the
result of text produced by an #include or other preprocessing directive.
This accommodates the somewhat common practice of putting dummy or
actual arguments into a header file and #including it into several code
sites.
Fixes https://github.com/llvm/llvm-project/issues/78928.
show more ...
|
Revision tags: llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1 |
|
#
f7a15e00 |
| 01-Mar-2024 |
Peter Klausler <35819229+klausler@users.noreply.github.com> |
[flang] Use module file hashes for more checking and disambiguation (#80354)
f18's module files are Fortran with a leading header comment containing
the module file format version and a hash of the
[flang] Use module file hashes for more checking and disambiguation (#80354)
f18's module files are Fortran with a leading header comment containing
the module file format version and a hash of the following contents.
This hash is currently used only to protect module files against
corruption and truncation.
Extend the use of these hashes to catch or avoid some error cases. When
one module file depends upon another, note its hash in additional module
file header comments. This allows the compiler to detect when the module
dependency is on a module file that has been updated. Further, it allows
the compiler to find the right module file dependency when the same
module file name appears in multiple directories on the module search
path.
The order in which module files are written, when multiple modules
appear in a source file, is such that every dependency is written before
the module(s) that depend upon it, so that their hashes are known.
A warning is emitted when a module file is not the first hit on the
module file search path.
Further work is needed to add a compiler option that emits (larger)
stand-alone module files that incorporate copies of their dependencies
rather than relying on search paths. This will be desirable for
application libraries that want to ship only "top-level" module files
without needing to include their dependencies.
Another future work item would be to admit multiple modules in the same
compilation with the same name if they have distinct hashes.
show more ...
|
Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
c87e94b0 |
| 12-Jan-2024 |
jeanPerier <jperier@nvidia.com> |
[flang] Get ProvenanceRange from CharBlock starting with expanded macro (#77791)
When a CharBlock starts with an expanded macro but does not end in this
macro expansion, GetProvenanceRange fails to
[flang] Get ProvenanceRange from CharBlock starting with expanded macro (#77791)
When a CharBlock starts with an expanded macro but does not end in this
macro expansion, GetProvenanceRange fails to return a ProvenanceRange
which may cause error message to be emitted without location or lowering
to emit code without source location (which is problematic if this code
contains calls to procedures defined in the same file since LLVM will
later crash with the error:
"inlinable function call in a function with a DISubprogram location must
have a debug location"
Fix this situation by returning the ProvenanceRange starting at the
replaced macro reference.
show more ...
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
e12ffe6a |
| 23-Jun-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Honor #line and related preprocessing directives
Extend the SourceFile class to take account of #line directives when computing source file positions for error messages. Adjust the output of
[flang] Honor #line and related preprocessing directives
Extend the SourceFile class to take account of #line directives when computing source file positions for error messages. Adjust the output of #line directives to -E output so that they reflect any #line directives that were in the input.
Differential Revision: https://reviews.llvm.org/D153910
show more ...
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init |
|
#
042c964d |
| 13-Jan-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fix defined I/O semantics crash & missing errors that exposed it
Semantics crashes when emitting runtime derived type information tables for a type that has user-defined I/O procedures decla
[flang] Fix defined I/O semantics crash & missing errors that exposed it
Semantics crashes when emitting runtime derived type information tables for a type that has user-defined I/O procedures declared outside the type with explicit INTERFACE blocks (as opposed to a GENERIC binding within the type). This is due to the runtime table constructor adding a table entry for each specific procedure of any explicit interface of the right kind (e.g., READ(UNFORMATTED)) that it found, rather than just the ones that pertain to the derived type in question. But semantics also wasn't checking such interfaces for distinguishable specific procedures, either.
Clean these up, improve the spelling of defined I/O procedure kinds in error messages ("read(formatted)" rather than "READFORMATTED"), and make error messages stemming from macro expansions only have one "error:" prefix on the original message so that a new test would work.
Differential Revision: https://reviews.llvm.org/D142769
show more ...
|
Revision tags: llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1 |
|
#
8df63a23 |
| 27-Jul-2022 |
Peixin Qiao <qiaopeixin@huawei.com> |
[flang] Support the color diagnostics on scanning, parsing, and semantics
The options -f{no-}color-diagnostics have been supported in driver. This supports the behaviors in scanning, parsing, and se
[flang] Support the color diagnostics on scanning, parsing, and semantics
The options -f{no-}color-diagnostics have been supported in driver. This supports the behaviors in scanning, parsing, and semantics, and the behaviors are exactly the same as the driver.
To illustrate the added behaviour, consider the following input file: ```! file.f90 program m integer :: i = k end ``` In the following invocations, "error: Must be a constant value" _will be_ formatted: ``` $ flang-new file.f90 error: Semantic errors in file.f90 ./file.f90:2:18: error: Must be a constant value integer :: i = k ``` Note that "error: Semantic errors in file.f90" is also formatted, which is supported in https://reviews.llvm.org/D126164.
Also note that only "error", "warning" and "portability" are formatted. Check the following input file: ```! file2.f90 program m integer :: i = end ``` ``` $ flang-new test2.f90 error: Could not parse test2.f90 ./test2.f90:2:11: error: expected '(' integer :: i = ^ ./test2.f90:2:3: in the context: statement function definition integer :: i = ^ ... ``` The "error: Could not parse test2.f90" and "error: expected '('" are formatted. Others such as "in the context" are not formatted yet, which may or may not be supported.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D126166
show more ...
|
Revision tags: llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
#
cd03e96f |
| 23-Mar-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Add & use a better visit() (take 2)
Adds flang/include/flang/Common/log2-visit.h, which defines a Fortran::common::visit() template function that is a drop-in replacement for std::visit().
[flang] Add & use a better visit() (take 2)
Adds flang/include/flang/Common/log2-visit.h, which defines a Fortran::common::visit() template function that is a drop-in replacement for std::visit(). Modifies most use sites in the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution time, which forces implementations to build dispatch tables. This new common::visit() is O(log2 N) in the number of alternatives in a variant<>, but that N tends to be small and so this change produces a fairly significant improvement in compiler build memory requirements, a 5-10% improvement in compiler build time, and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit() to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments are referred to std::visit(), pending further work.
This change is enabled only for GCC builds with GCC >= 9; an earlier attempt (D122441) ran into bugs in some versions of clang and was reverted rather than simply disabled; and it is not well tested with MSVC. In non-GCC and older GCC builds, common::visit() is simply an alias for std::visit().
show more ...
|
#
4ca111d4 |
| 28-Mar-2022 |
Andrzej Warzynski <andrzej.warzynski@arm.com> |
Revert "[flang] Add & use a better visit()"
This reverts commit 2ab9990c9eb79682a4d4b183dfbc7612d3e55328. It has caused multiple build failures: * https://lab.llvm.org/buildbot/#/builders/177/build
Revert "[flang] Add & use a better visit()"
This reverts commit 2ab9990c9eb79682a4d4b183dfbc7612d3e55328. It has caused multiple build failures: * https://lab.llvm.org/buildbot/#/builders/177/builds/4346 * https://lab.llvm.org/buildbot/#/builders/180/builds/3803 * https://lab.llvm.org/buildbot/#/builders/175/builds/10419 * https://lab.llvm.org/buildbot/#/builders/191/builds/4318 * https://lab.llvm.org/buildbot/#/builders/173/builds/4274 * https://lab.llvm.org/buildbot/#/builders/181/builds/4297
All these bots failed with a time-out: ``` command timed out: 1200 seconds without output running [b'ninja', b'-j', b'32'], attempting to kill ``` I'm guessing that that's due to template instantiations failing at some point (https://reviews.llvm.org/D122441 introduced a custom implementation of std::visit). Everything seems fine when either: * building on X86 with GCC or Clang (tested with GCC 9.3 and Clang 12) * building on AArch64 with GCC (tested with GCC 11)
show more ...
|
#
2ab9990c |
| 23-Mar-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Add & use a better visit()
Adds flang/include/flang/Common/visit.h, which defines a Fortran::common::visit() template function that is a drop-in replacement for std::visit(). Modifies most
[flang] Add & use a better visit()
Adds flang/include/flang/Common/visit.h, which defines a Fortran::common::visit() template function that is a drop-in replacement for std::visit(). Modifies most use sites in the front-end and runtime to use common::visit().
The C++ standard mandates that std::visit() have O(1) execution time, which forces implementations to build dispatch tables. This new common::visit() is O(log2 N) in the number of alternatives in a variant<>, but that N tends to be small and so this change produces a fairly significant improvement in compiler build memory requirements, a 5-10% improvement in compiler build time, and a small improvement in compiler execution time.
Building with -DFLANG_USE_STD_VISIT causes common::visit() to be an alias for std::visit().
Calls to common::visit() with multiple variant arguments are referred to std::visit(), pending further work.
Differential Revision: https://reviews.llvm.org/D122441
show more ...
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
#
d7ea6068 |
| 18-Feb-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Avoid crash case in provenance mapping
When a contiguous range of a cooked character stream is being mapped to a range of source provenance, the code was assuming that the "end()" position o
[flang] Avoid crash case in provenance mapping
When a contiguous range of a cooked character stream is being mapped to a range of source provenance, the code was assuming that the "end()" position of the input range -- being the character immediately after the range -- would also follow the range's source provenance. This isn't always the case.
Modify the code to work with the true last character of the input range (at end()-1) and to also cope with cases when that last position truly maps to an earlier provenance, which can happen when the prescanner has inserted a space into the cooked character stream.
Differential Revision: https://reviews.llvm.org/D121124
show more ...
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init |
|
#
52a1346b |
| 26-Jan-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Distinguish intrinsic from non-intrinsic modules
For "USE, INTRINSIC", search only for intrinsic modules; for "USE, NON_INTRINSIC", do not recognize intrinsic modules. Allow modules of both
[flang] Distinguish intrinsic from non-intrinsic modules
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.
Differential Revision: https://reviews.llvm.org/D118631
show more ...
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
#
3338ef93 |
| 23-Jul-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Produce proper "preprocessor output" for -E option
Rename the current -E option to "-E -Xflang -fno-reformat".
Add a new Parsing::EmitPreprocessedSource() routine to convert the cooked char
[flang] Produce proper "preprocessor output" for -E option
Rename the current -E option to "-E -Xflang -fno-reformat".
Add a new Parsing::EmitPreprocessedSource() routine to convert the cooked character stream output of the prescanner back to something more closely resembling output from a traditional preprocessor; call this new routine when -E appears.
The new -E output is suitable for use as fixed form Fortran source to compilation by (one hopes) any Fortran compiler. If the original top-level source file had been free form source, the output will be suitable for use as free form source as well; otherwise there may be diagnostics about missing spaces if they were indeed absent in the original fixed form source.
Unless the -P option appears, #line directives are interspersed with the output (but be advised, f18 will ignore these if presented with them in a later compilation).
An effort has been made to preserve original alphabetic character case and source indentation.
Add -P and -fno-reformat to the new drivers.
Tweak test options to avoid confusion with prior -E output; use -fno-reformat where needed, but prefer to keep -E, sometimes in concert with -P, on most, updating expected results accordingly.
Differential Revision: https://reviews.llvm.org/D106727
show more ...
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
#
0eb3299d |
| 23-Apr-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Fix crash from -DMACRO= with empty replacement
Such macros were exposing some edge cases in the preprocessor regarding empty tokens.
Differential Revision: https://reviews.llvm.org/D101207
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
#
0d8331c0 |
| 18-Mar-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Refine symbol sorting
Replace semantics::SymbolSet with alternatives that clarify whether the set should order its contents by source position or not. This matters because positionally-orde
[flang] Refine symbol sorting
Replace semantics::SymbolSet with alternatives that clarify whether the set should order its contents by source position or not. This matters because positionally-ordered sets must not be used for Symbols that might be subjected to name replacement during name resolution, and address-ordered sets must not be used (without sorting) in circumstances where the order of their contents affects the output of the compiler.
All set<> and map<> instances in the compiler that are keyed by Symbols now have explicit Compare types in their template instantiations. Symbol::operator< is no more.
Differential Revision: https://reviews.llvm.org/D98878
show more ...
|
#
46ade6d0 |
| 16-Mar-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Order Symbols by source provenance
In parser::AllCookedSources, implement a map from CharBlocks to the CookedSource instances that they cover. This permits a fast Find() operation based on
[flang] Order Symbols by source provenance
In parser::AllCookedSources, implement a map from CharBlocks to the CookedSource instances that they cover. This permits a fast Find() operation based on std::map::equal_range to map a CharBlock to its enclosing CookedSource instance.
Add a creation order number to each CookedSource. This allows AllCookedSources to provide a Precedes(x,y) predicate that is a true source stream ordering between two CharBlocks -- x is less than y if it is in an earlier CookedSource, or in the same CookedSource at an earlier position.
Add a reference to the singleton SemanticsContext to each Scope.
All of this allows operator< to be implemented on Symbols by means of a true source ordering. From a Symbol, we get to its Scope, then to the SemanticsContext, and then use its AllCookedSources reference to call Precedes().
Differential Revision: https://reviews.llvm.org/D98743
show more ...
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init |
|
#
6110e771 |
| 26-Jan-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Search for #include "file" in right directory (take 2)
Make the #include "file" preprocessing directive begin its search in the same directory as the file containing the directive, as other
[flang] Search for #include "file" in right directory (take 2)
Make the #include "file" preprocessing directive begin its search in the same directory as the file containing the directive, as other preprocessors and our Fortran INCLUDE statement do.
Avoid current working directory for all source files except the original.
Resolve tests.
Differential Revision: https://reviews.llvm.org/D95481
show more ...
|
#
e8785890 |
| 26-Jan-2021 |
Andrzej Warzynski <andrzej.warzynski@arm.com> |
Revert "[flang] Search for #include "file" in right directory"
This reverts commit d987b61b1dce9948801ac37704477e7c257100b1.
As pointed out in https://reviews.llvm.org/D95388, the reverted commit c
Revert "[flang] Search for #include "file" in right directory"
This reverts commit d987b61b1dce9948801ac37704477e7c257100b1.
As pointed out in https://reviews.llvm.org/D95388, the reverted commit causes build failures in the following Flang buildbots: * http://lab.llvm.org:8011/#/builders/32/builds/2642 * http://lab.llvm.org:8011/#/builders/33/builds/2131 * http://lab.llvm.org:8011/#/builders/135/builds/1473 * http://lab.llvm.org:8011/#/builders/66/builds/1559 * http://lab.llvm.org:8011/#/builders/134/builds/1409 * http://lab.llvm.org:8011/#/builders/132/builds/1817 I'm guessing that the patch was only tested with `FLANG_BUILD_NEW_DRIVER=Off` (i.e. the default). The builders listed above set `FLANG_BUILD_NEW_DRIVER` to `On`.
Although fixing the build is relatively easy, the reverted patch modifies the behaviour of the frontend, which breaks driver tests. In particular, in https://reviews.llvm.org/D93453 support for `-I` was added that depends on the current behaviour. The reverted patch changes that behaviour. Either the tests have to be updated or the change fine-tuned.
show more ...
|
#
d987b61b |
| 25-Jan-2021 |
peter klausler <pklausler@nvidia.com> |
[flang] Search for #include "file" in right directory
Make the #include "file" preprocessing directive begin its search in the same directory as the file containing the directive, as other preproces
[flang] Search for #include "file" in right directory
Make the #include "file" preprocessing directive begin its search in the same directory as the file containing the directive, as other preprocessors and our Fortran INCLUDE statement do.
Avoid current working directory for all source files after the original.
Differential Revision: https://reviews.llvm.org/D95388
show more ...
|
Revision tags: llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
#
5881bf00 |
| 14-Sep-2020 |
peter klausler <pklausler@nvidia.com> |
[flang] More clean-up of CookedSource API
The std::string holding the content of a CookedSource no longer needs to be exposed in its API after the recent work that allows the parsing context to hold
[flang] More clean-up of CookedSource API
The std::string holding the content of a CookedSource no longer needs to be exposed in its API after the recent work that allows the parsing context to hold multiple instances of a CookedSource. So clean the API. These changes were extracted from some work in progress that was made easier by the API changes.
Differential Revision: https://reviews.llvm.org/D87635
show more ...
|
#
92a54197 |
| 31-Aug-2020 |
peter klausler <pklausler@nvidia.com> |
[flang] Support multiple CookedSource instances
These are owned by an instance of a new class AllCookedSources.
This removes the need for a Scope to own a string containing a module's cooked source
[flang] Support multiple CookedSource instances
These are owned by an instance of a new class AllCookedSources.
This removes the need for a Scope to own a string containing a module's cooked source stream, and will enable errors to be emitted when parsing module files in the future.
Differential Revision: https://reviews.llvm.org/D86891
show more ...
|
Revision tags: llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1 |
|
#
b98ad941 |
| 09-Apr-2020 |
David Truby <david.truby@arm.com> |
[flang] Merge flang-compiler/f18
This is the initial merge of flang-compiler, which is done in this way principally to preserve the history and git-blame, without generating a large number of commit
[flang] Merge flang-compiler/f18
This is the initial merge of flang-compiler, which is done in this way principally to preserve the history and git-blame, without generating a large number of commits on the first-parent history of LLVM.
If you don't care about the flang history during a bisect remember that you can supply paths to git-bisect, e.g. `git bisect start clang llvm`.
The history of f18 was rewritten to:
* Put the code under /flang/. * Linearize the history. * Rewrite commit messages so that issue and PR numbers point to the old repository.
Credit to Peter Waller for writing the flatten and merge script.
Updates: flang-compiler/f18#876 (submission into llvm-project) Mailing-list: http://lists.llvm.org/pipermail/llvm-dev/2020-January/137989.html ([llvm-dev] Flang landing in the monorepo - next Monday!) Mailing-list: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137661.html ([llvm-dev] Flang landing in the monorepo)
Co-authored-by: Peter Waller <peter.waller@arm.com>
show more ...
|
#
1f879005 |
| 29-Mar-2020 |
Tim Keith <tkeith@nvidia.com> |
[flang] Reformat with latest clang-format and .clang-format
Original-commit: flang-compiler/f18@9fe84f45d7fd685051004678d6b5775dcc4c6f8f Reviewed-on: https://github.com/flang-compiler/f18/pull/1094
|