Details
- Reviewers
awarzynski kiranchandramohan sscalpone
Diff Detail
Event Timeline
flang/tools/f18/flang | ||
---|---|---|
282 | It would be great if this name could follow's LLVM's coding guide:
Perhaps run_and_check_status? run_compiler_command? run_and_check? run_cmd? Also, could you add a short description? | |
321 | Similar suggestion elsewhere |
flang/tools/f18/flang | ||
---|---|---|
282 | run_and_check sounds fine and indeed I forgot description. |
This change makes a lot of sense and is a big improvement.
I just feel that the summary focus on one of the side effects rather than what this patch really does. I think that the main thing here is the refactoring and the code-duplication reduction. The inconsistent diagnostic is also fixed, but that's a relatively small change (hence "side-effect") and could be achieved without the refactoring. So, I would update the summary :) This is not a blocker for me though!
flang/tools/f18/flang | ||
---|---|---|
319 | This seems to be the only place in which the diagnostic is inconsistent with the compiler invocation (should be $ect_fc instead of "$wd/bin/flang-new"). |
Thanks @ygribov for this patch and the other contributions made.
We will take this patch. I just wanted to highlight that the flang script is temporary and will be replaced by the flang-new driver when codegen is upstreamed. I guess the longer-standing contributions will be in flang-new. We are also trying to minimize changes to the flang script to keep it stable. Sometimes we have seen minor changes running into issues in a different bash version. Hope that is OK with you.
Hi Kiran,
Thanks for the update. We are just trying to figure out the status of flang's frontend at the moment and fix issues in flang script which we run into. I do realize that this work will be thrown away in few months. If you believe that this is not really useful, I'll keep flang fixes in our local branch.
As a side note, what is the plan about merging codegen into main?
flang/tools/f18/flang | ||
---|---|---|
319 | Not quite, I believe command-line arguments are wrong in practically all invocations... |
Why not use flang-new for this? The main difference between flang-new and flang is that the latter calls an external Fortran compiler to compile the unparsed source files. If you do need code-generation, then that's available on fir-dev. We've been using it to compile e.g. SNAP (i.e. the driver is already fairly capable).
If you believe that this is not really useful, I'll keep flang fixes in our local branch.
All improvements are useful. But we have no upstream testing for this script and a few downstream users to rely on this. Personally, I'd love for everyone to switch to flang-new instead. And if there's anything that's missing in flang-new that prevents people from switching, it would be good to identify such blockers.
As a side note, what is the plan about merging codegen into main?
It's work-in-progress. We'd like it to happen ASAP. As for the driver itself, I want to start moving code-gen patches from fir-dev onto main in the coming days. I just keep getting distracted :-)
flang/tools/f18/flang | ||
---|---|---|
319 | Could you be more specific? The compiler invocation in this case is: $ext_fc -E "${opts[@]}" "${other_srcs[$idx]}" ${output_definition:+$output_definition} and the diagnostic is: flang-new failed with exit status $status: "$wd/bin/flang-new" "${opts[@]}" "$@" So, flang-new should be replaced with $ext_fc. Also, "$@" should be removed. Anything else? What about other places? I'm just trying to understand the behavior "before" and "after" this change. Documenting this would be much appreciated (either as a comment here or in the summary). It would really help anyone browsing through the history of this script (in case something breaks, which usually happens to downstream users). |
It would be great if this name could follow's LLVM's coding guide:
Perhaps run_and_check_status? run_compiler_command? run_and_check? run_cmd?
Also, could you add a short description?