<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi JeffH,
<div class=""><br class="">
</div>
<div class="">After a brief search that I never knew was necessary, I find that “all” is smaller than “everything” in clang world.</div>
<div class=""><a href="http://clang.llvm.org/docs/UsersManual.html#enabling-all-diagnostics" class="">http://clang.llvm.org/docs/UsersManual.html#enabling-all-diagnostics</a></div>
<div class=""><br class="">
</div>
<div class="">So, my question “why isn’t -Wconversion implied by -Wall?” might have an astonishing answer.</div>
<div class=""><br class="">
</div>
<div class="">The resulting workflow is then:</div>
<div class="">1) notice the symptoms of a bug in the output/effect of the code</div>
<div class="">2) re-compile with -Weverything -Wno-c++98-compat -Wno-c++-compat</div>
<div class="">3) re-compile with -Weverything -Wno-c++98-compat -Wno-c++-compat -Wno-<other-conflicts></div>
<div class="">4) re-compile with -Weverything -Wno-c++98-compat -Wno-c++-compat -Wno-<other-conflicts> -Wno-<unrelated></div>
<div class="">5) address all remaining warnings by changing code</div>
<div class="">Experience and repeated exposure would permit combining steps 2-4.<br class="">
<div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
</div>
</div>
</div>
</div>
</div>
<div class=""><br class="">
</div>
<div class="">This is documented, once you know to go look for it. However, it was not obvious to me that looking beyond “-Wall” was needed.</div>
<div class=""><br class="">
</div>
<div class="">Whilst I agree wholeheartedly that “incorrect programs are incorrect”, I think designers of interfaces/standards have some responsibility to select a design that makes it easy to discover incorrect usage over one that makes it hard. Ideally, a
design should be selected that makes it hard to form incorrect usage rather than one that makes misuse easy.</div>
<div class="">
<div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<br class="Apple-interchange-newline">
Cheers,</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Dan.</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
—<br class="">
Dr Daniel Holmes PhD<br class="">
Architect (HPC Research)<br class="">
<a href="mailto:d.holmes@epcc.ed.ac.uk" class="">d.holmes@epcc.ed.ac.uk</a><br class="">
Phone: +44 (0) 131 651 3465<br class="">
Mobile: +44 (0) 7940 524 088<br class="">
Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
—</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
—</div>
</div>
</div>
</div>
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 7 Aug 2019, at 21:14, Jeff Hammond via mpi-forum <<a href="mailto:mpi-forum@lists.mpi-forum.org" class="">mpi-forum@lists.mpi-forum.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">I don't care that much about C11 _Generic, which is why I have always focused on a C99 solution to the large-count problem, but I disagree with your reasons for abandoning it.</div>
<div class=""><br class="">
</div>
<div dir="ltr" class="">"silently truncated at run time" is trivially addressed with -Wconversion or -Wshorten-64-to-32. The example program below is addressed by this.</div>
<br class="">
$ clang -Wshorten-64-to-32 -c truncation.c <br class="">
truncation.c:10:9: warning: implicit conversion loses integer precision: 'long long' to 'int' [-Wshorten-64-to-32]<br class="">
foo(i);<br class="">
~~~ ^<br class="">
1 warning generated.<br class="">
<br class="">
$ gcc-9 -Wconversion -c truncation.c <br class="">
truncation.c: In function 'main':<br class="">
truncation.c:10:9: warning: conversion from 'long long int' to 'int' may change value [-Wconversion]<br class="">
10 | foo(i);<br class="">
| ^<br class="">
<br class="">
$ icc -Wconversion -c truncation.c <br class="">
truncation.c(10): warning #1682: implicit conversion of a 64-bit integral type to a smaller integral type (potential portability problem)<br class="">
foo(i);<br class="">
^<br class="">
<br class="">
<div class="">In any case, incorrect programs are incorrect. It is a quality-of-implementation issue whether C compilers and MPI libraries detect incorrect usage. We have never designed MPI around people who can't follow directions and we should not start
now.
<div class=""><br class="">
Jeff
<div class=""><br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Aug 7, 2019 at 6:59 AM Jeff Squyres (jsquyres) via mpi-forum <<a href="mailto:mpi-forum@lists.mpi-forum.org" class="">mpi-forum@lists.mpi-forum.org</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
SHORT VERSION<br class="">
=============<br class="">
<br class="">
Due to the possibility of silently introducing errors into user applications, the BigCount WG no longer thinks that C11 _Generic is a good idea. We are therefore dropping that from our proposal. The new proposal will therefore essentially just be the addition
of a bunch of MPI_Count-enabled "_x" functions in C, combined with the addition of a bunch of polymorphic MPI_Count-enabled interfaces in Fortran.<br class="">
<br class="">
MORE DETAIL<br class="">
===========<br class="">
<br class="">
Joseph Schuchart raised a very important point in a recent mailing thread: the following C/C++ code does not raise a compiler warning:<br class="">
<br class="">
-----<br class="">
#include <stdio.h><br class="">
<br class="">
static void foo(int j) {<br class="">
printf("foo(j) = %d\n", j);<br class="">
}<br class="">
<br class="">
int main(int argc, char *argv[]) {<br class="">
/* 8589934592LL == 2^33 */<br class="">
long long i = 8589934592LL + 11;<br class="">
foo(i);<br class="">
return 0;<br class="">
}<br class="">
-----<br class="">
<br class="">
If you compile and run this program on a commodity x86-64 platform, a) you won't get a warning from the compiler, and b) you'll see "11" printed out. I tried with gcc 9 and clang 8 -- both with the C and C++ compilers. I even tried with "-Wall -pedantic".
No warnings.<br class="">
<br class="">
This is because casting from a larger int type to a smaller int type is perfectly valid C/C++.<br class="">
<br class="">
Because of this, there is a possibility that we could be silently introducing errors into user applications. Consider:<br class="">
<br class="">
1. An application upgrades its "count" parameters to type MPI_Count for all calls to MPI_Send.<br class="">
--> Recall that "MPI_Count" already exists in MPI-3.1, and is likely of type (long long) on commodity x86-64 platforms<br class="">
2. The application then uses values in that "count" parameter that are greater than 2^32.<br class="">
<br class="">
If the user's MPI implementation and compiler both support C11 _Generic, everything is great.<br class="">
<br class="">
But if either the MPI implementation or the compiler do not support C11 _Generic, ***the "count" value will be silently truncated at run time***.<br class="">
<br class="">
This seems like a very bad idea, from a design standpoint.<br class="">
<br class="">
We have therefore come full circle: we are back to adding a bunch of "_x" functions for C, and there will be no polymorphism (in C). Sorry, folks.<br class="">
<br class="">
Note that Fortran does not have similar problems:<br class="">
<br class="">
1. Fortran compilers have supported polymorphism for 20+ years<br class="">
2. Fortran does not automatically cast between INTEGER values of different sizes<br class="">
<br class="">
After much debate, the BigCount WG has decided that C11 _Generic just isn't worth it. That's no reason to penalize Fortran, though.<br class="">
<br class="">
-- <br class="">
Jeff Squyres<br class="">
<a href="mailto:jsquyres@cisco.com" target="_blank" class="">jsquyres@cisco.com</a><br class="">
<br class="">
_______________________________________________<br class="">
mpi-forum mailing list<br class="">
<a href="mailto:mpi-forum@lists.mpi-forum.org" target="_blank" class="">mpi-forum@lists.mpi-forum.org</a><br class="">
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpi-forum" rel="noreferrer" target="_blank" class="">https://lists.mpi-forum.org/mailman/listinfo/mpi-forum</a><br class="">
</blockquote>
</div>
<br clear="all" class="">
<div class=""><br class="">
</div>
-- <br class="">
<div dir="ltr" class="gmail_signature">Jeff Hammond<br class="">
<a href="mailto:jeff.science@gmail.com" target="_blank" class="">jeff.science@gmail.com</a><br class="">
<a href="http://jeffhammond.github.io/" target="_blank" class="">http://jeffhammond.github.io/</a></div>
</div>
</div>
</div>
</div>
_______________________________________________<br class="">
mpi-forum mailing list<br class="">
<a href="mailto:mpi-forum@lists.mpi-forum.org" class="">mpi-forum@lists.mpi-forum.org</a><br class="">
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum<br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>