[REQUEST]: Add auto replacement C++ compiler options to alternative between GCC, Clang and MSVC

[raidenluikang]

Is your feature request related to a problem? Please describe

When change gcc compiler to MSVC compiler gcc specific compiler options required manually change.
For example -O2 -Wall -std=c++20
However, these options has alternatives in MSVC. So why don't automatic replacement they?

Describe the solution you'd like

If from GCC or Clang compiler change to MSVC in compiler editor automatic replace compiler options to its alternative in MSVC compiler, for example: replace -O2 to /O2, -Wall to /Wall , -std=c++20 to /std:c++20

And vice-versa, when change compiler from MSVC to GCC or Clang automatic replace compiler options back.

Describe alternatives you've considered

There also a strange situation, when change Clang compiler to GCC,

-stdlib=libc++ 

option should be removed, or discarded in GCC compiler.
Always manually fix compiler options are tedious !

If some compiler specific compiler options can't have alternative -- may be they , simple need to deleted from options editor?

Additional context

Not applicable

[dkm]

Hello,

This looks very complex to solve in the general case. We won't be able to come up with a 1:1 mapping for all options/compilers combinations. The closer we would be able to do is some find/replace for known options, but that would end up doing some pretty strange result for populated command lines... We would change some options only and get something like -Wsomething-we-dont-change /O3 /Wall -flto -fuse-ld=mold.

I don't see a good way of implementing this feature. Maybe you have better suggestion?

[cpplearner]

It's unclear whether -Wall should be mapped to /Wall. MSVC's /Wall is more like Clang's -Weverything.

MSVC's /std: accepts different values from GCC's -std=. For example, the former does not accept c++11 or gnu++14. Also, the meaning of /std:c++latest changes over time. It could mean C++20 or C++23, depending on the compiler version.

[raidenluikang]

I understand, but could you mapped -std=c++<N> <--> /std:c++<N> and -O<M> <--> /O<M>, also -Wall <--> /W4 when changed GCC to MSVC or Clang to MSVC, or vice versa ?

I thought, GCC 's -Wall should be mapped to MSVC's /W4 .

Latest, but optional feature:
MSVC /std:c++latest --> need to convert correct /std:c++<N> appropriate MSVC compiler version,
and after that map to -std=c++<N> ?

All other options remains without change, or removed --> It's up to you

[raidenluikang]

Also MSVC has strange behavior, even has /std:c++20 or /std:c++17 option , __cplusplus macros don't changed.

Could you append /Zc:__cplusplus compiler option when -std=c++<N> converted to /std:c++<N> ?

[OfekShilon]

Some easy examples:

• clang/gcc have -fno-semantic-interposition which can't be mapped to msvc - interposition is a linux-only property.
• clang/gcc have -gdwarf-5 which can't be mapped to msvc, as it generates pdb debug-info files and not dwarf.
• gcc/clang have a few hundreds optimization flags, msvc essentially has /O0, /O1 and /O2 (and a handful of others). Clearly no mapping is possible.

etc. etc. etc. For the huge majority of switches such a translation inherently isn't possible, and I believe trying to do this for the small subset of switches where it is - would add confusion instead of decreasing it.

[rmccampbell]

I think a better solution to this is #2214, which was suggested almost 4 years ago.