[PATCH] D122008: [flang][driver] Add support for generating executables

[Peter Klausler via Phabricator via cfe-commits]

klausler added a comment.

There's 128037 lines of code and documentation outside of lowering and drivers 
in flang/, and "git blame" tells me that I wrote 63% of them, including most of 
the Fortran semantics and nearly all of the Fortran parsing and runtime.  Based 
on my knowledge of the code base, the Fortran language, and where we stand in 
the process of shaking things out with applications and test suites, it is 
clear to me that things are not yet ready to be opened up to a larger user 
base.  We certainly don't need wider exposure yet to flush out more bugs.  
Premature exposure now would disrupt the critical path to overall success.  So 
I prefer option (3).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122008/new/

https://reviews.llvm.org/D122008

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123113: [Flang] Add `INTENT` for non-dummy arguments extension

[Peter Klausler via Phabricator via cfe-commits]

klausler added a comment.

What is going on here?  I don't understand.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123113/new/

https://reviews.llvm.org/D123113

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122008: [flang][driver] Add support for generating executables

[Peter Klausler via Phabricator via cfe-commits]

klausler added a comment.

In D122008#3462550 , @awarzynski 
wrote:

> Btw, if there are no new comments, I would like to merge this in the coming 
> days.

New comments or not, this step remains premature from my perspective.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122008/new/

https://reviews.llvm.org/D122008

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130513: [Flang] Add -fconvert option to swap endianness for unformatted files

[Peter Klausler via Phabricator via cfe-commits]

klausler added a comment.

Instead of adding new custom APIs that let command-line options control 
behavior is a way that is redundant with the runtime environment, I suggest 
that you try a more general runtime library API by which the main program can 
specify a default environment variable setting, or a set of them.  Then turn 
the command-line options into the equivalent environment settings and pass them 
as default settings that could be overridden by the actual environment.

This would not be any more work, it would lead to a cleaner implementation in 
the runtime than this one, and it would make the next option of this kind much 
easier to implement.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130513/new/

https://reviews.llvm.org/D130513

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130513: [Flang] Add -fconvert option to swap endianness for unformatted files

[Peter Klausler via Phabricator via cfe-commits]

klausler added inline comments.



Comment at: flang/runtime/main.cpp:51
+  if (Fortran::runtime::executionEnvironment.conversion !=
+  Fortran::runtime::Convert::Unknown)
+return;

We always use braces on if/for/while/&c. constructs in the runtime.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130513/new/

https://reviews.llvm.org/D130513

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88613: [flang] Semantic analysis for FINAL subroutines

[Peter Klausler via Phabricator via cfe-commits]

klausler updated this revision to Diff 295423.
klausler added a comment.

Previous update to this review had inadvertent changes to other files because I 
neglected to rebase after updating master; now fixed.  Sorry for the scare!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88613/new/

https://reviews.llvm.org/D88613

Files:
  flang/include/flang/Evaluate/characteristics.h
  flang/include/flang/Evaluate/type.h
  flang/include/flang/Semantics/symbol.h
  flang/include/flang/Semantics/tools.h
  flang/lib/Evaluate/characteristics.cpp
  flang/lib/Evaluate/tools.cpp
  flang/lib/Evaluate/type.cpp
  flang/lib/Semantics/check-call.cpp
  flang/lib/Semantics/check-declarations.cpp
  flang/lib/Semantics/mod-file.cpp
  flang/lib/Semantics/mod-file.h
  flang/lib/Semantics/pointer-assignment.cpp
  flang/lib/Semantics/resolve-names.cpp
  flang/lib/Semantics/symbol.cpp
  flang/lib/Semantics/tools.cpp
  flang/test/Semantics/call03.f90
  flang/test/Semantics/call05.f90
  flang/test/Semantics/final01.f90
  flang/test/Semantics/modfile10.f90
  flang/test/Semantics/resolve32.f90
  flang/test/Semantics/resolve55.f90

Index: flang/test/Semantics/resolve55.f90
===
--- flang/test/Semantics/resolve55.f90
+++ flang/test/Semantics/resolve55.f90
@@ -36,25 +36,24 @@
   end do
 end subroutine s4
 
-subroutine s5()
+module m
 ! Cannot have a variable of a finalizable type in a locality spec
   type t1
 integer :: i
   contains
 final :: f
   end type t1
-
-  type(t1) :: var
-
-!ERROR: Finalizable variable 'var' not allowed in a locality-spec
-  do concurrent(i=1:5) local(var)
-  end do
-
-contains
+ contains
+  subroutine s5()
+type(t1) :: var
+!ERROR: Finalizable variable 'var' not allowed in a locality-spec
+do concurrent(i=1:5) local(var)
+end do
+  end subroutine s5
   subroutine f(x)
 type(t1) :: x
   end subroutine f
-end subroutine s5
+end module m
 
 subroutine s6
 ! Cannot have a nonpointer polymorphic dummy argument in a locality spec
Index: flang/test/Semantics/resolve32.f90
===
--- flang/test/Semantics/resolve32.f90
+++ flang/test/Semantics/resolve32.f90
@@ -57,7 +57,7 @@
   contains
 procedure, nopass :: b => s
 final :: f
-!ERROR: Type parameter, component, or procedure binding 'i' already defined in this type
+!ERROR: FINAL subroutine 'i' of derived type 't2' must be a module procedure
 final :: i
   end type
   type t3
Index: flang/test/Semantics/modfile10.f90
===
--- flang/test/Semantics/modfile10.f90
+++ flang/test/Semantics/modfile10.f90
@@ -64,8 +64,8 @@
 !  type::t2
 !integer(4)::x
 !  contains
-!final::c
 !procedure,non_overridable,private::d
+!final::c
 !  end type
 !  type,abstract::t2a
 !  contains
Index: flang/test/Semantics/final01.f90
===
--- /dev/null
+++ flang/test/Semantics/final01.f90
@@ -0,0 +1,119 @@
+! RUN: %S/test_errors.sh %s %t %f18
+! Test FINAL subroutine constraints C786-C789
+module m1
+  external :: external
+  intrinsic :: sin
+  real :: object
+  procedure(valid), pointer :: pointer
+  type :: parent(kind1, len1)
+integer, kind :: kind1 = 1
+integer, len :: len1 = 1
+  end type
+  type, extends(parent) :: child(kind2, len2)
+integer, kind :: kind2 = 2
+integer, len :: len2 = 2
+   contains
+final :: valid
+!ERROR: FINAL subroutine 'external' of derived type 'child' must be a module procedure
+!ERROR: FINAL subroutine 'sin' of derived type 'child' must be a module procedure
+!ERROR: FINAL subroutine 'object' of derived type 'child' must be a module procedure
+!ERROR: FINAL subroutine 'pointer' of derived type 'child' must be a module procedure
+!ERROR: FINAL subroutine 'func' of derived type 'child' must be a subroutine
+final :: external, sin, object, pointer, func
+!ERROR: FINAL subroutine 's01' of derived type 'child' must have a single dummy argument that is a data object
+!ERROR: FINAL subroutine 's02' of derived type 'child' must have a single dummy argument that is a data object
+!ERROR: FINAL subroutine 's03' of derived type 'child' must not have a dummy argument with INTENT(OUT)
+!ERROR: FINAL subroutine 's04' of derived type 'child' must not have a dummy argument with the VALUE attribute
+!ERROR: FINAL subroutine 's05' of derived type 'child' must not have a POINTER dummy argument
+!ERROR: FINAL subroutine 's06' of derived type 'child' must not have an ALLOCATABLE dummy argument
+!ERROR: FINAL subroutine 's07' of derived type 'child' must not have a coarray dummy argument
+!ERROR: FINAL subroutine 's08' of derived type 'child' must not have a polymorphic dummy argument
+!ERROR: FINAL subroutine 's09' of derived type 'child' must not have a polymorphic dummy argument
+!ERROR: FINAL subroutine 's10' 

[PATCH] D104305: [flang][driver] Add `-fdebug-dump-all`

[Peter Klausler via Phabricator via cfe-commits]

klausler added a comment.

The non-shared-library build of the current llvm-project/main tree fails on 
this new test; it looks as if gfortran is being invoked and passed an option 
that it does not recognize.  The shared library build passes all tests.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104305/new/

https://reviews.llvm.org/D104305

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104305: [flang][driver] Add `-fdebug-dump-all`

[Peter Klausler via Phabricator via cfe-commits]

klausler added a comment.

No; I'm hitting this problem with an in-tree static build of llvm-project/main. 
 Weird.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104305/new/

https://reviews.llvm.org/D104305

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103612: [flang][driver] Add `-funparse-typed-exprs-as-fortran`

[Peter Klausler via Phabricator via cfe-commits]

klausler added a comment.

> The default behaviour is to always decorate unparsed typed expression with 
> e.g. their KIND. The new flag can be used to turn this off, so that the 
> generated output uses valid Fortran syntax and can be fed to another Fortran 
> compiler.

The output of Expr::AsFortran() should be valid Fortran, and it's a bug if 
it's not.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103612/new/

https://reviews.llvm.org/D103612

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103612: [flang][driver] Add `-funparse-typed-exprs-as-fortran`

[Peter Klausler via Phabricator via cfe-commits]

klausler added a comment.

In D103612#2827458 , @awarzynski 
wrote:

> In D103612#2827444 , @klausler 
> wrote:
>
>>> The default behaviour is to always decorate unparsed typed expression with 
>>> e.g. their KIND. The new flag can be used to turn this off, so that the 
>>> generated output uses valid Fortran syntax and can be fed to another 
>>> Fortran compiler.
>>
>> The output of Expr::AsFortran() should be valid Fortran, and it's a bug 
>> if it's not.
>
> This is the output that I get from the unparser (input file: 
> flang/test/Driver/unparse-typed-exprs.f95):
>
>   PROGRAM test_allocated
>INTEGER :: i = 13_4
>REAL(KIND=2_4), ALLOCATABLE :: x(:)
>IF (.NOT.allocated(x)) ALLOCATE(x(i))
>   END PROGRAM test_allocated
>
> This is not valid, is it? Or am I missing something?

Kind suffixes are described in subclause 7.4.3 of Fortran 2018, e.g. R708 on p. 
58.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103612/new/

https://reviews.llvm.org/D103612

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103612: [flang][driver] Add `-funparse-typed-exprs-as-fortran`

[Peter Klausler via Phabricator via cfe-commits]

klausler added a comment.

In D103612#2830111 , @awarzynski 
wrote:

> In D103612#2827468 , @klausler 
> wrote:
>
>> Kind suffixes are described in subclause 7.4.3 of Fortran 2018, e.g. R708 on 
>> p. 58.
>
> Many thanks for this reference.
>
> So when calling `Unparse,` one specifes `AnalyzedObjectsAsFortran` (i.e. the 
> optional last argument) to get more semantic context in the dump, right?

It's for better code coverage when testing.  When the internal representations 
of expressions & variables are dumped by unparsing rather than the original 
parse trees, it allows semantic analysis (esp. folding) to be exercised.  If an 
unparsed program compiles and runs fine when unparsed into gfortran without 
this flag, but fails when the flag is present, there's a bug.  This feature 
allows much of the frontend to undergo some testing and debugging in the 
absence of a code generator.

It's also useful for self-testing via a "parse/unparse/reparse/unparse" mode, 
in which we recompile unparsed Fortran and check that it unparses to the same 
output.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103612/new/

https://reviews.llvm.org/D103612

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D106727: [flang] Produce proper "preprocessor output" for -E option

