impala-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Armstrong (Code Review)" <ger...@cloudera.org>
Subject [Impala-ASF-CR] IMPALA-3676,4321: Use clang as a static analysis tool
Date Thu, 20 Oct 2016 00:00:29 GMT
Tim Armstrong has posted comments on this change.

Change subject: IMPALA-3676,4321: Use clang as a static analysis tool
......................................................................


Patch Set 2:

(5 comments)

http://gerrit.cloudera.org:8080/#/c/4758/2/be/CMakeLists.txt
File be/CMakeLists.txt:

Line 106: SET(CXX_FLAGS_TIDY "${CXX_FLAGS_TIDY} --gcc-toolchain=${GCC_ROOT}")
> They seem to be set for different reasons - this one for clang-tidy, that o
Ah right, I didn't realise the ASAN build got the --gcc-toolchain flag in a different way
- it's in:

  cmake_modules/asan_toolchain.cmake

Maybe we should rename asan_toolchain to clang_toolchain and also use that for the clang-tidy
builds?


http://gerrit.cloudera.org:8080/#/c/4758/2/be/src/exprs/aggregate-functions-ir.cc
File be/src/exprs/aggregate-functions-ir.cc:

Line 175
> static const int* HLL_PRECISION_PTR = &AggregateFunctions::HLL_PRECISION;
I think it might manifest as a link-time error if you do anything with the address, unless
constexpr does something different with its linkage compared with static const ....


http://gerrit.cloudera.org:8080/#/c/4758/2/be/src/exprs/slot-ref.cc
File be/src/exprs/slot-ref.cc:

PS2, Line 176: static
> Why not?
It doesn't make a difference for correctness, and I don't see any reason we would want the
compiler to store it in global memory somewhere.

If it's a regular local variable that's a constant the compiler is free to do whatever it
wants with it, particularly if you don't take the address of it - it can optimise it out,
put it in the global data section, whatever is most appropriate.


http://gerrit.cloudera.org:8080/#/c/4758/1/be/src/util/runtime-profile.h
File be/src/util/runtime-profile.h:

Line 335
> You don't think it's worth the space savings?
I don't think there are enough RuntimeProfile objects to produce a noticable savings, I think
we should prioritise readability (e.g. here own_pool_ seems to be logically grouped with pool_).
For some other objects that are more numerous it might make a bigger difference.


http://gerrit.cloudera.org:8080/#/c/4758/1/bin/impala-config.sh
File bin/impala-config.sh:

Line 260: export IMPALA_GOOGLETEST_VERSION=20151222
> Since that's the version that's already in S3, I'd like to make this a foll
Maybe just wait until the follow-on patch to make the change?  It's nice to use official releases
where possible.


-- 
To view, visit http://gerrit.cloudera.org:8080/4758
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I4ed168488cb30ddeccd0087f3840541d858f9c06
Gerrit-PatchSet: 2
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Jim Apple <jbapple@cloudera.com>
Gerrit-Reviewer: Jim Apple <jbapple@cloudera.com>
Gerrit-Reviewer: Tim Armstrong <tarmstrong@cloudera.com>
Gerrit-HasComments: Yes

Mime
View raw message