Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Turn on useful warnings from gcc #218

Merged
merged 8 commits into from
Feb 22, 2018

Conversation

kalvdans
Copy link
Contributor

Fix code that gcc warns for. Remove unused variables, const poisoning,
and use declare functions (void) instead of ().

Please note that it changes the signatures of the API. The ABI is not changed.

I need someone to double-check the CMakeLists.txt changes.

Christian Häggström added 4 commits February 17, 2018 20:56
Fix code that gcc warns for. Remove unused variables, const poisoning,
and use declare functions (void) instead of ().
Function definitions in header files makes some functions unused in some
compilation units.
@kalvdans
Copy link
Contributor Author

@FrancescAlted, what is your opinion on annotating strings that should not be modified with 'const' in the API?

Christian Häggström added 2 commits February 19, 2018 10:36
Use add_compile_options() instead of fiddling with variables. The
options will apply to both C and C++ so I had to drop -Wstrict-prototypes.
I better not touch Windows flags since I can't easily test out the
changes locally.
@kalvdans
Copy link
Contributor Author

Ok, this pull request is ready for review. @estan, @FrancescAlted. We also need to agree on the timing to introduce these API changes and what to write in the release notes.

blosc/blosclz.c Outdated
@@ -79,7 +79,7 @@



static inline uint8_t *get_run(uint8_t *ip, const uint8_t *ip_bound, const uint8_t *ref) {
static uint8_t *get_run(uint8_t *ip, const uint8_t *ip_bound, const uint8_t *ref) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you get rid of inline keyword. Is it unnecessary on all modern compilers?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change was unintentional. I will revert it. And yes, modern compilers ignore this keyword, I usually use __attribute__((force_inline)) instead.

#pragma message("AVX2 shuffle tests not enabled.")
#else
#warning AVX2 shuffle tests not enabled.
#endif
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why you don't want the AVX2 not being tested messages to appear?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It breaks the build if we want to enable -Werror at a later time. Do you feel strongly for keeping it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I am just used to see it. If I see it, I know that AVX2 is not being tested in the platform. Probably mainly useful during early stages of AVX2 support though, so +1.

endif(NOT CMAKE_C_FLAGS AND COMPILER_SUPPORT_SSE2)
if(COMPILER_SUPPORT_SSE2)
add_compile_options(-msse2)
endif(COMPILER_SUPPORT_SSE2)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does add_compile_options() require a cmake > 2.8.10? This is the current minimum required.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, seems it was added in cmake 2.8.12. Should we require cmake >= 2.8.12 or should I revert my changes to CMakeLists.txt?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fortunately it seems like Ubuntu trusty has 2.8.12, so let's make a bump. Could you do that in main CMakeLists.txt?

@@ -251,15 +251,18 @@ if(DEACTIVATE_AVX2)
endif()

# flags
# @TODO: set -Wall
# Set -Wall and other useful warning flags.
if(CMAKE_C_COMPILER_ID STREQUAL GNU OR CMAKE_C_COMPILER_ID STREQUAL Clang OR CMAKE_C_COMPILER_ID STREQUAL Intel)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could also toss AppleClang in there for good measure. It's how Apple's own version of Clang is identified.

Instead of the if, you could use generator expressions like:

add_compile_options(
    "$<$<CXX_COMPILER_ID:GNU>:-Wall;-Wwrite-strings;-Wno-unused>"
    "$<$<CXX_COMPILER_ID:Clang>:-Wall;-Wwrite-strings;-Wno-unused>"
    "$<$<CXX_COMPILER_ID:AppleClang>:-Wall;-Wwrite-strings;-Wno-unused>"
    "$<$<CXX_COMPILER_ID:Intel>:-Wall;-Wwrite-strings;-Wno-unused>"
)

But I don't know if that's any prettier? Best-looking would be if the 3.3+ feature if ("bar" IN_LIST _list) could be used I think, but that's not in 2.8.

If you keep it the way it is, perhaps move the add_compile_option to inside the if block just below (the one for SSE2)? (since the conditions are the same).

Copy link

@estan estan Feb 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, thinking a bit, don't take the generator expressions as a serious suggestion. It's just cryptic, while anyone who reads the CMakeLists.txt probably just want to get on with what they were doing and not learn all about CMake's warts :)

Generator expressions seems to be primarily for when you need information that is only available at CMake's final "generation" step, and the compiler ID is not such a thing.

# Set -Wall and other useful warning flags.
if(CMAKE_C_COMPILER_ID STREQUAL GNU OR CMAKE_C_COMPILER_ID STREQUAL Clang OR CMAKE_C_COMPILER_ID STREQUAL Intel)
add_compile_options(-Wall -Wwrite-strings -Wno-unused-function)
endif(CMAKE_C_COMPILER_ID STREQUAL GNU OR CMAKE_C_COMPILER_ID STREQUAL Clang OR CMAKE_C_COMPILER_ID STREQUAL Intel)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Repeating the condition in the endif(..) is no longer necessary I think, so this could be just endif().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Repeating the condition in the endif(...) was just a way to see at a glance where the condition block finished. This is more useful in nested conditions, and we could remove it from here (not a big deal though).

Copy link

@estan estan Feb 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FrancescAlted Aha, I thought it was a left-over from < 2.6 times, when it was mandatory. Yes, no big deal, and could just as well be kept.

@estan
Copy link

estan commented Feb 19, 2018

@kalvdans Looks like some nice cleanups. Just a couple of comments, but 👍 from me.

@FrancescAlted FrancescAlted merged commit b569be2 into Blosc:master Feb 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants