You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue #1086 calls for a better method of compiler identification than checking the compiler name.
The current issue proposes an intermediate solution that presumably is straightforward to implement.
Possible Solution
I suggest that
flang and flang-new both resolve to LLVM Flang and
A new name, e.g., flang-classic, resolve to Classic Flang.
This breaks existing workflows in a way that hopefully has minimal cost to fix.
Users could, for example, create an executable flang-classic wrapper script with the following contents:
#!/bin/bash
<insert-path-to-classic-flang> "$@"
Additional Information
Additional considerations:
The LLVM Flang README.md file states, "... the plan is to replace Classic Flang with the new Flang in the future."
The Classic Flang Wiki describes Classic Flang as a "Fortran 2003/2008 Compiler," whereas
LLVM Flang 19 supports most of Fortran 2018 (with the primary exception being parallel features that Classic Flang also doesn't support),
where item 1 suggests that the change proposed in this issue is inevitable and items 2 and 3 suggest that now is a reasonable time to make the change.
Feedback is welcome.
The text was updated successfully, but these errors were encountered:
Description
Issue #1086 calls for a better method of compiler identification than checking the compiler name.
The current issue proposes an intermediate solution that presumably is straightforward to implement.
Possible Solution
I suggest that
flang
andflang-new
both resolve to LLVM Flang andflang-classic
, resolve to Classic Flang.This breaks existing workflows in a way that hopefully has minimal cost to fix.
Users could, for example, create an executable
flang-classic
wrapper script with the following contents:Additional Information
Additional considerations:
where item 1 suggests that the change proposed in this issue is inevitable and items 2 and 3 suggest that now is a reasonable time to make the change.
Feedback is welcome.
The text was updated successfully, but these errors were encountered: