RFC: Removing clang-cl's /fallback option

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Removing clang-cl's /fallback option

Deep Majumder via cfe-dev
clang-cl's /fallback option was added back in 2013 [1] as part of
bringing up clang's native Windows support.

Since then, the Windows support has become quite stable, and I'm not
aware of anyone using /fallback anymore. In Chromium we stopped using
it in 2015 [2].

While /fallback doesn't require a lot of code, it does add a bit of
complexity to the driver (for example it added a special type of Job),
and I worry about the code rotting since it's not getting updated to
handle new flags.

So, are there any objections to removing the /fallback mode? My
proposal is to put a note in the upcoming Clang 12 release, and then
delete the code after the branch point, meaning it would be gone in
Clang 13.

Please let me know what you think.

Thanks,
Hans

1. https://github.com/llvm/llvm-project/commit/87cfa71071d73c702a833f19c9fe035f31c1275d
2. http://crrev.com/340533
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Removing clang-cl's /fallback option

Deep Majumder via cfe-dev
+1 from me, fwiw - though I don't have much connection to the Windows
side of things.

On Mon, Jan 18, 2021 at 2:32 AM Hans Wennborg via cfe-dev
<[hidden email]> wrote:

>
> clang-cl's /fallback option was added back in 2013 [1] as part of
> bringing up clang's native Windows support.
>
> Since then, the Windows support has become quite stable, and I'm not
> aware of anyone using /fallback anymore. In Chromium we stopped using
> it in 2015 [2].
>
> While /fallback doesn't require a lot of code, it does add a bit of
> complexity to the driver (for example it added a special type of Job),
> and I worry about the code rotting since it's not getting updated to
> handle new flags.
>
> So, are there any objections to removing the /fallback mode? My
> proposal is to put a note in the upcoming Clang 12 release, and then
> delete the code after the branch point, meaning it would be gone in
> Clang 13.
>
> Please let me know what you think.
>
> Thanks,
> Hans
>
> 1. https://github.com/llvm/llvm-project/commit/87cfa71071d73c702a833f19c9fe035f31c1275d
> 2. http://crrev.com/340533
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Removing clang-cl's /fallback option

Deep Majumder via cfe-dev
In reply to this post by Deep Majumder via cfe-dev
[Hans Wennborg]
> So, are there any objections to removing the /fallback mode?

None from me - we've never used this while testing MSVC's STL with clang-cl.

Thanks,
STL
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Removing clang-cl's /fallback option

Deep Majumder via cfe-dev
Can't say I was aware of /fallback at all.
--paulr

> -----Original Message-----
> From: cfe-dev <[hidden email]> On Behalf Of Stephan T.
> Lavavej via cfe-dev
> Sent: Tuesday, January 19, 2021 6:25 PM
> To: Hans Wennborg <[hidden email]>; Clang Dev <[hidden email]>
> Subject: Re: [cfe-dev] RFC: Removing clang-cl's /fallback option
>
> [Hans Wennborg]
> > So, are there any objections to removing the /fallback mode?
>
> None from me - we've never used this while testing MSVC's STL with clang-
> cl.
>
> Thanks,
> STL
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/cfe-
> dev__;!!JmoZiZGBv3RvKRSx!oBhkN3OQFOFdTQ7Kv_jJ_6ryBXrdJG3kXLN6DVdqdc3yeLzOi
> pZnHwMgbtweq6RAVw$
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Removing clang-cl's /fallback option

Deep Majumder via cfe-dev
In reply to this post by Deep Majumder via cfe-dev
On Mon, Jan 18, 2021 at 5:32 AM Hans Wennborg via cfe-dev
<[hidden email]> wrote:

>
> clang-cl's /fallback option was added back in 2013 [1] as part of
> bringing up clang's native Windows support.
>
> Since then, the Windows support has become quite stable, and I'm not
> aware of anyone using /fallback anymore. In Chromium we stopped using
> it in 2015 [2].
>
> While /fallback doesn't require a lot of code, it does add a bit of
> complexity to the driver (for example it added a special type of Job),
> and I worry about the code rotting since it's not getting updated to
> handle new flags.
>
> So, are there any objections to removing the /fallback mode? My
> proposal is to put a note in the upcoming Clang 12 release, and then
> delete the code after the branch point, meaning it would be gone in
> Clang 13.
>
> Please let me know what you think.

No concerns from me, thank you for looking into it!

~Aaron
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Removing clang-cl's /fallback option

Deep Majumder via cfe-dev
In reply to this post by Deep Majumder via cfe-dev
No objections from the Microsoft Office team.

-----Original Message-----
clang-cl's /fallback option was added back in 2013 [1] as part of bringing up clang's native Windows support.

Since then, the Windows support has become quite stable, and I'm not aware of anyone using /fallback anymore. In Chromium we stopped using it in 2015 [2].

While /fallback doesn't require a lot of code, it does add a bit of complexity to the driver (for example it added a special type of Job), and I worry about the code rotting since it's not getting updated to handle new flags.

So, are there any objections to removing the /fallback mode? My proposal is to put a note in the upcoming Clang 12 release, and then delete the code after the branch point, meaning it would be gone in Clang 13.

Please let me know what you think.

Thanks,
Hans
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Removing clang-cl's /fallback option

Deep Majumder via cfe-dev
In reply to this post by Deep Majumder via cfe-dev
Although we don't use fallback mode, we do use /ZW for WinRT extensions, and this isn't supported by clang-cl (the corollary of this is that we don't use clang-cl).  I'm mostly just posting this as a way to say that /ZW is important for many users of cl, and without /fallback I think those users will be prevented from using clang-cl.

What currently happens when you use clang for Windows support that comes with recent versions of Visual Studio?  Does it silently append /fallback on the user's behalf?  Or does it just give you an error if you try to use an unsupported option?

On Wed, Jan 20, 2021 at 6:53 AM Aaron Ballman via cfe-dev <[hidden email]> wrote:
On Mon, Jan 18, 2021 at 5:32 AM Hans Wennborg via cfe-dev
<[hidden email]> wrote:
>
> clang-cl's /fallback option was added back in 2013 [1] as part of
> bringing up clang's native Windows support.
>
> Since then, the Windows support has become quite stable, and I'm not
> aware of anyone using /fallback anymore. In Chromium we stopped using
> it in 2015 [2].
>
> While /fallback doesn't require a lot of code, it does add a bit of
> complexity to the driver (for example it added a special type of Job),
> and I worry about the code rotting since it's not getting updated to
> handle new flags.
>
> So, are there any objections to removing the /fallback mode? My
> proposal is to put a note in the upcoming Clang 12 release, and then
> delete the code after the branch point, meaning it would be gone in
> Clang 13.
>
> Please let me know what you think.

No concerns from me, thank you for looking into it!

~Aaron

>
> Thanks,
> Hans
>
> 1. https://github.com/llvm/llvm-project/commit/87cfa71071d73c702a833f19c9fe035f31c1275d
> 2. http://crrev.com/340533
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Removing clang-cl's /fallback option

Deep Majumder via cfe-dev
I just checked, and Microsoft's Visual Studio integration doesn't use
the /fallback flag.

Probably users who build with /ZW would apply that to the whole
project, which wouldn't make clang-cl /fallback any different from
using MSVC in the first place.

On Wed, Jan 20, 2021 at 8:22 PM Zachary Turner <[hidden email]> wrote:

>
> Although we don't use fallback mode, we do use /ZW for WinRT extensions, and this isn't supported by clang-cl (the corollary of this is that we don't use clang-cl).  I'm mostly just posting this as a way to say that /ZW is important for many users of cl, and without /fallback I think those users will be prevented from using clang-cl.
>
> What currently happens when you use clang for Windows support that comes with recent versions of Visual Studio?  Does it silently append /fallback on the user's behalf?  Or does it just give you an error if you try to use an unsupported option?
>
> On Wed, Jan 20, 2021 at 6:53 AM Aaron Ballman via cfe-dev <[hidden email]> wrote:
>>
>> On Mon, Jan 18, 2021 at 5:32 AM Hans Wennborg via cfe-dev
>> <[hidden email]> wrote:
>> >
>> > clang-cl's /fallback option was added back in 2013 [1] as part of
>> > bringing up clang's native Windows support.
>> >
>> > Since then, the Windows support has become quite stable, and I'm not
>> > aware of anyone using /fallback anymore. In Chromium we stopped using
>> > it in 2015 [2].
>> >
>> > While /fallback doesn't require a lot of code, it does add a bit of
>> > complexity to the driver (for example it added a special type of Job),
>> > and I worry about the code rotting since it's not getting updated to
>> > handle new flags.
>> >
>> > So, are there any objections to removing the /fallback mode? My
>> > proposal is to put a note in the upcoming Clang 12 release, and then
>> > delete the code after the branch point, meaning it would be gone in
>> > Clang 13.
>> >
>> > Please let me know what you think.
>>
>> No concerns from me, thank you for looking into it!
>>
>> ~Aaron
>>
>> >
>> > Thanks,
>> > Hans
>> >
>> > 1. https://github.com/llvm/llvm-project/commit/87cfa71071d73c702a833f19c9fe035f31c1275d
>> > 2. http://crrev.com/340533
>> > _______________________________________________
>> > cfe-dev mailing list
>> > [hidden email]
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Removing clang-cl's /fallback option

Deep Majumder via cfe-dev
In reply to this post by Deep Majumder via cfe-dev
Since there were no objections, here's a patch: https://reviews.llvm.org/D95876

On Mon, Jan 18, 2021 at 11:32 AM Hans Wennborg <[hidden email]> wrote:

>
> clang-cl's /fallback option was added back in 2013 [1] as part of
> bringing up clang's native Windows support.
>
> Since then, the Windows support has become quite stable, and I'm not
> aware of anyone using /fallback anymore. In Chromium we stopped using
> it in 2015 [2].
>
> While /fallback doesn't require a lot of code, it does add a bit of
> complexity to the driver (for example it added a special type of Job),
> and I worry about the code rotting since it's not getting updated to
> handle new flags.
>
> So, are there any objections to removing the /fallback mode? My
> proposal is to put a note in the upcoming Clang 12 release, and then
> delete the code after the branch point, meaning it would be gone in
> Clang 13.
>
> Please let me know what you think.
>
> Thanks,
> Hans
>
> 1. https://github.com/llvm/llvm-project/commit/87cfa71071d73c702a833f19c9fe035f31c1275d
> 2. http://crrev.com/340533
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Removing clang-cl's /fallback option

Deep Majumder via cfe-dev

On Tue, 2 Feb 2021 at 17:45, Hans Wennborg via cfe-dev <[hidden email]> wrote:
Since there were no objections, here's a patch: https://reviews.llvm.org/D95876


Farewell, /fallback, we hardly knew ye.

Csaba
--
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformant way
to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK)

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev