-
-
Notifications
You must be signed in to change notification settings - Fork 9.9k
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
BUG: Fix some (not all) compiler warnings #9705
Conversation
Many were the downcasting of `npy_intp` to `int`, partially because `Descr->itemsize` has a poor choice of type. Here we throw errors, rather than silently wrapping around.
@@ -659,7 +659,7 @@ npy_divmod@c@(@type@ a, @type@ b, @type@ *modulus) | |||
|
|||
/* snap quotient to nearest integral value */ | |||
if (div) { | |||
floordiv = npy_floor(div); | |||
floordiv = npy_floor@c@(div); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Loss of precision bug here for long double, fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extracted to #9749
PyErr_SetString(PyExc_TypeError, | ||
"shape is too long"); | ||
goto fail; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Buffer overflow error fixed here
PyErr_SetString(PyExc_ValueError, "Buffer too large"); | ||
goto fail; | ||
} | ||
descr->elsize = (int) view->itemsize; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really frustrating. PyBuffer.itemsize
is a ssize_t
, but our descr.itemsize
is an int
. It'd be great if we could fix this our end, but that would be an ABI breakage.
@@ -183,7 +183,7 @@ convert_datetime_metadata_tuple_to_datetime_metadata(PyObject *tuple, | |||
* the Python datetime.tzinfo object. | |||
*/ | |||
NPY_NO_EXPORT int | |||
get_tzoffset_from_pytzinfo(PyObject *timezone, npy_datetimestruct *dts); | |||
get_tzoffset_from_pytzinfo(PyObject *timezone_obj, npy_datetimestruct *dts); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was reserved word?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was not consistent with the name in the implementation, and changing this one was easier
@@ -191,7 +191,7 @@ npy_PyFile_Dup2(PyObject *file, char *mode, npy_off_t *orig_pos) | |||
if (ret == NULL) { | |||
return NULL; | |||
} | |||
fd2 = PyNumber_AsSsize_t(ret, NULL); | |||
fd2 = (int) PyNumber_AsSsize_t(ret, NULL); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we should really have a function for this that could also check that the value is in range. Might make a comment so we can find this later if we want to do a proper fix.
@@ -3693,7 +3693,7 @@ static void | |||
|
|||
delta -= start; | |||
for (i = 2; i < length; ++i) { | |||
buffer[i] = start + i*delta; | |||
buffer[i] = (@type@) (start + i*delta); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess multiplication by i
causes the problem here.
@@ -945,14 +951,20 @@ PyArray_IntpFromIndexSequence(PyObject *seq, npy_intp *vals, npy_intp maxvals) | |||
} | |||
|
|||
/*NUMPY_API | |||
* PyArray_IntpFromSequence | |||
* PyArray_IntpFromSequence` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Intentional "`"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, good catch
* Returns the number of integers converted or -1 if an error occurred. | ||
* vals must be large enough to hold maxvals | ||
*/ | ||
NPY_NO_EXPORT int | ||
PyArray_IntpFromSequence(PyObject *seq, npy_intp *vals, int maxvals) | ||
{ | ||
return PyArray_IntpFromIndexSequence(seq, vals, (npy_intp)maxvals); | ||
npy_intp result = PyArray_IntpFromIndexSequence( | ||
seq, vals, (npy_intp)maxvals); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, this might look better broken and aligned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you saying the indentation is wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, just that it might look better if it started after (
in the usual way. However, it looks like some of these files never got the full style cleanup done many years ago, so probably we can do all that in one swoop at a future date.
@@ -666,7 +667,7 @@ discover_dimensions(PyObject *obj, int *maxndim, npy_intp *d, int check_it, | |||
{ | |||
PyObject *e; | |||
int r; | |||
npy_intp n, i; | |||
npy_intp n; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function signature could use a style fixup.
@@ -596,9 +596,9 @@ convert_datetime_to_datetimestruct(PyArray_DatetimeMetaData *meta, | |||
out->as = (int)((dt % 1000LL) * 1000); | |||
} | |||
else { | |||
npy_datetime minutes; | |||
int minutes; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs to be int
for the call?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, and we're dividing by such a big number that that seems pretty reasonable
int local, int utc, NPY_DATETIMEUNIT base, int tzoffset, | ||
NPY_CASTING casting) | ||
{ | ||
npy_datetimestruct dts_local; | ||
int timezone_offset = 0; | ||
|
||
char *substr = outstr, sublen = outlen; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the cause of #9712
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extracted to #9814
_mm_prefetch(data0 + 512, _MM_HINT_T0); | ||
_mm_prefetch(data1 + 512, _MM_HINT_T0); | ||
_mm_prefetch((char *) (data0 + 512), _MM_HINT_T0); | ||
_mm_prefetch((char *) (data1 + 512), _MM_HINT_T0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks very sketchy - was the intended meaning ((char *) data0) + 512
? Else we end up loading 4KiB for double
s
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll guess that what you have is correct as the loop count is in type sized chunks of 8, so it makes some sense that 512 should also be in type sized units. I wonder if it really matters much?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very old code and the instruction is Microsoft specific, so I wonder if it isn't worth rewriting the whole thing at some point. @juliantaylor Thoughts?
Need to use |
Closing this, it stands an approximately 0% chance of being rebaseable |
* out_dimensions, out_strides, and out_offset. | ||
*/ | ||
NPY_NO_EXPORT int | ||
parse_index(PyArrayObject *self, PyObject *op, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed in #12276
used_ndim = PyArray_NDIM(self); | ||
new_ndim += (int) indices[curr_idx].value; | ||
curr_idx += 1; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whitespace fixes here moved to #13169
Many were the downcasting of
npy_intp
toint
, partially becauseDescr->itemsize
has a poor choice of type. The rules seem to be:npy_intp
(unless it'sdescr->itemsize
...)int
int
It might be far easier to reason about things if all of these were changed to
intp
, but perhaps there's performance to be had by not doing that.Here we throw errors, rather than silently wrapping around.
These were warnings raised by msvc.