[Peter Klausler via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG3338ef93b028: [flang] Produce proper "preprocessor 
output" for -E option (authored by klausler).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D106727?vs=363212&id=363221#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106727/new/

https://reviews.llvm.org/D106727

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/FrontendOptions.h
  flang/include/flang/Frontend/PreprocessorOptions.h
  flang/include/flang/Parser/parsing.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/Frontend/FrontendOptions.cpp
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/lib/Parser/parsing.cpp
  flang/lib/Parser/provenance.cpp
  flang/lib/Parser/token-sequence.cpp
  flang/lib/Parser/token-sequence.h
  flang/test/Driver/cpp-nocpp-command-line-macro.f90
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/escaped-backslash.f90
  flang/test/Driver/fixed-free-detection.f90
  flang/test/Driver/fixed-line-length.f90
  flang/test/Driver/frontend-forwarding.f90
  flang/test/Driver/include-header.f90
  flang/test/Driver/input-from-stdin.f90
  flang/test/Driver/macro-def-undef.F90
  flang/test/Driver/macro-multiline.F90
  flang/test/Parser/badlabel.f
  flang/test/Preprocessing/assert.F90
  flang/test/Preprocessing/dash-E.F90
  flang/test/Preprocessing/fixed-rescan.F
  flang/test/Preprocessing/hollerith.f
  flang/test/Preprocessing/pp001.F
  flang/test/Preprocessing/pp002.F
  flang/test/Preprocessing/pp003.F
  flang/test/Preprocessing/pp004.F
  flang/test/Preprocessing/pp005.F
  flang/test/Preprocessing/pp006.F
  flang/test/Preprocessing/pp007.F
  flang/test/Preprocessing/pp008.F
  flang/test/Preprocessing/pp009.F
  flang/test/Preprocessing/pp010.F
  flang/test/Preprocessing/pp011.F
  flang/test/Preprocessing/pp012.F
  flang/test/Preprocessing/pp013.F
  flang/test/Preprocessing/pp014.F
  flang/test/Preprocessing/pp015.F
  flang/test/Preprocessing/pp016.F
  flang/test/Preprocessing/pp017.F
  flang/test/Preprocessing/pp018.F
  flang/test/Preprocessing/pp019.F
  flang/test/Preprocessing/pp020.F
  flang/test/Preprocessing/pp021.F
  flang/test/Preprocessing/pp022.F
  flang/test/Preprocessing/pp023.F
  flang/test/Preprocessing/pp024.F
  flang/test/Preprocessing/pp025.F
  flang/test/Preprocessing/pp026.F
  flang/test/Preprocessing/pp027.F
  flang/test/Preprocessing/pp028.F
  flang/test/Preprocessing/pp029.F
  flang/test/Preprocessing/pp030.F
  flang/test/Preprocessing/pp031.F
  flang/test/Preprocessing/pp032.F
  flang/test/Preprocessing/pp033.F
  flang/test/Preprocessing/pp034.F
  flang/test/Preprocessing/pp035.F
  flang/test/Preprocessing/pp036.F
  flang/test/Preprocessing/pp037.F
  flang/test/Preprocessing/pp038.F
  flang/test/Preprocessing/pp039.F
  flang/test/Preprocessing/pp041.F
  flang/test/Preprocessing/pp043.F
  flang/test/Preprocessing/pp044.F
  flang/test/Preprocessing/pp101.F90
  flang/test/Preprocessing/pp102.F90
  flang/test/Preprocessing/pp104.F90
  flang/test/Preprocessing/pp107.F90
  flang/test/Preprocessing/pp108.F90
  flang/test/Preprocessing/pp111.F90
  flang/test/Preprocessing/pp112.F90
  flang/test/Preprocessing/pp115.F90
  flang/test/Preprocessing/pp116.F90
  flang/test/Preprocessing/pp117.F90
  flang/test/Preprocessing/pp118.F90
  flang/test/Preprocessing/pp121.F90
  flang/test/Preprocessing/pp123.F90
  flang/test/Preprocessing/pp124.F90
  flang/test/Preprocessing/pp125.F90
  flang/test/Preprocessing/pp126.F90
  flang/test/Preprocessing/pp127.F90
  flang/test/Preprocessing/pp128.F90
  flang/tools/f18-parse-demo/f18-parse-demo.cpp
  flang/tools/f18/f18.cpp
  flang/unittests/Frontend/FrontendActionTest.cpp

Index: flang/unittests/Frontend/FrontendActionTest.cpp
===
--- flang/unittests/Frontend/FrontendActionTest.cpp
+++ flang/unittests/Frontend/FrontendActionTest.cpp
@@ -1,4 +1,4 @@
-//===- unittests/Frontend/PrintPreprocessedTest.cpp  FrontendAction tests--===//
+//===- unittests/Frontend/FrontendActionTest.cpp  FrontendAction tests-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -116,6 +116,7 @@
 
   // Set-up the action kind.
   compInst_.invocation().frontendOpts().programAction_ = PrintPreprocessedInput;
+  compInst_.invocation().preprocessorOpts().noReformat = true;
 
   // Set-up the output stream. We are using output buffer wrapped as an output
   // stream, as opposed to an actual file (or a file descriptor).
Index: flang/tools/f18/f18.cpp

[PATCH] D103612: [flang][driver] Add `-fno-analyzed-objects-for-unparse`

[Peter Klausler via Phabricator via cfe-commits]

klausler added a comment.

This patch may have broken the shared library buildbots.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103612/new/

https://reviews.llvm.org/D103612

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D114209: [flang] Add -fno-automatic, refine IsSaved()

[Peter Klausler via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG996ef895cd3d: [flang] Add -fno-automatic, refine IsSaved() 
(authored by klausler).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114209/new/

https://reviews.llvm.org/D114209

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Common/Fortran-features.h
  flang/include/flang/Evaluate/tools.h
  flang/include/flang/Semantics/tools.h
  flang/lib/Evaluate/tools.cpp
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Semantics/resolve-names-utils.cpp
  flang/lib/Semantics/runtime-type-info.cpp
  flang/lib/Semantics/tools.cpp
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Semantics/entry01.f90
  flang/test/Semantics/save01.f90
  flang/test/Semantics/save02.f90

Index: flang/test/Semantics/save02.f90
===
--- /dev/null
+++ flang/test/Semantics/save02.f90
@@ -0,0 +1,9 @@
+! RUN: %flang_fc1 -fsyntax-only -fno-automatic %s 2>&1 | FileCheck %s --allow-empty
+! Checks that -fno-automatic implies the SAVE attribute.
+! This same subroutine appears in test save01.f90 where it is an
+! error case due to the absence of both SAVE and -fno-automatic.
+subroutine foo
+  integer, target :: t
+  !CHECK-NOT: error:
+  integer, pointer :: p => t
+end
Index: flang/test/Semantics/save01.f90
===
--- flang/test/Semantics/save01.f90
+++ flang/test/Semantics/save01.f90
@@ -17,5 +17,13 @@
INTEGER :: mc
 END FUNCTION
 
+! This same subroutine appears in test save02.f90 where it is not an
+! error due to -fno-automatic.
+SUBROUTINE foo
+  INTEGER, TARGET :: t
+  !ERROR: An initial data target may not be a reference to an object 't' that lacks the SAVE attribute
+  INTEGER, POINTER :: p => t
+end
+
 END MODULE
 
Index: flang/test/Semantics/entry01.f90
===
--- flang/test/Semantics/entry01.f90
+++ flang/test/Semantics/entry01.f90
@@ -55,7 +55,6 @@
   common /badarg3/ x
   namelist /badarg4/ x
   !ERROR: A dummy argument must not be initialized
-  !ERROR: A dummy argument may not have the SAVE attribute
   integer :: badarg5 = 2
   entry okargs(goodarg1, goodarg2)
   !ERROR: RESULT(br1) may appear only in a function
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -39,6 +39,7 @@
 ! HELP-NEXT:Specify where to find the compiled intrinsic modules
 ! HELP-NEXT: -flarge-sizes  Use INTEGER(KIND=8) for the result type in size-related intrinsics
 ! HELP-NEXT: -flogical-abbreviations Enable logical abbreviations
+! HELP-NEXT: -fno-automatic Implies the SAVE attribute for non-automatic local objects in subprograms unless RECURSIVE
 ! HELP-NEXT: -fno-color-diagnostics  Disable colors in diagnostics
 ! HELP-NEXT: -fopenacc  Enable OpenACC
 ! HELP-NEXT: -fopenmp   Parse OpenMP pragmas and generate parallel code.
@@ -103,6 +104,7 @@
 ! HELP-FC1-NEXT: -flogical-abbreviations Enable logical abbreviations
 ! HELP-FC1-NEXT: -fno-analyzed-objects-for-unparse
 ! HELP-FC1-NEXT:Do not use the analyzed objects when unparsing
+! HELP-FC1-NEXT: -fno-automatic Implies the SAVE attribute for non-automatic local objects in subprograms unless RECURSIVE
 ! HELP-FC1-NEXT: -fno-reformat  Dump the cooked character stream in -E mode
 ! HELP-FC1-NEXT: -fopenacc  Enable OpenACC
 ! HELP-FC1-NEXT: -fopenmp   Parse OpenMP pragmas and generate parallel code.
Index: flang/test/Driver/driver-help-hidden.f90
===
--- flang/test/Driver/driver-help-hidden.f90
+++ flang/test/Driver/driver-help-hidden.f90
@@ -39,6 +39,7 @@
 ! CHECK-NEXT:Specify where to find the compiled intrinsic modules
 ! CHECK-NEXT: -flarge-sizes  Use INTEGER(KIND=8) for the result type in size-related intrinsics
 ! CHECK-NEXT: -flogical-abbreviations Enable logical abbreviations
+! CHECK-NEXT: -fno-automatic Implies the SAVE attribute for non-automatic local objects in subprograms unless RECURSIVE
 ! CHECK-NEXT: -fno-color-diagnostics  Disable colors in diagnostics
 ! CHECK-NEXT: -fopenacc  Enable OpenACC
 ! CHECK-NEXT: -fopenmp   Parse OpenMP pragmas and generate parallel code.
Index: flang/lib/Semantics/tools.cpp
===
--- flang/lib/Semantics/tools.cpp
+++ flang/lib/Semantics/tools.cpp
@@ -626,49 +626,6 @@
 

[PATCH] D130513: [Flang] Add -fconvert option to swap endianness for unformatted files

[Peter Klausler via Phabricator via cfe-commits]

klausler added a comment.

I can't speak to the lowering or driver bits, but the runtime part looks pretty 
good to me.




Comment at: flang/runtime/environment-default-list.h:1
+//===-- Runtime/environment-default-list.h 
===//
+//

If you want this header to be maximally portable C and C++, please observe the 
usage of other such headers, and use old-school C /*comments*/.

You could probably just use an 'int' for the item count and avoid some 
difficulty below, unless you expect a program to use billions of default 
environment settings.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130513/new/

https://reviews.llvm.org/D130513

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130513: [Flang] Add -fconvert option to swap endianness for unformatted files

[Peter Klausler via Phabricator via cfe-commits]

klausler accepted this revision.
klausler added a comment.

The runtime parts look good to me.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130513/new/

https://reviews.llvm.org/D130513

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration

[Peter Klausler via Phabricator via cfe-commits]

klausler added inline comments.



Comment at: flang/runtime/CMakeLists.txt:251
 
-  INSTALL_WITH_TOOLCHAIN
-)
+if (DEFINED LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
+  add_flang_library(FortranRuntime STATIC

pscoro wrote:
> efriedma wrote:
> > pscoro wrote:
> > > efriedma wrote:
> > > > pscoro wrote:
> > > > > efriedma wrote:
> > > > > > This "if" doesn't make sense to me.  If we're not building 
> > > > > > flang-rt, we shouldn't be here, so I don't see why you need an "if" 
> > > > > > in the first place.
> > > > > `add_subdirectory(runtime)` is a line that still exists in 
> > > > > `flang/CMakeLists.txt`. This exists because `Fortran_main` is still 
> > > > > being built at the same time as the compiler, and to do so, the 
> > > > > runtime subdirectory still needs to be added to flang 
> > > > > (`flang/CMakeLists.txt` -> `add_subdirectory(runtime)` -> 
> > > > > `flang/runtime/CMakeLists.txt` -> `add_subdirectory(FortranMain)`. 
> > > > > The solution I had was to just add a check around the 
> > > > > `FortranRuntime` library production so that it only happens for 
> > > > > flang-rt.
> > > > > 
> > > > > If you have a better solution let me know. Overall, I'm not sure if 
> > > > > Fortran_main is currently being handled in the best way (ie, its 
> > > > > still being built at the same time as the compiler, which doesn't 
> > > > > seem ideal), but am not sure what course of action to take with it 
> > > > > since it doesn't really belong in flang-rt either (see documentation 
> > > > > for details)
> > > > Fortran_main should be "part of" flang-rt in the sense that building 
> > > > flang-rt builds it.  Most of the same reasons we want to build 
> > > > flang-rt.a as a runtime apply.
> > > > 
> > > > Since the output needs to be separate, building flang-rt should produce 
> > > > two libraries: flang-rt.a and FortranMain.a.
> > > I agree with this idea and have been trying to make it work but in the 
> > > process I discovered that my "fix" above (`if (DEFINED 
> > > LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)`) is 
> > > worse than I thought.
> > > 
> > > By building the llvm target with flang-rt as an enabled runtime, we are 
> > > essentially saying: build the flang compiler, and then invoke cmake again 
> > > to build the runtimes project (externally), which builds flang-rt.
> > > 
> > > The problem is that check-all depends on check-flang which depends on the 
> > > runtime. The if guard above was not actually doing what I thought it was, 
> > > and the reason why configuring didnt fail with "flang-rt does not exist" 
> > > is because the if guard was still evaluating to true. Basically, the 
> > > guard ensured that FortranRuntime was only being built if flang-rt is 
> > > built, but the add_library call was still being reached *during the 
> > > configuration of the flang compiler*.
> > > 
> > > I am having trouble dealing with this dependency since runtimes get built 
> > > externally (and after the compiler is built, which is when the check-all 
> > > custom target gets built). I will have to investigate more closely how 
> > > other runtimes handle this. My initial thought was perhaps the runtime 
> > > testing should be decoupled from check-flang/check-all however I don't 
> > > know if that's a good idea, and I also think that only helps with 
> > > flang-rt, but if Fortran_main is required to build any executable I 
> > > imagine that it should be needed for check-flang?
> > > 
> > > This is just an update of whats holding me back right now. If you have 
> > > any tips please let me know. Thanks for bringing this to my attention.
> > For comparison, check-clang doesn't require any runtime libraries at all. 
> > All the checks only check the generated LLVM IR/driver commands/etc.  Any 
> > tests that require runtime execution go into either the regression tests 
> > for the runtimes themselves, or into lllvm-test-suite.
> > 
> > Probably check-flang should do something similar. It probably makes sense 
> > to add a check-flang-rt target or something like that.  (Not sure which 
> > existing flang tests are impacted.)
> If we are decoupling the affected tests from flang-rt, then I think the only 
> component left coupled (that I'd argue shouldn't be coupled) is the runtime 
> source files. I'm seeing that for all the other runtimes in the llvm-project, 
> the sources exist in a top level directory. Would it make sense and be 
> feasible for flang-rt to act similarly?
> 
> Comparing to the infrastructure for compiler-rt, I've been entertaining the 
> idea that FortranRuntime and FortranMain can be treated as a library with 
> sources defined in `flang-rt/lib/FortranRuntime` and 
> `flang-rt/lib/FortranMain`, similar to how compiler-rt has libraries like 
> `compiler-rt/lib/asan` that are added to the final compiler-rt target.
> 
> FortranDecimalRT's sources would still be gathered from the Flang source 
> dir

[PATCH] D154869: [Flang] [FlangRT] Introduce FlangRT project as solution to Flang's runtime LLVM integration

[Peter Klausler via Phabricator via cfe-commits]

klausler added inline comments.



Comment at: flang-rt/unittests/FortranEvaluate/testing.h:1
+#ifndef FORTRAN_EVALUATE_TESTING_H_
+#define FORTRAN_EVALUATE_TESTING_H_

Why was this file (and testing.cpp) added instead of being moved, like other 
files were?

Why are the unit tests for the Evaluate library being moved into flang-rt?  The 
Evaluate library is only used by the compiler for constant folding and 
expression processing; it is not part of the runtime.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154869/new/

https://reviews.llvm.org/D154869

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits