I’m not saying it’s a bad suggestion - just pointing out that it likely wasn’t
caused by carelessness.
Setting something up on odin would be tricky, but someone could look at that
environment to see why it’s generating all these when we don’t see them
elsewhere - maybe it would be simple to set
On Nov 11, 2015, at 10:09 AM, Ralph Castain wrote:
>
> FWIW: I don’t think that’s the issue here. I don’t see these warnings on my
> CentOS7 box, for example. I think this is driven by the fact that odin has
> some very old compilers and a very different environment, and so it has
> historical
FWIW: I don’t think that’s the issue here. I don’t see these warnings on my
CentOS7 box, for example. I think this is driven by the fact that odin has some
very old compilers and a very different environment, and so it has historically
generated more warnings.
The warnings often are valid - the
Once you squash all these warnings, you could set up a little bit of Jenkins or
Travis CI logic to check for PRs that add new warnings and marks them
appropriately. Of course, with people making commits directly to master,
warnings introduced by those direct commits will be ascribed to those wh
This is from an older compiler, so take it for what it’s worth - I’ll take care
of the orte ones, but the bcol, nbc, and osc ones will need addressing:
pmix1_server_south.c: In function 'myerr':
pmix1_server_south.c:58: warning: 'nm' may be used uninitialized in this
function
pmix1_client.c: In
