History log of /llvm-project/flang/lib/Common/Fortran-features.cpp (Results 1 – 8 of 8)
Revision Date Author Comments
# fc97d2e6 18-Dec-2024 Peter Klausler <pklausler@nvidia.com>

[flang] Add UNSIGNED (#113504)

Implement the UNSIGNED extension type and operations under control of a
language feature flag (-funsigned).

This is nearly identical to the UNSIGNED feature that h

[flang] Add UNSIGNED (#113504)

Implement the UNSIGNED extension type and operations under control of a
language feature flag (-funsigned).

This is nearly identical to the UNSIGNED feature that has been available
in Sun Fortran for years, and now implemented in GNU Fortran for
gfortran 15, and proposed for ISO standardization in J3/24-116.txt.

See the new documentation for details; but in short, this is C's
unsigned type, with guaranteed modular arithmetic for +, -, and *, and
the related transformational intrinsic functions SUM & al.

show more ...


# c1c99290 02-Dec-2024 Peter Klausler <pklausler@nvidia.com>

[flang] Allow a few irrelevant attributes, with warning (#117374)

INTENT, VALUE, and OPTIONAL attributes apply only to dummy arguments. A
couple older compilers accept them, usually with a warning,

[flang] Allow a few irrelevant attributes, with warning (#117374)

INTENT, VALUE, and OPTIONAL attributes apply only to dummy arguments. A
couple older compilers accept them, usually with a warning, if they are
applied to names that are not dummy arguments, and they show up in some
older non-portable source code. Change these cases into stern warnings
by default.

show more ...


# aa68dd57 14-Nov-2024 Peter Klausler <pklausler@nvidia.com>

[flang] Disable extension by default (#114875)

f18 allows, as an extension, an assumed-rank array to be associated with
a dummy argument that is not assumed-rank. This usage is non-conforming
and

[flang] Disable extension by default (#114875)

f18 allows, as an extension, an assumed-rank array to be associated with
a dummy argument that is not assumed-rank. This usage is non-conforming
and supported by only one other compiler, perhaps unintentionally.
Disable the extension by default, but also make it controllable so that
we can turn it back on later if it's really needed. (If it turns out to
not appear in applications after more exposure, I'll remove it
entirely.)

Fixes https://github.com/llvm/llvm-project/issues/114080.

show more ...


# 0e907c17 06-Nov-2024 Iñaki Amatria Barral <140811900+inaki-amatria@users.noreply.github.com>

[flang] Prevent errors from being suppressed (#114420)

`ModFileReader::Say()` flags all messages as errors, but Flang was
mistakenly suppressing two errors when the `-w` flag was used, as they
wer

[flang] Prevent errors from being suppressed (#114420)

`ModFileReader::Say()` flags all messages as errors, but Flang was
mistakenly suppressing two errors when the `-w` flag was used, as they
were incorrectly conditioned to warning suppression. This fix ensures
that errors are reported regardless of the `-w` flag.

This commit also replaces two uses of `_warn_en_US` with `_err_en_US` to
prevent potential confusion in the future.

show more ...


# 5a9d6841 15-Oct-2024 Peter Klausler <pklausler@nvidia.com>

[flang] Split interoperability warnings, disable some by default (#111922)

Type interoperability warnings current issue for intrinsic types when
their type, kind, or length do not meet the requirem

[flang] Split interoperability warnings, disable some by default (#111922)

Type interoperability warnings current issue for intrinsic types when
their type, kind, or length do not meet the requirements for C
interoperability. This turns out to be too noisy for the case of
one-byte characters with lengths other than one when creating C pointers
from C_LOC or C_F_POINTER -- it is not uncommon for programs to use
pointers to longer character objects.

So split the interoperability warning so that the case of a known bad
character length for an otherwise interoperable type is controlled by
its own UsageWarning enumerator, and leave that usage warning off by
default. This will better fit expectations in the default case while
still showing a warning under -pedantic.

show more ...


# 0f973ac7 02-Oct-2024 Peter Klausler <pklausler@nvidia.com>

[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)

(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as

[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)

(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as expected.)

Allow a parser::Message for a warning to be marked with the
common::LanguageFeature or common::UsageWarning that controls it. This
will allow a later patch to add hooks whereby a driver will be able to
decorate warning messages with the names of its options that enable each
particular warning, and to add hooks whereby a driver can map those
enumerators by name to command-line options that enable/disable the
language feature and enable/disable the messages.

The default settings in the constructor for LanguageFeatureControl were
moved from its header file into its C++ source file.

Hooks for a driver to use to map the name of a feature or warning to its
enumerator were also added.

To simplify the tagging of warnings with their corresponding language
feature or usage warning, to ensure that they are properly controlled by
ShouldWarn(), and to ensure that warnings never issue at code sites in
module files, two new Warn() member function templates were added to
SemanticsContext and other contextual frameworks. Warn() can't be used
before source locations can be mapped to scopes, but the bulk of
existing code blocks testing ShouldWarn() and FindModuleFile() before
calling Say() were convertible into calls to Warn(). The ones that were
not convertible were extended with explicit calls to
Message::set_languageFeature() and set_usageWarning().

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


# 64ab3302 25-Feb-2020 CarolineConcatto <51754594+CarolineConcatto@users.noreply.github.com>

[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)

This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-b

[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)

This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>

Original-commit: flang-compiler/f18@d2eb7a1c443d1539ef12b6f027074a0eb15b1ea0
Reviewed-on: https://github.com/flang-compiler/f18/pull/980

show more ...