[PATCH] D73951: [Clang] [Driver]Add logic to search for flang frontend

[Steve Scalpone via Phabricator via cfe-commits]

sscalpone added a comment.

type in the commit message: //esle// the frontend name is hard-coded to 
"flang", use that to


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73951



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

[PATCH] D73951: [Clang] [Driver]Add logic to search for flang frontend

[Steve Scalpone via Phabricator via cfe-commits]

sscalpone added inline comments.



Comment at: clang/test/Driver/flang/flang-driver-2-frontend01.f90:1
+! Check wich name of flang frontend is invoked by the driver
+

typo //wich//



Comment at: clang/test/Driver/flang/flang-driver-2-frontend02.f90:1
+! Check wich name of flang frontend is invoked by the driver
+

Typo


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73951



___
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

[Steve Scalpone via Phabricator via cfe-commits]

sscalpone added a comment.

As I said this morning, I prefer to wait with this patch until the upstreaming 
is finished.  The reason is not only to do with upstreaming, but also with a 
concurrent effort to button up any assertion and runtime errors so the initial 
user experience is better.   While some posit the the news of your patch won't 
be heard around the world, I think it is a major accomplishment & the user 
community will be thrilled to try flang.  My preference is for that first wave 
of users to come a way with the impression that flang is a high-quality work in 
progress.

@awarzynski The CMAKE PR is closed.  Do you plan to revitalize it?Will you 
check that this patch, along with the CMAKE PR, is indeed enough to satisfy the 
requirement for the cmake reviewers as well as provides enough functionality to 
support cmake in a real project?


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] D125788: [flang][driver] Rename `flang-new` as `flang`

[Steve Scalpone via Phabricator via cfe-commits]

sscalpone added a comment.

My belief is that we should wait until f18 hits a reasonable quality bar for 
executables before making flang-new the default.  My reasoning seems not to 
have carried the day.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125788

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

[PATCH] D125788: [flang][driver] Rename `flang-new` as `flang`

[Steve Scalpone via Phabricator via cfe-commits]

sscalpone added a comment.

My proposal is:

If the compiler compiles it, it ought to run.
If the compiler can't compile it, it ought to clearly say why.

1. All tests of legal Fortran that compile & link must also execute correctly 
(which excludes tests that expect to catch a problem at runtime)
2. For all tests with unsupported features, the compiler must issues an error 
message and the message references the source-location of the unsupported 
feature

My preference is to use the NAG test suite.   It is not freely available.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125788

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

[PATCH] D125788: [flang][driver] Rename `flang-new` as `flang`

[Steve Scalpone via Phabricator via cfe-commits]

sscalpone added a comment.

Recommend that you contact NAG for more info on the test suite.  Here's the 
only reference that I could find: 
https://fortran-lang.discourse.group/t/fortran-compiler-testing-framework/1573/10


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125788

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

[PATCH] D125788: [flang][driver] Rename `flang-new` as `flang`

[Steve Scalpone via Phabricator via cfe-commits]

sscalpone added a comment.

I'm fine with removing or renaming the existing flang shell script.

My proposal is not to wait for a 100% pass rate.   My proposal is to wait until 
the messages for unimplemented features are converted to TODOs that reference 
the program's source line and that legal programs which compile and link will 
execute without error.  In short, what flang compiles should work, and what 
flang doesn't compile should offer a reasonable message to the user to 
understand the limitation.

This proposal is not restricted to F95  but to 
any source that someone might attempt to compile.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125788

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

[PATCH] D93453: [flang][driver] Add support for `-I`

[Steve Scalpone via Phabricator via cfe-commits]

sscalpone added a comment.

Flang supports include files and module files.  The search path is used to look 
for both include files and module files.  The help text doesn't include info 
about module files.

The help text refers to the -isystem option.  Is that implemented for flang, 
and if so, ought tests be added to make sure -I and -isystem co-exist as 
documented for flang?

Not that there's also a special include directory for intrinsic modules.  
Intrinsic modules are treated specially, and right now, they are special by 
virtue of being in a special directory.  In the throwaway driver, the option is 
-intrinsic-module-directory.

There's also the -module option to specify the directory into which newly 
created module files are written.   I don't recall if flang or other compilers 
generally add that directory to the search path as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93453

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

[PATCH] D94169: [clang][driver] Restore the original help text for `-I`

[Steve Scalpone via Phabricator via cfe-commits]

sscalpone added a comment.

@awarzynski, perhaps I am being too dramatic by wondering if we are 
compromising support for one or the other language in order to support a common 
definition.  In the case of -I, there are language-specific semantics that are 
important and interesting, such as the relationship in clang between -I and 
-isystem, and the relationship in flang between -I and -module.  Maybe the 
right answer is to allow the definition of duplicate options that are 
differentiated by language?

+1 @andreil99


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94169

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