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
For this RFC, I want to tighten down vLLM's compiler flags regarding warnings. Both to eliminate warnings when compiling code, and also to increase the number of warnings to prevent certain classes of bugs that have proven to be problematic in vLLM.
Why eliminate warnings? Seeing a lot of warning spam is annoying. Bogus or unimportant warnings can also mask real problems. It also just looks bad -- until #6904, one of the first things developers saw when building vLLM from source was a ton of spam about possible divide-by-zeros. These things are usually easy to fix and just need a small forcing function to make it happen.
Why add more warnings? I think we can eliminate or drastically reduce certain classes of bugs. For example, -Wconvert will hopefully prevent bugs like those fixed in #6838, #6649, and #1514 by making our narrowing conversions explicit.
Proposed Change.
Turn on -Werror
This is necessary in order to enforce a clean build.
Turn on -Wconversion
Eliminate narrowing conversion bugs especially from int64_t to int32_t. Currently way too spammy to turn on, especially in the attention kernels.
Just for reference, this is what we've used in the past at Neural Magic. Although this is definitely more strict than we want to use in vLLM at least to start with, and some of this came from jumping through hoops to compile on both g++ and clang++ without warnings:
This issue has been automatically marked as stale because it has not had any activity within 90 days. It will be automatically closed if no further activity occurs within 30 days. Leave a comment if you feel this issue should remain open. Thank you!
Motivation.
For this RFC, I want to tighten down vLLM's compiler flags regarding warnings. Both to eliminate warnings when compiling code, and also to increase the number of warnings to prevent certain classes of bugs that have proven to be problematic in vLLM.
Why eliminate warnings? Seeing a lot of warning spam is annoying. Bogus or unimportant warnings can also mask real problems. It also just looks bad -- until #6904, one of the first things developers saw when building vLLM from source was a ton of spam about possible divide-by-zeros. These things are usually easy to fix and just need a small forcing function to make it happen.
Why add more warnings? I think we can eliminate or drastically reduce certain classes of bugs. For example,
-Wconvert
will hopefully prevent bugs like those fixed in #6838, #6649, and #1514 by making our narrowing conversions explicit.Proposed Change.
Turn on
-Werror
This is necessary in order to enforce a clean build.
Turn on
-Wconversion
Eliminate narrowing conversion bugs especially from
int64_t
toint32_t
. Currently way too spammy to turn on, especially in the attention kernels.Feedback Period.
No response
CC List.
@bnellnm @WoosukKwon
Any Other Things.
No response
The text was updated successfully, but these errors were encountered: