vasilito
cb424d7448
verify-patch-sanity.py validates every active recipe .patch has internally- consistent hunk line counts — catching the 'malformed patch at line N' failure at commit/CI/preflight time instead of hours into a cook. This cycle hit that class three times (qtwaylandscanner, sddm, xwayland), each only discovered when cookbook tried to apply the patch. Running it across the repo found 29 latent malformed patches (validated against GNU patch: e.g. relibc/P3-sysv-ipc reproduces 'malformed patch at line 22'). They were harmless only because they sit in vendored recipes (baked, not re- applied) — but would fail on any version-bump re-derivation. --fix recounts the hunk headers (body untouched) and repaired all 29. Wired into build-preflight.sh (Phase 1.0D) and redbear-ci.yml, with a unit test (test-patch-sanity.sh). Skips archived/legacy trees and unvalidatable formats (empty placeholders, bare-@@ git hunks).
64 lines
2.4 KiB
ReStructuredText
64 lines
2.4 KiB
ReStructuredText
flang - the Flang Fortran compiler
|
|
==================================
|
|
|
|
SYNOPSIS
|
|
--------
|
|
|
|
:program:`flang` [*options*] *filename ...*
|
|
|
|
DESCRIPTION
|
|
-----------
|
|
|
|
:program:`flang` is a Fortran compiler which supports all of the Fortran 95 and
|
|
many newer language features. Flang supports OpenMP and has some support for
|
|
OpenACC and CUDA. It encompasses preprocessing, parsing, optimization, code
|
|
generation, assembly, and linking. Depending on the options passed in, Flang
|
|
will perform only some, or all, of these actions. While Flang is highly
|
|
integrated, it is important to understand the stages of compilation in order to
|
|
understand how to invoke it. These stages are:
|
|
|
|
Driver
|
|
The flang executable is actually a small driver that orchestrates the
|
|
execution of other tools such as the compiler, assembler and linker.
|
|
Typically you do not need to interact with the driver, but you
|
|
transparently use it to run the other tools.
|
|
|
|
Preprocessing
|
|
This stage performs tokenization of the input source file, macro expansion,
|
|
#include expansion and handles other preprocessor directives.
|
|
|
|
Parsing and Semantic Analysis
|
|
This stage parses the input file, translating preprocessor tokens into a
|
|
parse tree. Once in the form of a parse tree, it applies semantic
|
|
analysis to compute types for expressions and determine whether
|
|
the code is well formed. Parse errors and most compiler warnings
|
|
are generated by this stage.
|
|
|
|
Code Generation and Optimization
|
|
This stage translates the parse tree into intermediate code (known as
|
|
"LLVM IR") and, ultimately, machine code. It also optimizes this
|
|
intermediate code and handles target-specific code generation. The output
|
|
of this stage is typically a ".s" file, referred to as an "assembly" file.
|
|
|
|
Flang also supports the use of an integrated assembler, in which the code
|
|
generator produces object files directly. This avoids the overhead of
|
|
generating the ".s" file and calling the target assembler explicitly.
|
|
|
|
Assembler
|
|
This stage runs the target assembler to translate the output of the
|
|
compiler into a target object file. The output of this stage is typically
|
|
a ".o" file, referred to as an "object" file.
|
|
|
|
Linker
|
|
This stage runs the target linker to merge multiple object files into an
|
|
executable or dynamic library. The output of this stage is typically
|
|
an "a.out", ".dylib" or ".so" file.
|
|
|
|
OPTIONS
|
|
-------
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
FlangCommandLineOptions
|