Compilation warnings with clang 9.0.0 #17015
Comments
From @dur-randirCreated by @dur-randirI get the following warnings when building perl on Debian with clang 9.0.0 Wstring-plus-int: sv.c:12490:41: warning: adding 'int' to a string does not append to Perl Info |
From @demerphqAm I missing something here? This seems like pretty reasonable code and Yves On Thu, 23 May 2019, 11:34 Sergey Aleynikov (via RT), <
|
|
The RT System itself - Status changed from 'new' to 'open' |
From @hvdsOn Thu, 23 May 2019 08:06:30 -0700, demerphq wrote:
I think it's warning you that this isn't C++. I don't think this is one we should care about. Hugo |
From @dur-randirOn Thu, 23 May 2019 08:18:28 -0700, hv wrote:
This is also in their's default warnings set, i'll check is it only for clang9 or has appeared earlier. |
From @dur-randirOn Thu, 23 May 2019 08:06:30 -0700, demerphq wrote:
This warning was added in clang 8.0.0, released in March 2019. They've already had some discussion about it's usefulness in https://reviews.llvm.org/D55382. |
jkeenan
added
the
build-time-warnings
|
I now have clang-10 available on Linux. Here is an update on the build-time warnings we're getting on unthreaded builds on Linux using that C-compiler. non-DEBUGGING DEBUGGING (as originally reported with clang-9 in this ticket) And, for good measure, Threaded, non-DEBUGGING I can supply further data upon request. Thank you very much. |
|
Is there something specific I should note here Jim?
Yves
…On Fri, 13 Nov 2020 at 23:55, James E Keenan ***@***.***> wrote:
I now have clang-10 available on Linux. Here is an update on the
build-time warnings we're getting on unthreaded builds on Linux using that
C-compiler.
$ clang --version
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
*non-DEBUGGING*
$ ./perl -Ilib -V:config_args
config_args='-des -Dusedevel -Dcc=clang'
$ report-build-warnings blead.2ce8ebb919.linux.clang-10.maketp.output.txt.gz
File: blead.2ce8ebb919.linux.clang-10.maketp.output.txt.gz
W#pragma-messages 4
Wimplicit-int-float-conversion 6
Wstring-compare 2
Wstring-plus-int 1
*DEBUGGING* (as originally reported with clang-9 in this ticket)
$ ./perl -Ilib -V:config_args
config_args='-des -Dusedevel -DDEBUGGING -Dcc=clang';
$ report-build-warnings blead.2ce8ebb919.linux.clang-10.debugging.maketp.output.txt.gz
File: blead.2ce8ebb919.linux.clang-10.debugging.maketp.output.txt.gz
W#pragma-messages 4
Wimplicit-int-float-conversion 6
Wstring-compare 27
Wstring-plus-int 1
And, for good measure, *Threaded, non-DEBUGGING*
report-build-warnings blead.2ce8ebb919.linux.clang-10.threaded.maketp.output.txt.gz
File: blead.2ce8ebb919.linux.clang-10.threaded.maketp.output.txt.gz
W#pragma-messages 4
Wimplicit-int-float-conversion 6
Wstring-compare 2
Wstring-plus-int 1
I can supply further data upon request.
Thank you very much.
Jim Keenan
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17015 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAZ5R4ZQ5FBP5T4PG2SUATSPW2NLANCNFSM4TVEHBPQ>
.
--
perl -Mre=debug -e "/just|another|perl|hacker/"
|
We've improved. Compiling a threaded build on Linux using clang-10 as compiler, we're now down to: This matches the build-time warnings output I'm getting with clang-10 on FreeBSD-12 as well. Thank you very much. |
As @jkeenan has worked out, the
This one is perhaps a bit more defensible; it's coming from It's clearly there as an optimization to avoid the cost of a However if the degree of undefinedness is only that there may be multiple copies of a string literal resulting in distinct pointers, then the check could still be perfectly safe and will likely still often be useful: scope entry and exit is a pretty hot path in perl, and it would be a shame to slow it down just because a compiler is being extra pedantic. If it is "undefined" to the degree that Hugo |
|
On 3/21/21 8:47 PM, Hugo van der Sanden wrote:
We've improved. Compiling a threaded build on Linux using clang-10
as compiler, we're now down to:
|$ report-build-warnings
blead.3e25f6d2dc.linux.clang-10.threaded.maketp.output.txt.gz File:
blead.3e25f6d2dc.linux.clang-10.threaded.maketp.output.txt.gz
Wstring-compare 2 Wstring-plus-int 1 $ parse-build-warnings
blead.3e25f6d2dc.linux.clang-10.threaded.maketp.output.txt.gz File:
blead.3e25f6d2dc.linux.clang-10.threaded.maketp.output.txt.gz [ {
char => 41, group => "Wstring-plus-int", line => 12517, source =>
"sv.c", text => "adding 'int' to a string does not append to the
string", }, |
As before, this is perfectly normal pointer arithmetic - the warning is
aimed at people who half-learned a bit of C++. We could satisfy it by
replacing |q + 1| with something like |&q[1]|, but that makes the code
worse so we shouldn't do it. We should ignore or shut up the warning
instead, preferably globally.
+1
{
char => 37,
group => "Wstring-compare",
line => 8219,
source => "re_comp.c",
text => "result of comparison against a string literal is
unspecified (use an explicit string comparison function instead)",
},
This one is perhaps a bit more defensible; it's coming from
|LEAVE_with_name("study_chunk")|, defined in scope.c as a macro with
argument "name" (and documented that the argument should be a string
literal).
Any macro that requires its parameter to be a string literal should
enforce that by surrounding at least one use of it with quotes
"" name ""
It checks whether the scope we're leaving has the right name
using:
|assert(((char*)PL_scopestack_name[PL_scopestack_ix-1] \ == (char*)name)
\ || strEQ(PL_scopestack_name[PL_scopestack_ix-1], name)); \ |
It's clearly there as an optimization to avoid the cost of a |strEQ()|
when it's the same pointer, but if that truly gives undefined behaviour
for a string literal we could just use the |strEQ()| always.
However /if/ the degree of undefinedness is only that there may be
multiple copies of a string literal resulting in distinct pointers, then
the check could still be perfectly safe and will likely still often be
useful: scope entry and exit is a pretty hot path in perl, and it would
be a shame to slow it down just because a compiler is being extra pedantic.
I would argue that since this is in an assert() which expands to no code
at all outside DEBUGGING builds, that the person doing the compiling has
already said they aren't interested in the fastest possible code.
Hence we needn't worry about doing things the fastest possible way.
…
If it is "undefined" to the degree that |"foo" == "bar"| could be true,
then our code is wrong and we should change it.
Hugo
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#17015 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA2DH7J6DPKWPDSLSANGFTTE2VUPANCNFSM4TVEHBPQ>.
|
Observed in clang 9 and 10. Partial solution for #17015
Observed in clang 9 and 10. Partial solution for #17015
|
1 build-time warning quieted by #18671; more remain; ticket stays open. |
Observed in clang 9 and 10. Partial solution for Perl#17015
Today I updated https://rt.cpan.org/Ticket/Display.html?id=136985 to request that the upstream maintainer look at these warnings. |
|
The remaining build-time warnings being emitted by Scalar-List-Utils have been cleared up as per https://rt.cpan.org/Ticket/Display.html?id=136985 and subsequent synch into blead. This ticket is now closable. |
Migrated from rt.perl.org#134131 (status was 'open')
Searchable as RT134131$
The text was updated successfully, but these errors were encountered: