Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

eric-wieser
Copy link
Member

@eric-wieser eric-wieser commented Sep 18, 2017

Many were the downcasting of npy_intp to int, partially because Descr->itemsize has a poor choice of type. The rules seem to be:

  • Size in bytes - npy_intp (unless it's descr->itemsize...)
  • Number of operands - int
  • Number of axes - 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.

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);
Copy link
Member Author

@eric-wieser eric-wieser Sep 18, 2017

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

Copy link
Member Author

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;
}
Copy link
Member Author

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;
Copy link
Member Author

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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was reserved word?

Copy link
Member Author

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);
Copy link
Member

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);
Copy link
Member

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`
Copy link
Member

@charris charris Sep 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Intentional "`"?

Copy link
Member Author

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);
Copy link
Member

@charris charris Sep 18, 2017

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.

Copy link
Member Author

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?

Copy link
Member

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;
Copy link
Member

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;
Copy link
Member

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?

Copy link
Member Author

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;
Copy link
Member Author

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

Copy link
Member Author

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);
Copy link
Member Author

@eric-wieser eric-wieser Sep 19, 2017

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 doubles

Copy link
Member

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?

Copy link
Member

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?

@charris
Copy link
Member

charris commented Sep 19, 2017

Need to use NPY_INTP_FMT instead of d for print formatting after the variable type changes in descriptor.c and datetime_strings.c.

@eric-wieser
Copy link
Member Author

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,
Copy link
Member Author

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;
}
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants